The goal of this issue is to make a sprint planning across all our repositories (plugins, components, other projects). #### Why is this important?
Currently we follow up any issues in
piwik/piwik issue tracker. Problem is that we tend to forget about bug reports and suggestions made in any of the 40+ other issue trackers (such as plugins, components, side projects, log-analytics, etc.).
To build the best platform and products we simply cannot forget even one important issue. Therefore we aim to establish an effective process to manage our work across 50+ products.
The goal of this issue is to test this process at least once and see how it goes.
Notes: - it will be helpful to generate accurate changelog across our repositories. see (piwik/github-changelog-generator#4)
How will this sprint planning be done? And how will it prevent those kinda issues? Eg when moving issues in a current milestone during a "sprint". In theory, a sprint is planned in the beginning of the sprint and only those issues are being worked on. In our case we do not really have a sprint that is "protected" etc. Or will this be the case now?
I'm also not sure if 4 week Sprints is really correct the best for us as we are in a maintenance mode. If we want to do that we'd probably need 1 week sprints but think something Kanban like might me more appropriate.