RFC.. Steering Committee Bylaws Proposal
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1]. The Bylaws hopefully address some key issues that I feel are at the core of the current problems: * Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2]. [1] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/Boost%20Steering%20Committee%20Bylaws.md> [2] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/2011-05-20%20Boost%20governance%20annotated.pdf> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 16.10.2017 07:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems.
One particularly contentious issue I see is related to the committee's mandate: what decisions are in scope for the committee, and how are conflicts resolved, should they arise ? I believe this question is even bigger than just about the Steering Committee and its mandate; it is about the very nature of the Boost organization, in relation to its member projects, and in particular, how projects as well as the entire organization are governed, how decisions are being made, etc. (To take a recent conflict: is it really the committee's mandate to impose what tools individual projects have to use ?) I don't see any of these (or related) questions being addressed anywhere. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, Oct 16, 2017 at 10:27 PM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On 16.10.2017 07:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems.
One particularly contentious issue I see is related to the committee's mandate: what decisions are in scope for the committee, and how are conflicts resolved, should they arise ?
Right.. But right now there is nothing to resolve conflicts. Or rather, we have one, we can ignore what the Committee says. After all there's nothing now, or in these bylaws, that says we have to "do as we're told". I believe this question is even bigger than just about the Steering
Committee and its mandate; it is about the very nature of the Boost organization, in relation to its member projects, and in particular, how projects as well as the entire organization are governed, how decisions are being made, etc.
Indeed. And ultimately the question is do we want to build a Committee that manages such things, or not. If it's the former we need some mechanism for doing the building. If it's the later... We will have to come up with some other mechanism and abandon the Committee.
(To take a recent conflict: is it really the committee's mandate to impose what tools individual projects have to use ?)
The mandate was never really all that clear in terms of where the lines where. And the original formation meant for something more than just existing to happen to the Committee, as far as I understand what happened. So I guess it's really up to us. I don't see any of these (or related) questions being addressed anywhere.
There is no way those question can be addressed with this first step. But att least with the bylaws we can amend them and possibly address them over time. Thank you for the feedback :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 17.10.2017 00:09, Rene Rivera via Boost wrote:
On Mon, Oct 16, 2017 at 10:27 PM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On 16.10.2017 07:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. One particularly contentious issue I see is related to the committee's mandate: what decisions are in scope for the committee, and how are conflicts resolved, should they arise ?
Right.. But right now there is nothing to resolve conflicts. Or rather, we have one, we can ignore what the Committee says. After all there's nothing now, or in these bylaws, that says we have to "do as we're told".
I believe this question is even bigger than just about the Steering
Committee and its mandate; it is about the very nature of the Boost organization, in relation to its member projects, and in particular, how projects as well as the entire organization are governed, how decisions are being made, etc.
Indeed. And ultimately the question is do we want to build a Committee that manages such things, or not. If it's the former we need some mechanism for doing the building. If it's the later... We will have to come up with some other mechanism and abandon the Committee.
I agree. My point is that before we can discuss organizational structure and bylaws we need to find consensus as to what that structure should help us achieve, and what mandate such a committee should have. I like the idea of looking at other organizations, and asking the SFC for advice on the matter. (For avoidance of doubt: I'm not suggesting to start over from scratch: Boost has a long history, and the Steering Committee has provided excellent service over the years. Let's build on that !) Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Oct 17, 2017 at 6:44 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On Mon, Oct 16, 2017 at 10:27 PM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:
On 16.10.2017 07:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. One particularly contentious issue I see is related to the committee's mandate: what decisions are in scope for the committee, and how are conflicts resolved, should they arise ?
Right.. But right now there is nothing to resolve conflicts. Or rather, we have one, we can ignore what the Committee says. After all there's nothing now, or in these bylaws, that says we have to "do as we're told".
I believe this question is even bigger than just about the Steering
Committee and its mandate; it is about the very nature of the Boost organization, in relation to its member projects, and in particular, how projects as well as the entire organization are governed, how decisions are being made, etc.
Indeed. And ultimately the question is do we want to build a Committee
On 17.10.2017 00:09, Rene Rivera via Boost wrote: that
manages such things, or not. If it's the former we need some mechanism for doing the building. If it's the later... We will have to come up with some other mechanism and abandon the Committee.
I agree. My point is that before we can discuss organizational structure and bylaws we need to find consensus as to what that structure should help us achieve, and what mandate such a committee should have.
I'm sure I don't have the time to drive such an effort to design en elicit such organizational consensus.
I like the idea of looking at other organizations, and asking the SFC for advice on the matter.
How should we ask the SFC for advice? Whom should ask? I'm asking because the recent mechanism for this is to ask the SC to ask the SFC.
(For avoidance of doubt: I'm not suggesting to start over from scratch: Boost has a long history, and the Steering Committee has provided excellent service over the years. Let's build on that !)
Perhaps.. But at some point starting from scratch will happen anyway if nothing gets done. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 16/10/2017 12:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
I dislike the proposed structure. It has no separation of powers. I also believe it is impossible under charity regulations, though the SFC lawyers can say for sure. If you're going to propose bylaws, my original proposal whereby the existing Steering Committee becomes a "Board of Directors" and a new Steering Committee made up of elected library authors is far more conventional. The Board of Directors would be limited to managing the finances, but can also dissolve the Steering Committee and call for a new election (one would expect this only to occur if the Steering Committee did something illegal like embezzle money). The new Steering Committee takes on all other responsibilities apart from the finances, and is elected from here on two year terms. This new Steering Committee would "run" Boost on a day to day basis. The Board of Directors runs BoostCon and the other "once off" stuff, and continues to deliberately be made up of mostly *non* Boost library authors. This separation of powers is how most charity based orgs are run. I'd strongly recommend you don't innovate on that. I also think that despite my many run-ins with the Steering Committee over the years, having not library authors in control of the money is a wise idea. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Oct 16, 2017 at 11:00 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 16/10/2017 12:35, Rene Rivera via Boost wrote:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
I dislike the proposed structure. It has no separation of powers. I also believe it is impossible under charity regulations, though the SFC lawyers can say for sure.
If you're going to propose bylaws, my original proposal whereby the existing Steering Committee becomes a "Board of Directors" and a new Steering Committee made up of elected library authors is far more conventional.
The Board of Directors would be limited to managing the finances, but can also dissolve the Steering Committee and call for a new election (one would expect this only to occur if the Steering Committee did something illegal like embezzle money). The new Steering Committee takes on all other responsibilities apart from the finances, and is elected from here on two year terms. This new Steering Committee would "run" Boost on a day to day basis. The Board of Directors runs BoostCon and the other "once off" stuff, and continues to deliberately be made up of mostly *non* Boost library authors.
This separation of powers is how most charity based orgs are run. I'd strongly recommend you don't innovate on that.
Thank you for volunteering to make a formal proposal. I look forward to studying it.
I also think that despite my many run-ins with the Steering Committee over the years, having not library authors in control of the money is a wise idea.
Why? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
El oct. 16, 2017, a las 04:35, Rene Rivera via Boost <boost@lists.boost.org> escribió:
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems.
This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2].
When buildbot joined the SFC, one of the requirements (and service!) that SFC had was to help create a board together with all the rules. Since boost is also a member of the SFC, did it do the same? If so, wouldn't that board already have rules and regulations? Or is that body distinct from the one called "Steering Committee"?
[1] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/Boost%20Steering%20Committee%20Bylaws.md> [2] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/2011-05-20%20Boost%20governance%20annotated.pdf>
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, Oct 17, 2017 at 1:34 AM, Jared Grubb <jared.grubb@gmail.com> wrote:
When buildbot joined the SFC, one of the requirements (and service!) that SFC had was to help create a board together with all the rules.
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
If so, wouldn't that board already have rules and regulations? Or is that body distinct from the one called "Steering Committee"?
AFAIK there is nothing except the SC. Maybe the SFC assumed that the SC had appropriate rules. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On Wed, Oct 18, 2017 at 5:48 PM, Rene Rivera via Boost < boost@lists.boost.org> wrote:
On Tue, Oct 17, 2017 at 1:34 AM, Jared Grubb <jared.grubb@gmail.com> wrote:
When buildbot joined the SFC, one of the requirements (and service!) that SFC had was to help create a board together with all the rules.
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
Indeed, I've never heard of that, nor know what the SFC is in fact. Could someone please elaborate? I guess this is the kind of things one hears about at BoostCon only? Thanks, --DD
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
Indeed, I've never heard of that, nor know what the SFC is in fact. Could someone please elaborate? I guess this is the kind of things one hears about at BoostCon only? Thanks, --DD
The SFC can be found at https://sfconservancy.org/ Boost is by far the wealthiest member of the SFC, and as part of the SFC it falls under US non-profit law. Therefore you cannot just set new by laws or change the SC's configuration without undergoing the formal legal process as established under US non-profits regulations. The bylaws you suggested earlier I believe are illegal under US charity law. As I suggested, you need to add separation of powers and you'd stand a much better chance of the SFC's lawyers okaying it. As considerable sums of money are involved, fiduciary duty is very important here, else the US IRS would correctly assess tax non-compliance may be at work. You might consider listening to the advice being given to you on this. Some of us went down that rabbit hole many years ago. We may have even nearly achieved getting some formal by laws written down, we were just short on the SC votes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, Oct 18, 2017 at 9:03 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Boost is by far the wealthiest member of the SFC, and as part of the SFC it falls under US non-profit law.
For the record, several months ago I advised a member of the Boost Steering Committee to exchange all of the organization's US-dollar denominated liquid assets for Bitcoin back when the price was around $1,000: <https://coinmarketcap.com/currencies/bitcoin/#charts> Thanks
On 18-10-17 18:09, Vinnie Falco via Boost wrote:
On Wed, Oct 18, 2017 at 9:03 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Boost is by far the wealthiest member of the SFC, and as part of the SFC it falls under US non-profit law. For the record, several months ago I advised a member of the Boost Steering Committee to exchange all of the organization's US-dollar denominated liquid assets for Bitcoin back when the price was around $1,000:
<https://coinmarketcap.com/currencies/bitcoin/#charts>
Thanks
I'm unable to work out what point you are making. Did they convert, and hence the relative wealth? Or was it sarcasm because they didn't follow your advice?
On Tue, Oct 24, 2017 at 12:12 AM, Seth via Boost <boost@lists.boost.org> wrote:
I'm unable to work out what point you are making. Did they convert, and hence the relative wealth? Or was it sarcasm because they didn't follow your advice?
Neither, I'm just making the sentiment more public. I don't think anyone converted.
On 24-10-17 14:25, Vinnie Falco via Boost wrote:
Neither, I'm just making the sentiment more public. I don't think anyone converted.
My gut says, investing in bitcoin is investing, which implies taking risk. I doubt that's the mandate of any charity/non-profit. They might outsource it, obviously. Like anyone else. Or donations could be made in bitcoin :) Seth
On Wed, Oct 18, 2017 at 11:03 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
Indeed, I've never heard of that, nor know what the SFC is in fact. Could someone please elaborate? I guess this is the kind of things one hears about at BoostCon only? Thanks, --DD
The SFC can be found at https://sfconservancy.org/
Boost is by far the wealthiest member of the SFC, and as part of the SFC it falls under US non-profit law.
Therefore you cannot just set new by laws or change the SC's configuration without undergoing the formal legal process as established under US non-profits regulations.
Right.. But technically Boost nor the SC are legal organizations under any laws. It's the SFC that's the legal organization.
The bylaws you suggested earlier I believe are illegal under US charity law.
Easily resolved by changing the name to "Rules and Policies". And no they aren't meant to be legal from as self organized corporation. After all it's a committee not a board. As I suggested, you need to add separation of powers and you'd
stand a much better chance of the SFC's lawyers okaying it.
The separation is already there. There's the SFC and the SC. For every monetary decision that the SC makes the SFC still needs to approve it. As considerable sums of money are involved, fiduciary duty is very
important here, else the US IRS would correctly assess tax non-compliance may be at work.
Which is why the SFC does due diligence to make sure the SC doesn't run afoul of those laws and of its own by-laws and policies. You might consider listening to the advice being given to you on this.
What makes you think I didn't consider the advice? After all I can consider the advice and not follow it.
Some of us went down that rabbit hole many years ago. We may have even nearly achieved getting some formal by laws written down, we were just short on the SC votes.
That's news to me. And I suspect that's news to almost everyone else here. This is key problem to the current arrangement. Do you see how that is contrary to the original goals of the SC. When did that happen? Before or after joining the SFC? Where did it happen? How many votes did you need? How many votes did you get? What was concretely proposed? What did the proponents say? What did the detractors say? And ultimately.. Why do we need to even ask questions as to what the SC does? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Right.. But technically Boost nor the SC are legal organizations under any laws. It's the SFC that's the legal organization.
Boost is a legal entity registered under US tax law. It falls under the SFC umbrella as a "division" of sorts. Our monies are held separate to others and must be spent according to the rules specified by US non-profit law. How members of the steering committee are changed, who is appointed legally in charge of the bank accounts, all of this is dictated by law which is to say the rules initially submitted when the SC was first created.
The bylaws you suggested earlier I believe are illegal under US charity law.
Easily resolved by changing the name to "Rules and Policies". And no they aren't meant to be legal from as self organized corporation. After all it's a committee not a board.
The SC can vote to change its own rules if it follows correctly its rules for changing its rules. But it cannot change those roles to be non compliant with US non-profit law. Otherwise it must change from a non-profit to a for-profit. That would be expensive.
As I suggested, you need to add separation of powers and you'd
stand a much better chance of the SFC's lawyers okaying it.
The separation is already there. There's the SFC and the SC. For every monetary decision that the SC makes the SFC still needs to approve it.
The SFC have no power to spend Boost money without express, written approval from the body with the legal fiduciary duty: the steering committee. Trust me on this, I've gone multiple weeks waiting on the SC to greenlight the SFC to do stuff. The SFC purely provide admin at the behest and instruction of the Boost SC. They are Boost's "civil service" if you like. We outsource admin to them, and we could theoretically dismiss them and replace them at any time. Indeed that very act was once discussed for various reasons no longer important.
As considerable sums of money are involved, fiduciary duty is very
important here, else the US IRS would correctly assess tax non-compliance may be at work.
Which is why the SFC does due diligence to make sure the SC doesn't run afoul of those laws and of its own by-laws and policies.
The SFC may choose to advise the SC of the non-wisdom of a course of action because it may cause trouble with the IRS, or be illegal, or simply not how other open source orgs do things. The SC may choose to ignore them. The SC is the one in charge from a legal point of view.
Some of us went down that rabbit hole many years ago. We may have even nearly achieved getting some formal by laws written down, we were just short on the SC votes.
That's news to me. And I suspect that's news to almost everyone else here.
I've done lots of stuff boost-dev isn't aware of. Indeed, lots of stuff that some on the SC aren't aware of. Believe it or not, I don't go advertising my service loudly seeking approval, despite what some may think. Most of it has occurred quietly, out of sight.
This is key problem to the current arrangement. Do you see how that is contrary to the original goals of the SC. When did that happen? Before or after joining the SFC? Where did it happen? How many votes did you need? How many votes did you get? What was concretely proposed? What did the proponents say? What did the detractors say?
And ultimately.. Why do we need to even ask questions as to what the SC does?
The SC has a clearly spelled out "mission statement" on its home page. That statement was written, incidentally, because I complained there was none. For the record, I entirely and absolutely agree with you that there is a governance problem at work here. Some years ago I tried to persuade the SC to reform itself, and a vote was held. My initiative lost, but that was a very different SC back then. The current SC has a lot of new members with very different viewpoints to previous SCs (and I'll be honest, much more aligned with my opinions on things). If the proposal were retabled, I think you'd have a good chance of getting it through. But you need to take a very different approach to the one you are taking. I know this will sound rich coming from me, but you are being too confrontational. Proposing a set of bye laws from outside the SC is confrontational. You should instead ask the SC for a formal vote on whether, in principle, it agrees with the establishment of bye laws splitting governance into two arm's length groups, one appointed, one elected. Start with that first. If they vote approval, then I am very sure that certain members of the SC will self initiate dialogue with all relevant stakeholders to *collaboratively* draw up a set of bye laws. Rather than you writing a set on your own. Those, once agreed, would then need another vote from the SC and legal review by the SFC. This is the process I think you ought to take. Less confrontational, more inclusive of all stakeholders, and let the SC do its job of steering instead of you trying to steer it. I say all of the above as someone with very considerable experience in interacting with the SC over many years. You'll find them usually reasonable *IF* you follow their established processes, which I just described to you above. You also need to accept that changing governance will take considerable personal effort invested over a long period of time. Lots of cats to herd. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wednesday, October 18, 2017, Niall Douglas wrote:
But you need to take a very different approach to the one you are taking. I know this will sound rich coming from me, but you are being too confrontational. Proposing a set of bye laws from outside the SC is confrontational.
The SC asked Rene to do this, didn't they? i.e. His help was solicited at CppCon. That said, nothing in Rene's e-mail came across as particularly confrontational. Glen
On Wed, Oct 18, 2017 at 12:46 PM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:
On Wednesday, October 18, 2017, Niall Douglas wrote:
But you need to take a very different approach to the one you are taking. I know this will sound rich coming from me, but you are being too confrontational. Proposing a set of bye laws from outside the SC is confrontational.
The SC asked Rene to do this, didn't they? i.e. His help was solicited at CppCon.
Correct. It went like this: * I arrived at the conference, happy to be distracted from seriously bad stuff that was happening to me personally. And really intent on not thinking about Boost much. * I was cornered (my entrance badge was held hostage) into talking to certain SC people to reconcile. I had a bunch of drinks that made that experience tolerable. * I was happily enjoying the conference. And having some interesting discussions about build systems and the C++ ecosystem, thanks to Izzy for fueling some of that :-) * I was asked to have a discussion as to moving forward with cmake. I spoke maybe 6 words in that conversation. * I was asked to talk with other SC members about the concerns that the cmake decision raised in how that decision was made. * I pointed out my, and others, concerns about the lack of transparency and lack of involvement. And I mentioned that in other organizations such rules are written down in documents like by-laws. * They asked me to write up some by-laws for them to consider. * I spent two weeks of some spare time doing that. And then getting some private proofreading on that result. * I then posted them here. Because I believe that we should discuss such things in public before proposing them to the SC for consideration. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On Wed, Oct 18, 2017 at 11:59 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Right.. But technically Boost nor the SC are legal organizations under any laws. It's the SFC that's the legal organization.
Boost is a legal entity registered under US tax law. It falls under the SFC umbrella as a "division" of sorts. Our monies are held separate to others and must be spent according to the rules specified by US non-profit law. How members of the steering committee are changed, who is appointed legally in charge of the bank accounts, all of this is dictated by law which is to say the rules initially submitted when the SC was first created.
I have to say.. Finding this stuff out now is rapidly decreasing my confidence in the SC and the operation of Boost. It's a sad situation. And I'm worried this is just going to implode. I'd really like to find out what the rules truly are and what is going on. This is horribly saddening :-( (cut the rest as to not over-quote.. but my comment applies to the whole email) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
El oct. 18, 2017, a las 11:17, Rene Rivera via Boost <boost@lists.boost.org> escribió:
On Wed, Oct 18, 2017 at 11:59 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Right.. But technically Boost nor the SC are legal organizations under any laws. It's the SFC that's the legal organization.
Boost is a legal entity registered under US tax law. It falls under the SFC umbrella as a "division" of sorts. Our monies are held separate to others and must be spent according to the rules specified by US non-profit law. How members of the steering committee are changed, who is appointed legally in charge of the bank accounts, all of this is dictated by law which is to say the rules initially submitted when the SC was first created.
I have to say.. Finding this stuff out now is rapidly decreasing my confidence in the SC and the operation of Boost. It's a sad situation. And I'm worried this is just going to implode. I'd really like to find out what the rules truly are and what is going on. This is horribly saddening :-(
(cut the rest as to not over-quote.. but my comment applies to the whole email)
I think you're more alarmed than you should be. Legal and Accounting are hard, especially in a global context, and the SFC is and has been a great resource for open-source projects. (I am sharing my personal opinion based on SFC and buildbot project; I have no knowledge of boost's arrangement). But I 100% agree that transparency should be improved. The fact that the boost.org site doesn't really talk about SFC should be corrected, and I hope the current operating rules of that board could be posted. Just the simple question of "is the Steering Committee the same as the operating board for SFC purposes?" should be obvious. Maybe these things are on the website, but I couldn't find them. Jared
I think you're more alarmed than you should be.
Legal and Accounting are hard, especially in a global context, and the SFC is and has been a great resource for open-source projects. (I am sharing my personal opinion based on SFC and buildbot project; I have no knowledge of boost's arrangement).
I wouldn't be as positive personally. For the 10% we pay them, I have not been convinced of the value add. But then I suppose our 10% is a lot more money than most other open source org's 10%. For them, then value add probably is worth it.
But I 100% agree that transparency should be improved.
The SC is much more transparent than has been given credit for. You just need to be paying attention.
The fact that the boost.org site doesn't really talk about SFC should be corrected, and I hope the current operating rules of that board could be posted. Just the simple question of "is the Steering Committee the same as the operating board for SFC purposes?" should be obvious. Maybe these things are on the website, but I couldn't find them.
The reason that doesn't exist is because nobody has submitted a pull request to boostorg/website adding it. Volunteers to write it are welcome I am sure. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
I have to say.. Finding this stuff out now is rapidly decreasing my confidence in the SC and the operation of Boost. It's a sad situation. And I'm worried this is just going to implode. I'd really like to find out what the rules truly are and what is going on. This is horribly saddening :-(
It took me a while to figure out too. But there is a defined process for org change. Routes forward: 1. You get a demonstrated general consensus here that your proposed changes are widely agreed with by the community. Example: The recent changes to how libraries enter the review queue. 2. You persuade the SC that consensus by the community on a change cannot be reached due to disagreement or apathy, but a decision must be made or else it will threaten Boost's future. Examples: the cmake decision, the need to upgrade Boost's server infrastructure, the list dmarc setting, funding the continuing GSoC students when Google dropped us in 2016 for no good reason, lots of others actually I can't remember off hand ... Now that is a terrible governance design. Really awful. Anyone with any experience in governance design would have warned against choosing it for the SC at foundation. But it's done now, and that's the established process for changing the org. They have to follow it. You have drawn up a proposed new set of by laws, as the SC chair asked you to do. You now must either get the community to widely agree on them, in which case the SC will adopt them as it is required to do, unless those by laws cannot be adopted for legal reasons. Or you need to demonstrate to the SC that community consensus cannot be reached on your proposed changes, and that failure to adopt the change threatens the future of Boost. Note the ordering: (i) demonstrate failure to reach consensus (ii) demonstrate failure to change is a threat to the org. In that order. The hardest part with this route is (ii), without lots of people quitting Boost in anger, hard to prove (ii). 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. But I would say you have a fair chance under Route 2. I think you have no chance under Route 1. Too few here think governance is important, unfortunately, until it bites them personally in the ass. Until then it's always somebody else's problem. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, Oct 18, 2017 at 5:23 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
I have to say.. Finding this stuff out now is rapidly decreasing my confidence in the SC and the operation of Boost. It's a sad situation. And I'm worried this is just going to implode. I'd really like to find out what the rules truly are and what is going on. This is horribly saddening :-(
It took me a while to figure out too. But there is a defined process for org change. Routes forward:
1. You get a demonstrated general consensus here that your proposed changes are widely agreed with by the community.
2. You persuade the SC that consensus by the community on a change cannot be reached due to disagreement or apathy, but a decision must be made or else it will threaten Boost's future.
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. 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 ;-)
But I would say you have a fair chance under Route 2.
There's always a third option. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
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/
Niall Douglas wrote:
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.
Surely it doesn't need "project management software". It just needs that the section called "Recent resolutions" at https://sites.google.com/a/boost.org/steering/ gets updated to include some mention of the CMake decision. (That is the official page, right?) I note also that the SC mailing list archive at https://groups.google.com/forum/?hl=en#!forum/boost-steering has no mention of CMake that I can see. So if this were all handled by some sort of project management software where people could subscribe to see this discussion, what discussion would they see? (Again, is that the official list? Why are these things hosted by Google, rather than by Boost?) Regards, Phil.
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.
Surely it doesn't need "project management software".
I believe the idea was some sort of issue tracking software, except it isn't exactly issue tracking. It's more like story or "investigation" tracking. That discussion was a long time ago, but some felt Redmine's project management would do it, others felt that the software they use for managing CppCon would do it, others had other opinions again. No consensus was reached.
It just needs that the section called "Recent resolutions" at https://sites.google.com/a/boost.org/steering/ gets updated to include some mention of the CMake decision. (That is the official page, right?)
That gets updated when Jon gets round to it. And he's been kinda busy recently, there was this large conference recently ... But the software discussed was not for resolutions passed, but rather for issues currently being considered and actively worked upon. I do remember Jon wanted to be able to assign discussion topics and tasks to specific people. Right now he does this by looping them into email by hand, which works, but as with all things, email can get missed and people can be busy etc. You've got to remember everything happens on a volunteer basis. Quality of implementation can be a bit flaky sometimes. It's no one's fault, it's just we haven't invested in admin and bureaucracy here at Boost. You get corresponding drops of the ball. Like we're still running a Trac so old it's not funny how old it is. The fact that hasn't been hacked yet and all our data destroyed is purely because the hackers can't be bothered. Michael did undertake a very, very long overdue upgrade of the mail servers last year which cost him *months* of his time free of cost. Before that we were running a truly ancient MailMan, and again stunning it didn't get hacked. Let me repeat once again: if we don't invest as a community in infrastructure, admin and bureaucracy, you get these outcomes. And it's not like we can't afford to do so.
I note also that the SC mailing list archive at https://groups.google.com/forum/?hl=en#!forum/boost-steering has no mention of CMake that I can see. So if this were all handled by some sort of project management software where people could subscribe to see this discussion, what discussion would they see? (Again, is that the official list?
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 should also mention how hard it is to volunteer people into doing things free of cost. That's why so many discussion and roping people in avenues exist. That's why there is no formal process. Cajoling people to do stuff is hard enough as it is. Formal processes scare volunteers off.
Why are these things hosted by Google, rather than
by Boost?)
Google gives free Enterprise cloud services to open source orgs. It's not widely advertised, but has been the case since the very beginning of Google. Indeed, until last year, almost all our infrastructure had been donated to us free of cost, some of it so old and non-upgraded that everybody had lost the passwords to the servers, so we couldn't change anything or get our data out. Michael carried that cross and got it done. It was not easy. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 19.10.2017 17:49, Niall Douglas via Boost wrote:
Let me repeat once again: if we don't invest as a community in infrastructure, admin and bureaucracy, you get these outcomes. And it's not like we can't afford to do so.
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
While I can't argue about specific infrastructure questions in this context, I'm again puzzled how almost arbitrary important questions / issues almost inevitably gravitate towards technical "solutions". The fundamental issues that I don't see addressed anywhere are not of a technical nature, but organizational and social: * What is the relationship between the Boost organization and its member projects ? * What decisions are to be made by projects, and what by the organization ? * How are conflicts between the two entities resolved ? As long as we don't find clear answers to the above we aren't going to get out of the current stall. 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.
I should also mention how hard it is to volunteer people into doing things free of cost. That's why so many discussion and roping people in avenues exist. That's why there is no formal process. Cajoling people to do stuff is hard enough as it is. Formal processes scare volunteers off.
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. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On October 19, 2017 7:47:09 PM EDT, Stefan Seefeld via Boost <boost@lists.boost.org> 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.)
* 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.
In case people aren't aware and seeing as Rob didn't mention it, Rob served on the Steering Committee for many years, and thus his statements about how the SC works carries more weight than from others, including myself. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, Oct 18, 2017 at 10:48 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:
On Tue, Oct 17, 2017 at 1:34 AM, Jared Grubb <jared.grubb@gmail.com> wrote:
When buildbot joined the SFC, one of the requirements (and service!) that SFC had was to help create a board together with all the rules.
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
To be fair, that was years before there was a steering committee. < https://lists.boost.org/boost-announce/2007/08/0141.php> -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
On Wed, Oct 18, 2017 at 6:07 PM, Nevin Liber via Boost < boost@lists.boost.org> wrote:
On Wed, Oct 18, 2017 at 10:48 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:
On Tue, Oct 17, 2017 at 1:34 AM, Jared Grubb <jared.grubb@gmail.com> wrote:
When buildbot joined the SFC, one of the requirements (and service!) that SFC had was to help create a board together with all the rules.
Since boost is also a member of the SFC, did it do the same?
I have no idea. As joining the SFC was another one of those decisions made mostly in obscurity.
To be fair, that was years before there was a steering committee. < https://lists.boost.org/boost-announce/2007/08/0141.php>
The only reference to the SFC I could find on the Boost site was well hidden away in the donate page. Which is the only page returned by the search below too. I'm surprised it's not even mentioned on the landing page of boost.org. --DD [1] https://www.google.com/search?as_q=conservancy&as_sitesearch=www.boost.org
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera via Boost Sent: 16 October 2017 12:35 To: boost@lists.boost.org Cc: Rene Rivera Subject: [boost] RFC.. Steering Committee Bylaws Proposal
It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1].
The Bylaws hopefully address some key issues that I feel are at the core of the current problems:
* Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems.
This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2].
I can understand that you are still spitting feathers about the crass handling of B2/Cmake, but this seems a big legalistic sledge hammer to try to solve that issue, and others too. It is quite reasonable for the Steering Committee to opine that the number of users of Boost might be boosted by providing a way to use another build tool, but ultimately, the library writers will control what happens by voting with their feet, or fingers. Let's keep muddling on ;-) and Carry On Coding :-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 10/18/17 1:33 AM, Paul A. Bristow via Boost wrote:
I can understand that you are still spitting feathers about the crass handling of B2/Cmake, but this seems a big legalistic sledge hammer to try to solve that issue, and others too.
It is quite reasonable for the Steering Committee to opine that the number of users of Boost might be boosted by providing a way to use another build tool, but ultimately, the library writers will control what happens by voting with their feet, or fingers.
Let's keep muddling on ;-) +1
and Carry On Coding :-) +1
Robert Ramey
Paul
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Oct 18, 2017 at 3:33 AM, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
I can understand that you are still spitting feathers about the crass handling of B2/Cmake, but this seems a big legalistic sledge hammer to try to solve that issue, and others too.
You do know that I could actually care less about what build system Boost uses? And that has nothing to do with this.
It is quite reasonable for the Steering Committee to opine that the number of users of Boost might be boosted by providing a way to use another build tool, but ultimately, the library writers will control what happens by voting with their feet, or fingers.
Nah.. Programmers have a long history of accepting edicts about the tools and methods that others proclaim. And I doubt this will be any different from that history. Let's keep muddling on ;-)
Right.. Lets accept what is given without any say on it.
and Carry On Coding :-)
Sure.. We'll rowing to the drum beat. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 10/18/17 8:10 AM, Rene Rivera via Boost wrote:
Nah.. Programmers have a long history of accepting edicts about the tools and methods that others proclaim. And I doubt this will be any different from that history.
Let's keep muddling on ;-)
Right.. Lets accept what is given without any say on it.
and Carry On Coding :-)
Sure.. We'll rowing to the drum beat.
I fear that you've fallen into the same trap that the steering committee has - that what they say makes a lot of difference. They can do a lot of things: spend some money, make proclamations, pass a code of conduct, stuff like that - but nothing really of substance. If you want proof just look at the last attempt to impose CMake. What they can do is to try to recognize, and build concensus. That is, buy the time the issue has ripened to the point that there is a consensus, they can climb on board to give the impression that they actually did something. Witness the successful transition to git from svn - which was much simpler by the way. So they can make a difference at the margin. But the rest is just a facade. Of course this is not a phenomenon unique to boost - its the general way of doing things in civilized society. Hence we see boards of directors filled with prestigious names who spend only a couple of days a year "working" to give give "guidance and direction" to the organization. (The boost steering committee is an exception of course) Don't think of this as a negative thing - imagine what the world would be like if these people actually did run things. Actually you don't have to imagine, consider the soviet politburo for obvious example. I've been a regular complainer about a number of aspects of boost build over the years, but I have huge respect for the developers of the current boost build setup. They have been reliable maintainers of the system and it's something we have been able to depend upon. But it has problematic aspects which have never been addressed. So here we are. Anyway, there are good reasons for Boost to support those who want/need to use CMake. I DO think there is a consensus about this. The problem is that it's not clear what this would really mean and require. CMake has facets for building IDE, a GUI vs Command line interface, Building libraries, Setting up and running tests, Posting tests results to a dashboard, and deployment of packages. Understanding these different facets currently requires one to spend a lot of time googling CMake explanations - none of which is particularly clear and comprehensive. There are open questions regarding how this would work in the context of Boost. E.G what this means for users vs developers, what facilities from CMake we might want to use and how it would provide facilities which we currently depend upon. It's stunning to me that in spite of a widely held view that that boost should support CMake, no one has posted a real proposal about what parts we should use, how we should use them to support development, maintenance, testing, deployment of the federation of libraries which currently constitute boost. Until such a proposal is presented, no progress can be made. Robert Ramey
participants (13)
-
Dominique Devienne -
Glen Fernandes -
Jared Grubb -
Nevin Liber -
Niall Douglas -
Paul A. Bristow -
Phil Endecott -
Rene Rivera -
Rob Stewart -
Robert Ramey -
Seth -
Stefan Seefeld -
Vinnie Falco