Onwards!

Christian Stimming stimming at tuhh.de
Tue Dec 28 16:44:30 EST 2010


Am Dienstag, 28. Dezember 2010 schrieb John Ralls:
> > I think, the roadmap should show the general direction, while RFEs in
> > bugzilla can also be small details. I often add entries there, which I
> > would like to improve later, may be next year. I would miss the
> > reminder, if they would be closed, because they do not fit in the
> > roadmap.

I think bugzilla leaves it up to the project to define what the semantics of 
such an enhancement request is. (That's different from a bug, which either is 
a bug or it's not in bugzilla.)

That's an open question: What should we answer to enhancement request that 
nobody of us wants to implement in the near future? Does closing mean this 
item will never be done? Of course not - future priorities of the existing 
developers or future developers might lead to its implementation. But then 
again, what should the list of open enhancement requests represent? Can we 
agree on some signal that says "None of use will currently do this"? Like, 
priority=low for those and only those? If such a signal is not possible, I 
would rather deny those items now and clear. But if such a signal is possible, 
I'm fine with that and I will quickly use it for everything where I'm assignee 
and I decide not to work on this in the near future.

> As for your personal to-do list, perhaps you could assign them to yourself.
> The three recent ones (that were waiting for the string freeze to lift)
> can be committed now.

I agree with John here: If you have items there which you consider on your 
personal to-do list, please assign them to yourself.

> Going in the other direction, once we agree on the roadmap for the next
> version and who's going to do what, we can break each major task into a
> bunch of enhancements and set a developement release as the target. That's
> probably as close to project management as we're likely to get.

Yep. Let's see what the roadmap shows as major new tasks...

Regards,

Christian


More information about the gnucash-devel mailing list