Re: [boost] Trac

Subject: Re: [boost] Trac
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-08-02 08:35:41

On 2 August 2018 at 05:45, James E. King III via Boost
<boost_at_[hidden]> wrote:
> On Wed, Aug 1, 2018 at 4:47 PM Robert Ramey via Boost <boost_at_[hidden]> wrote:
>
>> I see 4 alternatives:
>>
>> a) stay with track and require developers to use trac and only trac
>> b) require only github issues and convert all the old trac tickets to
>> github.
>> c) choose trac for all new issues but leave the old issues in trac so no
>> one has to convert them
>>
>> d) let each library developer select which of the above he wants to do.
>>
>> I'm not adverse to b, c, or d.  But the current setup of having two
>> conflicting working systems is a burden on developers and adds no value.
>>
>> Robert Ramey
>>
>>
> 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.
> Standardizing on github for issues will do both.

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

The majority should be considered within those expressing their vote.
I'm not aware of any formal voting scheme in Boost though.

> If we leave existing issues in Trac then everyone should also commit to
> driving that backlog down to zero as a priority, and we should also measure
> this progress so that we can identify repositories
> that need ownership change to remain responsive to the community.

This is what I'm going to do for GIL:
- not migrate of any Trac issues to GitHub, but work to clear them all
as high priority task after Boost 1.68 is out.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net