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

Subject: Re: [boost] RFC.. Steering Committee Bylaws Proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-10-19 01:26:17

> I've been fully aware of that process for a long time. That's not the
> unwritten rules I was referring to. It's all the other ones, like how they
> vote, etc.

Just because things are unwritten doesn't mean due diligence and
transparency isn't enforced.

I've had my run ins with the SC, and have more than plenty of problems
with how they work in the past. But I have never suspected incompetence,
nor unfairness. Treacle slow decision making which takes years is not
the same as being opaque and failing to communicate. It just means that
it *appears* there is little communication because it comes out in
little bits distributed over a very long time.

The cmake decision is a good example. There was no shortage of
stakeholder engagement on that decision, it just was spread out over six
months or more. Here on boost-dev many folk on here ignored the assigned
members of the SC carrying out the stakeholder engagement because they
thought it was just the usual moaning about Boost.Build vs cmake, and
the usual nothing serious would come of it. They then got shocked that
the SC actually took a decision, precisely because it's so rare, which
is because decision making takes forever.

As I said, you've got to pay attention to the SC. If you do, you'll find
they move slower than a tortoise, but they are fairly transparent, and
decisions do get taken after a few years of building the case for it.

To solve the optics problem with the SC, I have also in the past asked
for a formal decision tracking website. Some debate occurred about which
project management software to use so decisions being pondered
supreme-court-like by the SC could be subscribed to by interested
parties. No consensus was arrived at on which software to use, so
nothing happened.

> I say all of the above from my past four years of dealing with the SC.
>> If the above is inaccurate, I am sure SC members will volunteer
>> themselves to correct me.
> 
> Haha.. Given previous history.. Highly unlikely they will volunteer a
> correction ;-)

There is an intentional approx 50/50 split on the SC between library
devs and non-library devs. The non-library devs traditionally read
content here but don't post anything. The library devs who do post here
frequently tend to not post anything SC related, nor indicate that they
are on the SC.

Here are the people who do post regularly or semi-regularly here who are
currently on the Boost steering committee:

* Hartmut Kaiser
* David Sankel
* Louis Dionne
* Michael Caisse
* Peter Dimov

All these names I am sure you recognise as being regular contributors
here on boost-dev. Some of you probably didn't realise that ordinary
library devs here are half the SC.

So yes, they will volunteer a correction if I say something completely
incorrect. They just may not mention that they *are* the steering
committee when they do so. I agree that that ought to be fixed, but
equally, each SC member cannot speak for the SC without a formal vote
beforehand. Perhaps requiring SC members to say they are on the SC in
their mail footer when posting to boost mailing lists might be wise?

> There's always a third option.

Some of what you perceive as lack of transparency is really lack of
administrators. Somebody needs to operate the project management
software which tracks these decisions so people can subscribe to issues
they care about.

I've argued in the past for employing a full time admin person to
take care of this sort of stuff you can't get volunteers for. But, I
failed to build a consensus here on boost-dev for that, plus I was
unable to prove to the SC that not deciding on that would threaten the
long term future of Boost ... yada yada ... same old story.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/