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/