Re: [Fresco-devel] issue tracking: Request For Comments

Russell Neches wrote:

> Pending / Working on it - a developer has noted the existence and
> reality of the bug and has put it in his/her proverbial in-box. They
> are currently thinking of and/or implementing a solution. A fix is
> imminent.
> 
> Open - the bug has been accepted into the BTS, but no action has been
> taken. Default status after a bug has been submitted. 
> 
> Later - a developer has noted the existence and reality of the bug,
> but has set it aside. Perhaps they expect that it will be fixed by a
> larger effort not directly related to the specific bug. 

I agree that it's good to signal that a bug has been reviewed and 
accepted by someone. I would consider an 'open' bug one that is accepted
and being worked on, instead of a new submission that waits reviewing.
May be 'new' would be good for the latter state...

> Reopened - while not functionally different from simply "opened," it
> may be deemed psychologically useful to note that this is another
> go-around with the problem. The idea, I suppose, is to discourage
> half-hearted fixes and encourage developers to be reticent when
> closing a bug. IE - "did I really fix it?"

you mean 'reopened' shows that the developer who closed it before did
a bad job ? Well, educational devices apart, I still believe all 
information is still available through an issue's history record. We
don't need a state for that.


[...]

> Clearly, one needs to tailor the BTS fit to the project. That's a
> non-trivial matter, IMHO. It's also important to make it fit the work
> habits of the people who are actually going to use it (NOT the other
> way around!). Various people have different ideas about work and time
> management, so you want your workflow system (in this case, a BTS) to
> act as a buffer between different personalities. 

you are totally right. It's all a matter of managing the development
process. As such, we could start simple and then add new 
entities/attributes as we need them. Luckily, roundup seems to allow
changes of the schema with running databases. I didn't figure out
all the details about how such a transition would work though...

Quite frankly, the most interesting feature I'm looking for right now
are the tasks. I want to put a lot of the feature requests / discussion
into an issue tracker to be able to better manage (and show !) whether
and how fresco is making progress. Right now you really need to be part
of the core developers to actually see that something changed, which is
pretty frustrating for everybody.

Regards,
		Stefan