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

[burnersk]

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