Re: [Gnumed-devel] Re: Launchpad Blueprints vs Bug vs Wiki todo-list

[James Busser]

On 15-Sep-08, at 12:50 AM, Gour wrote:

> James> We will be fine without the feature until the blueprints exceed
> James> one screen worth, however this will result if we map items from
> James> the wiki ToDo so...
>
> Good.
>
> Is it maybe better to submit it as bug report or you consider  
> blueprint
> is OK?

My idea was that in addition to bugs going into LP Bugs, various  
other items (among ToDos and Proposals) can go into Bugs *or*  
Blueprints depending on their length and their value in being further  
documented.

For requests like changing default behaviour, or adding values, or  
other things even though they are not bugs, but which are self- 
explanatory, I suggest we add these to Bugs.

Items which are longer, which would benefit from any evolution of  
discussion and solution design whose status may be worth keeping  
tracked, and whose implementation will require more time and steps,  
and which benefits from having its description and specification  
maintained somewhere else (e.g. wiki) should be put into Blueprint,  
which supports the two status attributes (state of agreement on  
design, and state of implementation), and holding an external  
reference URL.

(Bugs does have one extra attribute, "Milestone", which may be  
helpful to target if certain bugs *must* be fixed as part of certain  
releases, or whether other bugs (which are wishlist items) should be  
targeted for something later. One approach could be

- default milestone would be current major version of gnumed-client +  
"x" e.g. 0.3.x given it is reasonable that the auto-generated things  
should likely get fixed within the major version. Anything that is  
wishlist which cannot realistically be in view for 0.3.x can be  
deferred to 0.4.x. Among the 0.3.x bug items, any being currently  
worked-on could be set to "current" and when the bug is committed its  
Milestone can be set to the upcoming release (0.3.3) if it is useful  
to make it easy to know which version is needed to escape the bug or  
to gain the feature.