cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
Subject Re: Track feature requests in bugzilla? (was Re: DO NOT REPLY [Bug 10203] - Docs referenced by XSLT's document() are not included in cache validity)
Date Thu, 09 Oct 2003 11:03:23 GMT
Bertrand Delacretaz wrote:
> Le Jeudi, 9 oct 2003, à 12:13 Europe/Zurich, Carsten Ziegeler a écrit :
> 
>> ...And we also create a process in the following way:
>> - the wiki feature request page is scanned from time to time (the mails
>>   help there)
>> - A new entry is evaluated (perhaps the feature doesn't make sense or
>>  is a bug or is a really cool thing etc.) and if accepted added
>>   to our planning document.
>> So the planning document in our docs contains the approved list of 
>> feature
>> requests....
> 
> See what you mean, but this could also be a list of pointers to bugzilla.
> 
> IMHO if we start to use bugzilla more seriously, we will need a slightly 
> more precise categorization of issues:
> -actual bugs with different severity levels (can do)
> -patches ([PATCH] header is a hack but more or less workable)
> -feature requests
> -release-related stuff (if we want to use bugzilla dependencies to 
> prepare releases)
> -more?

+1

> Meaning that we shouldn't count just "open issues" anymore, rather "open 
> bugs", "open feature requests", "open patches" etc.
> On Monday we were focused on "total open issues" which is wrong IMHO.
> 
> I think this is easier to do in bugzilla where everything is dynamic.

IMO it's important to collect "everything" related to "open issues" in 
bugzilla and not to move the feature requests or anything else out of it to 
wiki or whereever. If bugzilla is one of the most important tools (desert 
island tools ;-) ) almost everything should be found there. I really 
wondered about the step towards wiki for feature requests.

> This might need adding more possible values to the "severity" field, 
> dunno off the top of my head how easy it is to do. Otherwise we can use 
> title headers like [RELEASE] [REQUEST] etc.

There is a "keyword" field in bugzilla. They can be defined by admins I 
think and also be queried. This is the one we use in the company too. The 
summary prefixes [XYZ] are only for better usability. You see it in a list 
to which group the issue belongs to.

> For feature requests, my suggestion would be to do so:
> -Let them come in bugzilla
> -Evaluate them often, and close the ones which seem too far away with 
> resolution=LATER
> -Explain all this on a wiki page, with links to bugzilla queries to show 
> what's current

+1

> This would help give more importance to bugzilla for planning/progress 
> monitoring stuff, which I think is good.
> And in this way we avoid the need to synchronize lists or move stuff 
> between bugzilla and the wiki.

+1000

I hate to maintain duplicate resources and to make duplicate effort.

>> ...I'm planning to "reactivate" our planning documentation in the docs 
>> section
>> so that it show more information anyway...
> 
> 
> Could be good if we're able to keep promises made there. I don't know if 
> it is realistic.

+1

Joerg

-- 
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de


Mime
View raw message