Boost Trac, random, No-Maintainer?

Boost Trac, random, No-Maintainer?

I filed 3 defects into Boost Trac for Boost.Random based on work I just did
on adding CI integration, and the maintainer that Trac assigned to these
new items was "No-Maintainer". That seems incorrect? The backlog in trac
for random also has "No-Maintainer" assigned to all the items.

Re: Boost Trac, random, No-Maintainer?

On 10/08/17 16:04, James E. King, III via Boost wrote:
> I filed 3 defects into Boost Trac for Boost.Random based on work I just did
> on adding CI integration, and the maintainer that Trac assigned to these
> new items was "No-Maintainer". That seems incorrect?
maintainers.txt says that Boost.Random maintainer is Steven Watanabe.

Re: Boost Trac, random, No-Maintainer?

Andrey Semashev wrote:
> On 10/08/17 17:00, Peter Dimov via Boost wrote:
>
> > Re Trac, I just enabled Github Issues for Random. Perhaps we finally
> > need to do that for all libraries.
>
> I think it should be left up to the library maintainers.

The library maintainers who dislike issues can re-disable them.

The problem with the current status quo is that when I look at a library and
see its issues disabled, I don't know if that's because the maintainer wants
them disabled, or because they are disabled because all were initially
disabled. No way to gauge intent.

Re: Boost Trac, random, No-Maintainer?

On 08.10.2017 11:32, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> On 10/08/17 17:00, Peter Dimov via Boost wrote:
>>
>> > Re Trac, I just enabled Github Issues for Random. Perhaps we
>> finally > need to do that for all libraries.
>>
>> I think it should be left up to the library maintainers.
>
> The library maintainers who dislike issues can re-disable them.

Huh.

> The problem with the current status quo is that when I look at a
> library and see its issues disabled, I don't know if that's because
> the maintainer wants them disabled, or because they are disabled
> because all were initially disabled. No way to gauge intent.

Yeah, the documentation structure still hasn't caught up with the move
to github.
Each project should *individually* contain some info to indicate how to
reach the maintainer and where to submit issues. There used to be a
single universal answer (trac), but quite a few libraries have moved to
github, yet there is no normalized way to indicate that.

(I quick and easy solution would be for each library to have its own
"landing page" (accessible through
"http://boostorg.github.com/<library>") which initially would be filled
out with default values. Library maintainers would take ownership of
that document and could change those values according to their needs.)

Re: Boost Trac, random, No-Maintainer?

> Andrey Semashev wrote:
>> On 10/08/17 17:00, Peter Dimov via Boost wrote:
>>
>> > Re Trac, I just enabled Github Issues for Random. Perhaps we finally
>> > need to do that for all libraries.
>>
>> I think it should be left up to the library maintainers.
>
> The library maintainers who dislike issues can re-disable them.
>
> The problem with the current status quo is that when I look at a library and
> see its issues disabled, I don't know if that's because the maintainer wants
> them disabled, or because they are disabled because all were initially
> disabled. No way to gauge intent.

Just let the maintainers have admin rights for their libraries, they will
enable issues if they want it. Enabling it globally and asking the
maintainers to complain seems like a wrong way to gauge intent.

Re: Boost Trac, random, No-Maintainer?

> Andrey Semashev wrote:
>
>> Just let the maintainers have admin rights for their libraries,
>
> They do.

No, surely not all of them do. Some admin tickets requesting admin access
are hanging unanswered for quite some time and I don't think admin rights
were granted to maintainers during the transition to git. Not sure if admin
rights are granted for new libraries.

>> they will enable issues if they want it.
>
> They do not.

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>

Re: Boost Trac, random, No-Maintainer?

Andrey Semashev wrote:
> >> Just let the maintainers have admin rights for their libraries,
> >
> > They do.
>
> No, surely not all of them do. Some admin tickets requesting admin access
> are hanging unanswered for quite some time and I don't think admin rights
> were granted to maintainers during the transition to git. Not sure if
> admin rights are granted for new libraries.

I checked a few at random, all did. Initially they did not, but then, if I
recall correctly, Github changed the way privileges worked and maintainers
were made admins.

Not what my experience shows. (My sample is small, of course.) The typical
case is for the maintainers to not even know they have issues disabled. (And
there's no way for users to tell them short of creating a dummy pull
request, as the usual mechanism of creating an issue obviously doesn't
work.)

Re: Boost Trac, random, No-Maintainer?

> Andrey Semashev wrote:
>> >> Just let the maintainers have admin rights for their libraries,
>> >
>> > They do.
>>
>> No, surely not all of them do. Some admin tickets requesting admin access
>> are hanging unanswered for quite some time and I don't think admin rights
>> were granted to maintainers during the transition to git. Not sure if
>> admin rights are granted for new libraries.
>
> I checked a few at random, all did. Initially they did not, but then, if I
> recall correctly, Github changed the way privileges worked and maintainers
> were made admins.

That's not my experience. AFAIR, I was made admin only after requesting via
a ticket. I don't remember mass permission granting and I'm still not an
admin of Boost.Atomic.

>> If project maintainers that have admin rights don't enable issues then
>> they don't want it.
>
> Not what my experience shows. (My sample is small, of course.) The typical
> case is for the maintainers to not even know they have issues disabled.

I find this hard to believe. It's pretty obvious there is no Issues tab on
the GitHub page. And it would be strange for someone wanting to use issues
to not know if they are enabled.

Re: Boost Trac, random, No-Maintainer?

Andrey Semashev wrote:

> I'm still not an admin of Boost.Atomic.

You are now.

> > Not what my experience shows. (My sample is small, of course.) The
> > typical case is for the maintainers to not even know they have issues
> > disabled.
>
> I find this hard to believe. It's pretty obvious there is no Issues tab on
> the GitHub page.

It's obvious for users, yes.

> And it would be strange for someone wanting to use issues to not know if
> they are enabled.

Users know, yes. But without issues enabled, they have no way of
communicating this knowledge of theirs to the maintainer.

Re: Boost Trac, random, No-Maintainer?

> Andrey Semashev wrote:
>
>> > Not what my experience shows. (My sample is small, of course.) The
>> > typical case is for the maintainers to not even know they have issues
>> > disabled.
>>
>> I find this hard to believe. It's pretty obvious there is no Issues tab on
>> the GitHub page.
>
> It's obvious for users, yes.
>
>> And it would be strange for someone wanting to use issues to not know if
>> they are enabled.
>
> Users know, yes.

Re: Boost Trac, random, No-Maintainer?

> Yeah, the documentation structure still hasn't caught up with the move
> to github.
> Each project should *individually* contain some info to indicate how to
> reach the maintainer and where to submit issues.

You mean like on the boost library incubator. it would be easy to add
pages for existing boost libraries. In fact, I might just do that on my
own initiative.

There used to be a
> single universal answer (trac), but quite a few libraries have moved to
> github, yet there is no normalized way to indicate that.

> (I quick and easy solution would be for each library to have its own
> "landing page" (accessible through
> "http://boostorg.github.com/<library>") which initially would be filled
> out with default values. Library maintainers would take ownership of
> that document and could change those values according to their needs.)

Re: Boost Trac, random, No-Maintainer?

> On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost
> <[hidden email]> 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.

Re: Boost Trac, random, No-Maintainer?

On Sun, Oct 8, 2017 at 7:14 PM, James E. King, III via Boost
<[hidden email]> wrote:
> 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.

That is my preference as well.

I would take it one step further, issues in Trac should be imported
into the corresponding GitHub repository using an automated tool, for
visibility.