Piwik is an open source project. Many people contribute via ideas and patches for bugs and new features.
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.
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.)
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.
All developers from the Piwik team can commit in our Git repo.
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!
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
and a comment will be automatically added to the ticket #159 with a link to the commit on Github.
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:
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!
The adoption of a plugin into the Piwik core requires that we consider such criteria as (but not limited to):
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).