Boost logo

Boost :

Subject: Re: [boost] Trac
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-08-02 16:36:40


> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Stefan Seefeld via Boost
> Sent: 02 August 2018 17:16
> To: boost_at_[hidden]
> Cc: Stefan Seefeld
> Subject: Re: [boost] Trac
>
>
>
> 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.

But are we not closing it - only stopping NEW Trac entries.

Existing items can be replied to and migrated, or not as maintainers decide.

The rest is read-only - is it needs to be to keep the massive Boost history.

Paul


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk