Debate until Decision

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Debate until Decision

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Debate until Decision

Boost - Dev mailing list
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...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Debate until Decision

Boost - Dev mailing list
On 29 March 2018 at 16:32, Stefan Seefeld via Boost
<[hidden email]> wrote:

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

There is one additional detail that is important to understand this model

https://www.apache.org/foundation/

"
Individual Apache projects are in turn governed directly by
Project Management Committees (PMC) made up of individuals
who have shown merit and leadership within those projects.
"

IMHO, modularisation of Boost eco-system should be followed by
agreement to establish such PMC or PSC (Project Steering Committee).

Actually, the CMT may be seen as a forerunner for such initiative.

> b) delegated responsibilities
> [...]

Could be taken over by each PSC.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Debate until Decision

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Mateusz
> Loskot via Boost
> Sent: Thursday, March 29, 2018 6:18 PM
> To: [hidden email]
> Cc: Mateusz Loskot <[hidden email]>
> Subject: Re: [boost] Debate until Decision
>
> IMHO, modularisation of Boost eco-system should be followed by
> agreement to establish such PMC or PSC (Project Steering Committee).
>
> Actually, the CMT may be seen as a forerunner for such initiative.
>
> > b) delegated responsibilities
> > [...]
>
> Could be taken over by each PSC.
>

Are individual boost libraries actually big enough projects to warrant such a committee? My impression was that most libraries are mostly just one man/woman projects and I don't se, why you need a committee for that.

> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Debate until Decision

Boost - Dev mailing list
On 31 March 2018 at 16:24, mike via Boost <[hidden email]> wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Mateusz
>> Loskot via Boost
>> Sent: Thursday, March 29, 2018 6:18 PM
>> To: [hidden email]
>> Cc: Mateusz Loskot <[hidden email]>
>> Subject: Re: [boost] Debate until Decision
>>
>> IMHO, modularisation of Boost eco-system should be followed by
>> agreement to establish such PMC or PSC (Project Steering Committee).
>>
>> Actually, the CMT may be seen as a forerunner for such initiative.
>>
>> > b) delegated responsibilities
>> > [...]
>>
>> Could be taken over by each PSC.
>>
>
> Are individual boost libraries actually big enough projects to warrant such a committee?

Some are, with at least 2-3 active core maintainers, and some are certainly not

> My impression was that most libraries are mostly just one man/woman projects and I don't se, why you need a committee for that.

A committee with benevolent dictator as a sole member should be fine
too, why not.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Debate until Decision

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
This is an interesting discussion.

> On 29. Mar 2018, at 16:32, Stefan Seefeld via Boost <[hidden email]> wrote:
>> 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.

"Consensus" sounds good, but what does it mean in practice? I think decisions that affect boost as a whole cannot be made in a way that makes everyone happy. As James said, if you have a heterogenous group with varying backgrounds, it is natural that not everyone will fall on the same side even after extensive discussion. Still decisions have to be made.

Letting the maintainers vote on global boost issues after a proper discussion sounds like a good idea. In the end, that's how the review process for new libraries works. It is a sensible process, so why can't it be used to make all kinds of decision?

There are not many systems for making group decisions that actually work in practice. You basically have the choice between democracy, oligarchy, and monarchy. Letting the maintainers vote is a democratic meritocracy, I think many of us are fine with this.

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost