12.1.0 trac milestone organisation

[Daniel Drake]

Hi,

In recent release cycles, the trac milestone on http://dev.laptop.org
for each release has been disorganised and (for that reason) of
limited use - many more tickets in the milestone that the team would
have time to attack. In the 11.3.0 cycle I saw that I was not the only
one affected by this - it makes things especially hard for those who
don't spend as many hours tracking the release progress as the rest of
us.

So for 12.1.0 I would like to change this by myself dedicating more
time to keeping things clean and managed within the 12.1.0 milestone.
I'm proposing that we experiment with the following, which is what I
wrote at http://wiki.laptop.org/go/12.1.0/Release_plan  :



In recent release cycles, the release milestone in trac has become a
bit of a dumping ground for ideas-of-the-minute and miscellaneous bugs
(e.g. bugs not related to current development efforts). As such the
milestone's bug listing has been of limited value and hard to utilise
by those who do not work on the release specifics every day. In this
release cycle, the release manager will attempt to improve on this
situation with the following measures:

- All bugs in the milestone will have a correct and accurate assignee
who understands the responsibility to work on the issue according to
the schedule in this release plan.
- The release manager will triage incoming bugs roughly according to
the following criteria:
 - - Regressions caused by work in this release cycle will be included
in the milestone and assigned accordingly
 - - All other tickets will be triaged into Future Release (for things
we want, but will not necessarily commit to working on it immediately)
and Opportunity (for nice-to-haves).
 - - All tickets triaged to Future Release and Opportunity will have
at least 1 core release team member as assignee or CC. This way, any
bad triaging decisions can be raised and discussed in the weekly
release meeting.
 - Developers are welcome to take tickets from Future Release and
Opportunity milestones and move them into the release milestone, as
and when they have time available to dedicate to such work.
 - The resultant succinct, clean ticket listing in the milsetone will
be useful for release management, allowing for early identification of
release blockers, easy progress tracking, and lets us easily see that
nobody is overloaded with work.

Daniel