[boost] Debate until Decision

Subject: [boost] Debate until Decision
From: James E. King, III (jking_at_[hidden])
Date: 2018-03-29 13:29:56

I'm going to float some thoughts about how the group makes decisions
below.  I'm not suggesting a specific course of action, but I would like
people to think about how these ideas can be used to improve Boost
development.

Recent discussions about default address-model, and past discussions about
issues like cmake and CI build improvements (like whether or not to
purchase more build slaves from travis or appveyor), and topics about legal
use of code snippets leads me to the following conclusion:

   1. We are geographically, culturally, and vertically distributed and
   have highly varying viewpoints.
   2. We are all very good at expressing our viewpoint about various topics.
   3. We collectively need to improve our skill at coming to a group
   decision and moving forward.

Folks generally have individual control over their respective maintained
repositories in the current structure.  There are many topics that
generally affect all of the repositories, such as the ones I mentioned
previously, that affect all of us.  At my most recent startup company we
implemented an effective "Debate until Decision" mechanism by which:

   1. The issue is discussed.  (We do this well)
   2. A decision is made and implemented (We do not seem to do this well):

   Not everyone will be happy with the outcome.
   Folks should not attempt to undermine the outcome after decision.
   The issue can be raised again if new information is brought to light.

How is a decision made?  Typically in a meeting where people vote
face-to-face.  For a group like this, voting would be done online with a
time limit.

Who can vote?  That's a good question.  In this environment it may fall to
the group of folks who are maintainers of an affected repository.  I don't
necessarily have a good answer for that, as I am relatively new to the
group.  Some folks have been here for 10+ years and may feel differently
that seniority should have a say.  I don't know.

What are the benefits of this?  Simply:

*Things get done.*

Look at the cmake discussion, or the CI build job discussion, or the
current address-model discussion.  These need to be finished, agreed to,
and implemented (or not), and everyone moves forward.

The Apache Software Foundation maintains a fairly well documented structure
for each project, with a project management committee consisting of a chair
and members who have equal voting rights, however said group's primary
function is to identify and grow the team of developers who have commit
privileges.  The committers as a whole vote on issues that are
project-wide, like "should we split into multiple repositories", or "should
we move to another source code control environment"?

This mechanism could also be applied to how folks are brought into
maintainer status for a repository, or how a library enters the CMT.  If
you look at the bug backlog in trac for some one the libraries, it's pretty
clear that they are not properly maintained.  The issue may be discussed,
but then dropped and forgotten, and no action is taken to remedy it.  When
repositories have pull requests open for years, or a backlog of 100 defects
going back 10 years, there's a very unhealthy problem for that project that
needs to be addressed.

It may be a similar structure that will work well here.  Folks may
disagree.  This will be debated, certainly, as folks probably have varying
opinions about how much structure is needed or desired.  I simply hope this
leads to an effective discussion about how this group identifies
deficiencies, solves them, and moves forward.  Any group large or small can
benefit from examination and improvement of processes, including ours.

Thanks,

Jim