Development Process

Piwik is an open source project. Many people contribute via ideas and patches for bugs and new features.

How we use trac for Piwik project management

We use trac to keep track of all bugs, feature requests, and other tasks concerning the Piwik software, the website, and documentation.

We make sure all tickets contain enough information: details as to how to reproduce for bugs, some sort of specification for new features, or mockups for UI improvements. We have a policy of keeping trac a very organized place. We generally prioritize tickets by severity (e.g., bugs), and individual developers (Piwik team members or external contributors) decide which features they would like to implement.

While we are aiming to implement the features in our roadmap, we are also open to accept new unplanned features when the code and documentation meet our quality standards.

Mailing lists

This mailing list is used to discuss Piwik internals, ask questions about the architecture, discuss new ideas, etc.

This mailing list notifies all the commits to our Git repository.

This mailing list notifies all the changes to tickets in Trac (new ticket, closed, modifications, new comments, etc.)

IRC

Speak to other users and core team members in IRC at irc.freenode.net/#piwik (webchat)

Git repository

Piwik Git repository is hosted at Github and is publicly accessible at  https://github.com/piwik/piwik

In case Github goes down, we would use our backup Git Mirror at: git.piwik.org.

Who has write access to the Git repository?

All developers from the Piwik team can commit in our Git repo.

How can I obtain write access to Git?

To obtain write access on the Git repository, one must be trusted by other Piwik developers. This generally means that the developer submitted a few pull requests, implemented a new feature or improved the current code.

We are very open to welcoming new members in the team, feel free to join the fun!

How does code get committed in Git?

All the code committed to Git is reviewed by at least one other developer in the team. Very often, Piwik developers themselves will send bigger patches by pull requests for review by another member of the team before commit – all pull requests or patches submitted by external developers are extensively reviewed.

It is highly recommended that code committed in master branch respects Piwik coding standards, does not break, that all unit tests pass, and that the UI was manually tested if the user interface is affected by the change. It is recommended that the commit message references a ticket number; for example,

fixes #159 - changed patch to use wrapInner() instead of wrap()

will automatically close the ticket #159 in trac. You can also use the magic keyword

Refs #159

and a comment will be automatically added to the ticket #159 with a link to the commit on Github.

When applicable, the related online documentation and the related FAQs should be updated.

How to submit a patch or pull request?

Thank you for your interest in contributing to Piwik and adding your name to the list of contributors (see our git stats).
We provide all information to below:

  • Please make sure there is a ticket created in trac for the bug you are fixing, or the new feature you are implementing
  • Double check that your code respect the Piwik coding standards and security guidelines
  • Make sure the code is tested. Read more about tests in piwik. You may need to include unit tests or updates to existing tests, as Travis will run the tests automatically.
  • If you’re new to GitHub see our guide Contributing with Git.
  • Clone the Piwik repository in your github account, modify your fork.
  • Your code will be reviewed by a Piwik team member to ensure it meets quality standards. Please check these example of past code reviews: JSS/CSS minifying, SEO plugin, PDF plugin.
  • Send a pull request on GitHub with your changes along with a comment explaining the changes.
  • We will review the pull request and comment in the following hours or days. Congratulations!

If the pull request is non trivial, please be ready for a few iterations of this simple process: you will most likely get feedback and be kindly asked to update the code. We value high quality in the code.

When the patch is reviewed and validated by a Piwik developer, it will be pushed to the master. We will edit the ticket name with your name so that you will be credited in the changelog.

To gain write access to the Piwik Git repository, repeat this process a few times. Enjoy!

How can a third party plugin be included in core?

The adoption of a plugin into the Piwik core requires that we consider such criteria as (but not limited to):

  • audience – plugin appeals to a broad spectrum of users
  • desirabilty – is it a frequently requested feature by the Piwik community?
  • functionality – feature completeness
  • testability – use of unit tests and impact to manual testing (e.g., differences when plugin is activated vs deactivated)
  • maturity – history and popularity of the plugin
  • performance – impact on archiving and/or UI interaction
  • supportability – likelihood of spawning support tickets and forum posts of the “how do I?” or “why does it?” variety
  • complexity – simpler is better; +1 if developer has git commit privileges
  • dependencies – does it depend on closed source and/or paid subscription services?
  • licensing – license compatibility with GPLv3

Release Process

When a release is ready (when all assigned tickets to the corresponding roadmap are closed), the release is tagged with the release number (see all tags).

When a release is known as being “stable”, it will be tagged with the release number. A shell script will then be ran by the release manager to generate the archives (zip and tar.gz) which are copied on the build server builds.piwik.org. The file builds.piwik.org/LATEST is updated with the latest stable release number. Within hours, thousands of Piwik installations will be updated via the one click upgrade mechanism – or manual upgrade – by Piwik users.

Releases that contain the string “alpha”, “beta”, “rc”, are built for testing purposes and are not advertised on the website homepage. They are available on the build server and the file builds.piwik.org/LATEST_BETA is updated. You also can enable Piwik to use the latest Beta release automatically if you want to test the latest features (see this faq).

Further reading

See also: List of Features, Consultants, Testimonials, Piwik supporters, Merchandise and Participate in Piwik!.