This guide describes how we, the team of developers that makes changes to Piwik Core, operate and how others can participate in our work.
Read this guide if
This guide makes no assumptions. You do not need to know how to code or know how Piwik works in order to understand this guide.
We use Github to keep track of all bugs, feature requests and tasks that concern Piwik, the website and Piwik's documentation.
We make sure all tickets contain enough information, including:
We are rather obsessed with keeping our issue tracker an organized place. Tickets are either of the type 'Bug', 'Enhancement' or 'Task'. Developers (Piwik team members or external contributors) decide for themselves which features they would like to work on, with highest priority given to issues in the next version milestone. We have been using an issue tracker since the beginning of the project.
All opened tickets are grouped in Milestones. Click the menu link 'Milestones' in github issues. The versions milestones are listed at the very top and contains all the most important issues to close in accordance with our vision for the Piwik analytics platform.
Most important issues and bugs are moved to Short term milestone.
This milestone is our active tickets backlog. From time to time, we move one ticket from
Short term to the current version milestone (eg.
We try to publish a new Piwik release about once a month. A release is ready when the following release conditions are met:
Generally we will release several beta releases to give early access and ensuring continuous testing of Piwik.
To publish a new Piwik version, the release manager will tag the new version in git (see all release tags). A shell script is then run to generate the archives (zip and tar.gz) which are cryptographically signed and then copied to the build server builds.piwik.org and builds.piwik.org/LATEST is updated with the latest stable release number. Within hours, Piwik installations will be updated by users via the one click upgrade mechanism – or by manual upgrades.
Releases that contain the string "alpha", "beta", "rc", are built for testing purposes and are not advertised on piwik.org. They are however made available on the build server and the builds.piwik.org/LATEST_BETA is updated to contain the release's version string. You can enable Piwik to use the latest Beta release automatically if you want to test the latest features (see this faq to learn how).
As of 2014, we manage over fourty repositories at Github. This includes the main repository for Piwik and several plugins, themes, and toolsets to make the most out of Piwik, such as Piwik clients for software development in Python, Ruby, C#, SDKs for iOS, debian packages and other useful Piwik developer tools.
All developers from the Piwik organization can push to all git repositories.
All code committed to git is reviewed by at least one other developer in the team. Very often, Piwik developers themselves will send bigger changes by pull request for review before committing. All pull requests or patches submitted by external developers are extensively reviewed.
It is highly recommended that code committed in the master branch respects the Piwik coding standards, does not cause tests to fail, and does not create regessions in the UI or the platform. And the commit message should reference a ticket number in almost all cases; for example,
fixes #159 - changed patch to use wrapInner() instead of wrap()
This message will automatically close the ticket #472.
You can also use simply
#159 and a comment will be automatically added to the ticket #159 with a link to the commit on Github.
To gain push access to the Piwik code repositories, one must make positive changes in the project, such as contributing pull requests, bringing new ideas, code, marketing, product visions. When a certain amount of work has been achieved, when we trust your skills and judgement, we will invite you to join us in the core team.
Join us in the forums at forum.piwik.org
Discover our vibrant community where analytics tips are shared, suggestions on how to make the most out of Piwik, or general questions. Several team members visit the forums regularly, as well as active members of the community.
There are many ways you can make a difference in the project and influence the overall goodness of Piwik, most of which do not include coding.
If you find a new feature request very exciting or important, or if you're experiencing a particular bug, the best way to be heard by the Piwik team is to comment on the ticket. Features that are most requested are often higher on the priority list.
One way to help core development is to submit a report when you find a bug.
If you believe you have found a bug in Piwik, please do the following:
Anyone can contribute to Piwik by submitting a feature request. You can discuss with other users what can be improved in Piwik in the Feature Suggestions forum, or search if someone reported your suggestion before in the Piwik issue tracker. If you find an existing issue, leave a comment to make your voice heard. Otherwise create a new issue describing how Piwik can be improved to help you in your daily work.
If you can code and want to directly help Piwik development, you can contribute changes! read our Contributing to Piwik Core guide to learn more.
There are other useful ways to participate to Piwik and make a positive difference! Learn more: How do I get involved?