[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 8: issue priorities

From: Jan Warchoł
Subject: Re: GOP-PROP 8: issue priorities
Date: Sat, 6 Aug 2011 09:13:49 +0200

2011/8/6 James Lowe <address@hidden>:
> We don't have a GOP for 'isn't there a better way to keep track of issues AND 
> upload patches' I see though.

We have, but it's not yet put on schedule.

2011/8/6 Keith OHara <address@hidden>:
> I suspect Graham meant "order in which to best keep the project moving".
> Since the project doesn't control the order in which contributors attack
> issues, that would really be "order in which the project encourages
> contributors to attack issues".

Sounds good to me.  Still, decision depends on our views about
relative importance of user needs vs. developer needs.  Theoretically,
satisfying developer needs is more important to "keep the project
moving".  However, if we follow this attitude to the extreme, there
will be less users (and potentially new decelopers) coming.

> But any interpretation of "priority" in the sense of "importance" seems
> useless.  We differ quite a lot in our opinions of importance.  I suspect
> Janek and I would rank issues in near-opposite order of importance.  That
> means that any importance-type priority estimated by the contributor who
> opens the issue, won't really help other contributors decide what to work on
> next.
> Probably, however, we would all sort issues into roughly the same types of
> problems:
> Regressions, crashes, incorrect output, ugly output, things that get in the
> way of contributing, ...
> So, all we really need to do is make useful classifications, and admit that
> we won't all agree on their relative priorities.

This sounds a bit like "let's drop 'priority' field and use labels only" :)

> Users and new contributors will interpret priority as importance, though,
> and will naturally want their favorites to be higher on the list.
> That's why I suggested putting issues where we don't know exactly what
> Lilypond should do, as "Postponed".  Obviously we can't program the behavior
> until we know what we want it to be, and that motivates users (who might
> know their area of notation better than we do) to think through what they
> want.

Hmm.  Interesting point of view.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]