[katello-devel] Proposal: Feature Tracking and Release Planning

[Bryan Kearney]

On 11/12/2012 08:10 AM, Tom McKay wrote:
>
>
> ----- Original Message -----
>> From: "Eric Helms" <ehelms at redhat.com>
>> To: "katello-devel" <katello-devel at redhat.com>
>> Sent: Friday, November 9, 2012 6:55:04 PM
>> Subject: [katello-devel] Proposal: Feature Tracking and Release Planning
>>
>> Observations:
>>   - Users coming into IRC channel and inquiring:
>>     * When features are planned to be released
>>     * How features are being developed
>>     * How to request features
>>   - No cohesive discussions, or feature plans to point users or
>>   developers to
>>
>> Motivation:
>>
>> - Users and developers have little insight into what the project is
>> working on or targeting for next release (Roadmap is too broad -
>> https://fedorahosted.org/katello/roadmap)
>> - Users and developers have little insight into the design and
>> discussion of features
>> - There is no clear historical record of feature design
>> - Currently not easy for developers to participate in feature design
>> discussions
>>
>> Proposal:
>>
>> 1) Use Github issues to track design and implementation of features
>> 2) Use issue labels to categorize features, e.g.
>>       - R&D
>>       - Feature
>>       - Polish
>>       - Proposal
>> 3) Use milestones to align a particular set of features for next
>> release
>> 4) Keep milestones small and focused (release early, release often)
>> 5) Release when all issues aligned to a milestone are completed
>> 6) Pull requests relative to a feature can be aligned to a milestone
>> 7) Backlog milestone to track things that need to get done and
>> feature requests
>>
>> Questions:
>>
>> Q: What about timed releases?
>> A: If there are no new features, or the code base is unstable,
>> enforcing a timed release makes little sense
>>
>> Q: What if a long time has lapsed between releases?
>> A: Take the current milestone, split off the un-completed features
>> and cut a release based off the completed features to that point
>>
>>

Counter Proposal:

Mirek had already suggested a release schedule for he communtiy. Lets 
put that list on the wiki some place, and fill in what we think will be 
in the "next" item.

We can then add a better backlog page which has longer looking features.

Finally, folks can documnet on wiki pages the design which has been 
agreed upon.

This seems like it will improve visibility, and not introduce yet 
another backlog. This is a "Enforce the rules (tools) you have now, dont 
create new onnes"

-- bk