Re: [boost] Boost Trac, random, No-Maintainer?

Subject: Re: [boost] Boost Trac, random, No-Maintainer?
From: James E. King, III (jking_at_[hidden])
Date: 2017-10-09 02:14:15

On Sun, Oct 8, 2017 at 1:18 PM, Vinnie Falco via Boost <
boost_at_[hidden]> wrote:

> On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost
> <boost_at_[hidden]> wrote:
> > Then there's your answer. If project maintainers that have admin rights
> > don't enable issues then they don't want it.
>
> Rather than speak in generalities I think it would be more productive to
> talk
> about specific authors and specific projects. For example, I suspect that
> Chris does not want Issues enabled here:
> <https://github.com/boostorg/asio>
>
> But would rather see them here:
> <https://github.com/chriskohlhoff/asio>
>
> We should enumerate all of the libraries which have Issues disabled and
> evaluate them one by one.
>
>
As a consumer of boost, it would make a lot more sense for me to go to one
place for issues.
If I go to the official repository for a boostorg library and issues are
not enabled, I find that odd.
Further if some have issues enabled and some do not, I find that even more
odd.

It makes a lot more sense to me as a consumer of boost that if I have an
issue from a github
repository I have pulled from, that's where I should submit issues.

It also does not make sense that some repositories would prefer to have
issues on personal forks.
As a consumer of boost, if I cannot find the issue in github issues for
that repository, I might assume
the issue is not known.  Taking the example of asio, which has no readme,
how would I possibly know
to go to chriskohlhoff's repository to submit an issue?  I'm there right
now and I have no idea where
to submit an issue.  If I poke around enough I might find my way to trac
(as a ocnsumer).
I'm looking at the official github page for the official boost library
asio, why are issues somewhere else?

My observation in the libraries I've wandered into is that issues in trac
do not get a lot of attention.
The backlog in many projects in trac today is littered with things that
have valid patches but sit open literally
for years.

Let's take this to the most extreme incarnation of what people have
suggested - allowing maintainers
to decide:

Imagine the confusion from a consumer of boost, if each boostorg repository
had its own completely
separate way of recording and tracking issues.  I would find that quite
frustrating, whereas if I can always
go to one place (the issues tab in the *official* repository) to look for
known issues, just like I can go to
one place to look for open pull requests, that makes more sense.

My personal preference would be to require github issues be enabled and
used for all official
boostorg repositories, and that trac be deprecated and accept no new
issues.  This is what end users
who consume boost expect.  This will make it easier for issues to be
reported and dealt with.  Isn't that
what we want?  We should not make it difficult to submit issues on boost
libraries to make it easier for
maintainers.  We should make it easier for consumers and encourage them to
want to use more libraries.

Just some observations from my end.

- Jim