Rockbox mail archiveSubject: 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
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.
-- "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