[RFC] Rethink the voting / decision making process

[Daniel Dickinson]

<9badff72-de40-e123-d244-273c159a1c4e at mein.io>
<alpine.DEB.2.02.1606051307530.22056 at nftneq.ynat.uz>
Face:
iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEX///8AAABVwtN+AAAAeklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAOsBscAAAAASUVORK5CYII=
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2016-06-05 at 13:12 -0700, David Lang wrote: 
> On Sun, 5 Jun 2016, Jo-Philipp Wich wrote:
> 
> > Hi,
> >
> > so thinking more about it and about the input of your guys I'd propose
> > the following adjustments:
> >
> > - We define the group of voters as those people being mentioned on the
> >  about page and decouple the commit requirement, means commit access
> >  implies voting but not every voter must be a committer

I'm sure you've gathered I am for this, because I believe that important
and relevant contribution outside coding.  Obviously, as expressed by
others, avoiding bikeshedding on technical matters is important, but
that's not really only a concern for non-committing voters, but also for
voters who are not actually interested enough / have time enough to work
on the item in question themselves, but still want to make decisions
about it. 

Obviously some things are intrusive and may require a decision, but I
believe that as long as there is a policy of discouraging bikeshedding,
that most developers (or people contributing in other ways), would seek
input from other team members, anyway, and voting is really only needed
when there is major opposition to a proposed changeset or technical
design (by someone willing to implement).

I don't think that it is necessarily the case that an alternative
(unless one counts the status quo as an alternative) must be available,
if the proposed solution is sufficiently contrary to the project's
wishes.  One could perhaps have a (careful) definition of what
constitutes a purely technical matter that only committing members vote
on, on the basis that on purely technical matters the decision should be
made by those more likely to have the knowledge base to make appropriate
decisions (since I'm sure most of us disagree with the common management
myth that management doesn't need to have deep understanding of
technical issues, they just need to know how get technical people to
make arguments for and against a proposal).

> >
> > - Appointing new voters happens after a simple majority decision
> >
> > People qualifying as voters are those being publicly active in the
> > package feeds or mailing lists, regardless of whether this activity
> > happens in the form of patches or general feedback.
> >
> > It is then up to the people deciding on the appointment to judge whether
> > some suggested person qualifies.
> 
> Sounds reasonable to me.
> 
> Are you going to be looking for people to suggest themselves? or are you going 
> to be reaching out to people you think are 'active enough' to invite them?
> 
> Is it a simple majority of people who vote? or a simple majority of all voters? 
> What sort of timeframe to vote (i.e. if something doesn't get a majority in 3 
> days is it dead? or a week?)
> 
> Add these details and I think you have a good document on how lede decisions are 
> made.
> 
> > I like the idea of technical subcommittees but I am not sure whether
> > we're a big enough group for this yet - it probably makes no sense to
> > divide 13 people into several committees, for me this sounds like
> > something that should be done if the project approaches the 50-100
> > people mark.
> 
> even then, I think it's only worth splitting if you find that too many people 
> don't care enough to vote or are bothered by the admin traffic on a topic they 
> don't care about. Default to 'big tent' decisions.

Agreed.  Although I'd add that in general people should be encouraged to
solicit input and attempt to act on it without putting things to a vote,
unless there is strong reason for acting otherwise (like the suggestions
being a form of bikeshedding based on personal opinion and preference,
without really considering how much they really matter (particularly if
the suggestions involve a great deal more work)).

Regards,

Daniel