It's actual the final mail and not the draft to sawyer... :D Sorry about that -- Cheers, burnersk Am 2014-10-21 20:34, schrieb burnersk:

Hi Sawyer,

here is my draft of the introduction email...

--- DRAFT ---

Hi folks.

I was wondering recently when the feature X or the bug Y will be fixed. So I try to look up it in the GitHub Milestones[1]. I saw that milestones was used but starting from 0.14100 there was no progress at all with milestones (progress with issues itself was made of course).

For me as a developer milestones are nice because I can see what is on the schedule for the next release. From the user point I can see when my beloved feature X or hated bug Y is going to be fixed.

I think GitHub Milestones are a great way to communicate to developers and users at the same time.

So I asked on #dancer if there where any plans to proceed with release planning based on GitHub Milestones.

It turns out that the intention was there but time was missing to organize.

Sawyer asked me to attend to help with release planning.

I'm not sure that this is true but I had in mind, that the Dancer2 release cycle supposed to be 2 weeks. So that every second week there will be a new release with new great features and fixed bugs.

I'd like to check with all of you folks, developers or users, if you want this or not. Please discuss this idea.

I can imagine the following "process".

Basic environment: * develop period: 12 days (freeze on day 13 and 14, release on day 14) * develop time per developer: 1 hour / day (5 days a week, 10 hours a period) * developers: 8 core developer (some may not work "all the time" but we have other contributors) * total work hours per period: 80 hours

Milestone calculation (break on first match, it's just a guideline - not a strict rule): * estimate severity and popularity * very_next_release means the very next release even if it's barely possible (no left *planed* development time) * next_possible_release means the next possible release according on the development time left for the milestone * next_but_one_possible_release means the possible release(ses) after next_possible_release according on the development time left for the milestone 1. for severity in (Blocker, Critical) set milestone to very_next_release 2. for type in (Bug) and severity in (Major) and popularity in (High) set milestone to very_next_release 3. for severity in (Medium) and popularity in (High) and complexity in (Easy) set milestone to next_possible_release 4. for severity in (Medium) and popularity in (High) and complexity in (Moderate) set milestone to next_possible_release 5. for severity in (Medium) and popularity in (High) and complexity in (Hard) set milestone to next_but_one_possible_release 6. for others set milestone to next_but_one_possible_release

I'd soft estimate the severity and popularity, check back with the core developers and finally assign the milestone. Furthermore I'll (or a small team will) set severity, popularity and complexity initially when they are checked by the core team.

According to the release cycle the milestone due dates will be set.

Issues which are not become final within the desired milestone will be moved to the next milestone. Due to this circumstance there will be reserve of 10 working hours within every milestone for those delayed issues. The affected issues will be flagged as delayed.

What do you think about all of it?

[1] https://github.com/PerlDancer/Dancer2/milestones