Re: [boost] Debate until Decision

Subject: Re: [boost] Debate until Decision
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-03-29 14:32:42

Hi James,

thank you for raising these important issues.

On 29.03.2018 09:29, James E. King, III via Boost wrote:
>    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.

Right.

> 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.

I generally think that a formal process such as a vote should be the
last resort, if all other attempts to build consensus fail.

> 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.

As I tried to illustrate (for example by using the Little Prince as
metaphor), there are problems that are ill-conceived to be solvable in
this manner, where it's simply impossible to get everyone to agree. This
is not a matter of process (arguments, voting, rule), but reflects that
the Boost organization as a whole may have grown too big and too
heterogeneous to move as a single entity, at least with respect to
certain questions. And since you are mentioning the ASF...

> 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"?

here is some text from its website
(https://www.apache.org/foundation/how-it-works.html):

"

In order to reduce friction and allow for diversity to emerge, rather
than forcing a monoculture from the top, the projects are designated the
central decision-making organizations of the Apache world. Each project
is delegated authority over development of its software, and is given a
great deal of latitude in designing its own technical charter and its
own governing rules.

"

which is exactly what I have been suggesting for a very long time:
Despite some efforts a long time ago to "modularize" Boost, the process
a) has long stalled and b) was confined to the realm of source code
only. But "modular structure" means much more than just to limit header
inter-dependencies ! I believe we should consider the benefits of the
Apache model, where individual projects hold "a great deal of latitude"
for most decisions (from "technical charter" to "governing rules").

In that spirit, I would like to suggest that we try to enumerate things
that a) by all means need to be decided for Boost (and its >150
libraries/projects) as a whole, and b) can be delegated to individual
subprojects.

To get the ball rolling, let me enumerate a few points I think are
important:

a) commonalities

* use of the BSL
* a shared release cycle
* a shared CDN to download release packages (source and binary), as well
as documentation
* shared branding (use of names, styles, logos)
* certain policies as far as portability and compatibility requirements
are concerned
* shared legal, administrative, and financial support (example: GSoC
participation, SFC membership)

b) delegated responsibilities

* source repository hosting
* issue tracking
* build infrastructure
* CI & testing infrastructure
* development-specific communication infrastructure

Now, to make such a split possible, there need to exist a few important
integration points that support project independence while at the same
time preserving the convenience for example of building Boost as a
single entity. So I invite you to think constructively and creatively
about ways to achieve this, before you simply point out that what I'm
proposing is impossible to handle for end-users.
It's exactly this dichotomous thinking (either we are one entity or it's
all a big mess) to got us into the current stall.

So here are a few of those "integration points" that I think are crucial
in supporting more project-wise autonomy while at the same time
facilitate collaboration and convenience for end-users:

* a common interface allowing a top-level build script to iterate over
projects, invoking independent build / test / install processes
* a documentation interface that allows projects to "plug in" their own
documentation
* a web interface that allows projects to plug in their meta information
for easy lookup (source location, bug tracker location, mailing lists, etc.)
* CI and testing infrastructure necessary for integrated testing and
release preparation

So, while there is no doubt that we need to work on our ability to
debate, and to take decisions, I strongly believe that to move forward
we need to come up with a more scalable organizational model,
where not everything needs to be agreed on by everyone. I believe there
are a number of organizations - such as the Apache Software Foundation -
which has a great deal of expertise to offer in matters such as
governance and administration. It's high time for us to learn from that.

Thanks,

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...