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