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