[dancer-users] Dancer2 Release Cycles and Feature/Bugfix Release Planning

[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

-- 
Cheers,
burnersk