Re: [boost] Trac

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 
directors".

Stefan

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