Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Getting agreements

Re: Getting agreements

From: Antony Stone <Antony.Stone_at_rockbox.open.source.it>
Date: Sat, 9 Oct 2010 20:22:55 +0200

On Saturday 09 October 2010 at 17:15, Paul Louden wrote:

> In terms of objections, thought, you also need to be careful. With
> "reasons specified for the negative vote" then you'll just get into an
> argument over whether the reasons specified are valid or not. Is "this
> feature could be implemented better, and if it goes in this way, it will
> never be reimplemented as the better way" a valid reason? Some would say
> "yes, if we know a better way, we should use the other way." Others
> would say "no, someone else can reimplement it, but it's good enough
> that we should get it to users now" and you have another circular argument.

Given that sort of scenario (which I can easily see occurring), how about
agreeing that this situation causes the feature to be deferred (not thrown
out, just deferred until the next major release), and then if there's a
better implementation by the next release date, it gets taken instead. If
there isn't, the proposed implementation gets used and the above objection is
not sufficient reason to reject it.

> If people can be for an idea because "I like it" then people should be
> allowed to be against an idea because "I don't feel it's right for
> Rockbox" without any more objective reason for not including it than the
> other side has for wanting to include it.

I'm not so sure about this. If someone likes a feature and is prepared to put
in the time and effort to implement it, there are bound to be users who like
it too.

I think if someone wants to object to a feature being implemented (and
basically tell someone not to put in the time they are prepared to put in to
implement it), they should have to say "it's a bad feature because...". Of
course, valid reasons can include "uses too much memory", "doesn't fit in
with existing features" etc.

Then if more people agree with the objection than agree with the feature being
implemented, it gets abandoned. The clearer the argument for rejecting, and
the better the reason/s, the more likely it is that the feature gets thrown
out, just as the clearer and better the argument for including it, the more
likely it is to be adopted.

> That being said, if an objector wishes to state their reasons as an opening
> for the other side to win them over / remove their veto, it's fine. I think
> *most* of the time, people are going to object to things for specific
> perceived problems with it. And the times when someone just thinks "this
> does not belong, period" if it really does benefit the project there will be
> enough in favor of it that it won't matter that one or two people have
> their heels dug in over it.

Yes, I think it's important that no single person can absolutely veto an idea
(unless there's only one person in favour of it, of course). There has to be
a consensus, and the more people contributing to the decision, the better.

Antony.

-- 
"It would appear we have reached the limits of what it is possible to achieve 
with computer technology, although one should be careful with such 
statements; they tend to sound pretty silly in five years."
 - John von Neumann (1949)
                                                     Please reply to the list;
                                                           please don't CC me.
Received on 2010-10-09

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa