Boost logo

Boost :

Subject: Re: [boost] Trac
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-08-02 16:16:27

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


       ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at, gregod at, cpdaniel at, john at