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

On Sun, Oct 8, 2017 at 1:18 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

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