Re: [boost] RFC.. Steering Committee Bylaws Proposal

Subject: Re: [boost] RFC.. Steering Committee Bylaws Proposal
From: Rob Stewart (rstewart_at_[hidden])
Date: 2017-10-22 23:44:18

On October 19, 2017 7:47:09 PM EDT, Stefan Seefeld via Boost <boost_at_[hidden]> wrote:
> On 19.10.2017 17:49, Niall Douglas via Boost wrote:
> 
> * What is the relationship between the Boost organization and its
> member projects ?

There are no member projects. There are libraries with their own authors and maintainers, but they aren't independent of Boost.

> * What decisions are to be made by projects, and what by the
> organization ?

Authors and maintainers can make most any design and implementation decisions, but directory layout, tooling, etc. are centrally controlled for uniformity.

> * How are conflicts between the two entities resolved ?

Discussion on this list. If there's an impasse, the Steering Committee might be *asked* to step in.

> As long as we don't find clear answers to the above we aren't going to
> get out of the current stall.

The problem seems to be that you think there is more structure than exists.

> > There is no one discussion place. Some of it happens face to face at
> a
> > conference. Some happens when Jon skypes you out of the blue. Some
> > happens by private email. Some happens on the boost-steering mailing
> > list. Some happens on Slack.
> >
> > I absolutely agree that this stuff should be encoded into a formal
> > process. But once again, *somebody* has to admin formal processes.
> And
> > we have no somebody dedicated to doing admin. So it gets done ad
> hoc,
> > and not always to the highest quality. Nobody professional is being
> > employed to solely dedicate their time on making formal processes
> happen.
> I'm not sure how formal the process needs to be, as long as it is
> transparent. Private communication (including channels that aren't
> publicly archived) should be discounted, at least as far as
> audit-trailing the decision-making process is concerned. Read: any
> formal decision needs to be based on a "process" that can be followed
> publicly, such as via a mailing list archive.

Dave Abrahams and Beman started the Steering Committee because it became necessary to have a legal entity to commit funds and because it seemed that Boost had outgrown the moderator-based management structure it had used to that point.

From the start, the Steering Committee was intended to be mostly hands off because Boost had made all decisions on this list or, in limited cases, behind the scenes via the moderators. That's why the SC rarely acts without receiving a formal proposal for something.

Perhaps it's time for a different sort of governance, but it must come from the community as a proposal.

> Having well-documented "success stories" (i.e., past decisions that
> had
> a positive effect for the community) would likely help attract
> volunteers.
> On the contrary, the past debacle surrounding the B2 / CMake
> "decision"
> certainly had the opposite effect: a decision almost out of the blue,
> which is unlikely to have the intended effect. That doesn't seem very
> attractive to me.
> What's needed is a healthy dose of pragmatism (a good sense of what
> decisions can be made that will be supported by everyone), with the
> willingness to seek and build consensus, rather than operate in
> obscurity.

If you submit a proposal for how Boost should be managed, and you get wide support for it, including sufficient volunteers to be part of that governing body (or bodies), there should be little trouble making the desired change. If the proposal is vague, incomplete, or lacks sufficient volunteer support to ensure a reasonable transition and no loss of required governance, then it will be rejected.

If your only action is to complain about what does or doesn't exist, or what is or isn't done, nothing will happen.

--
Rob
(Sent from my portable computation device.)