On 2018-08-02 12:02 PM, Robert Ramey via Boost wrote:
This issue has come up on the mailing list more than once and it was also discussed in the admin project as an issue. In short, the community is suffering from the "Too Many Chefs in the Kitchen" syndrome. There is a lot of discussion, with many opinions, but there is no authority body that can actually make a decision that drives the project towards improvement, and therefore things do not happen quickly (if at all).
Amen.
We will not always be able to make a decision that everyone can agree to, but decisions should satisfy a majority of participants and also help drive project quality and developer efficiency to improve.
I'd like to nuance a bit: This isn't a democracy. Not all participants on any given discussion are equal. There are always people who are more concerned by a proposed change than others, so their opinion should have greater weight.
Standardizing on github for issues will do both.
The biggest issue (as far as I'm concerned) with Trac is that it's monolithic, and thus, the question of whether or not to close it really concerns all Boost contributors. But as with other tools discussions, we really should get to a point where such questions can be discussed (and agreed upon !) per project. That will be much simpler, than trying to build consensus in the community as a whole.
As an observer of numerous discussions, I find process collecting agreements frustrating: - a proposal is discussed, 2, 3, 10, 15, ..? people participate - agreement is nearly completed - suddenly, an objection arrives from someone - whole agreement reached so far collapses - no one feels like challenging the objection with simple "you've been late", - steam is out, proposal dies
All the above is true. Things always arrive at a stalemate. This is the queue for the "Board of Directors to step in, review the conflicting proposals, make a decision and find someone willing and able to implement it.
"willing to implement it" isn't enough, if a given change affects maintenance. The people concerned are the contributors to any given project, so they should decide (again, per project), not any "board of directors". Stefan -- ...ich hab' noch einen Koffer in Berlin...