search

boostorg / admin

https://svn.boost.org/trac/boost/wiki/ModAdmin
4 stars 6 forks source link

Every boostorg library should have Github Issues enabled #130

Closed jeking3 closed 6 years ago

jeking3 commented 7 years ago

We need to complete the transition from boost trac and use github issues across all repositories.

eldiener commented 7 years ago

I agree with this in that if all Boost libraries have github issues enabled the maintainer of any particular library can then choose to address github issues and optionally trac issues. But we should encourage github issues as the primary means of reporting issues until we decide to deprecate trac issues completely.

eldiener commented 7 years ago

Can we agree that having github issues enabled for all libraries is viable, or are we going to still say that enable github issues on a library by library basis is the way to go. If the latter I am going to post an admin issue for all the CMT libraries to have their github issues enabled along with all other libraries for which I have write access.

jeking3 commented 7 years ago

Similar to the announcement earlier this year around the intended switch to cmake as a build framework, an announcement to this effect on boost-announce sounds like it is in order. In fact, if possible I would like to remove the ability to add new boost trac issues for uuid now that issues exists.

Lastique commented 7 years ago

We need to complete the transition from boost trac and use github issues across all repositories.

There was no transition of issue trackers, there was only transition from SVN to git. There are valid reasons to have Trac enabled and keep using it (search the ML, this topic has been brought up several times). Some libraries might not want to have GitHub issues enabled as it adds a second place to report bugs, in addition to Trac.

I think it is more correct to give the maintainers a way to choose the issue tracker they want. Formally, this can be done by creating an admin ticket, but seeing how inactive the admin project is, this is probably not working well.

Lastique commented 7 years ago

In fact, if possible I would like to remove the ability to add new boost trac issues for uuid now that issues exists.

You can add links to the common tasks like reporting an issue to the project README.md (see https://github.com/boostorg/log for an example). For GitHub issues, I believe, there is also a way to provide an issue template to encourage users to provide the needed information.

eldiener commented 7 years ago

I think it is more correct to give the maintainers a way to choose the issue tracker they want.

Precisely. But if no Administrator is paying any attention to these issues it is impossible to get anything done as far as empowering individual maintainers is concerned.

jeking3 commented 7 years ago

I disagree with the notion that it would be better for the community to allow the maintainer of each library to install a different issue tracker. As it is currently there are two systems, and one literally seems to be ignored in many cases. The backlog in uuid was a good 5 years old before I started working on it, and most of the issues were already fixed, but nobody marked them as such. A standard way for anyone to report an issue on any boost library is better for the community as everyone can be instructed to open a github issue, not having to say, "See if the project has github issues, if not check the readme to see what the maintainer uses for issue tracking, if not then use boost trac". That would be too confusing for users. As someone who was recently adding issues to projects in both, having to use one or the other was annoyoing at best. As a consumer, trac looks like a dumping ground nobody looks at because there are open issues in many projects that are years old.

I'd like to see everything currently in boost trac moved into github issues and boost trac not accept any more new issues, and have everyone clean out their issue backlog in trac, then we can put trac into read-only more for archival purposes and/or retire it and phase it out. One less thing to maintain in a project is always good.

Lastique commented 7 years ago

The backlog in uuid was a good 5 years old before I started working on it, and most of the issues were already fixed, but nobody marked them as such.

This is more because the library had no proper maintainer than because of a specific issue tracker.

I'm sure forcing everyone to use GitHub issues will leave someone just as unhappy as with forcing everyone to Trac. I don't think project-specific issue trackers are a problem, especially since currently some libraries do use GitHub and others use Trac, and it doesn't seem to be such a big problem for users. Providing clear instructions solves this, IMHO.

mjcaisse commented 6 years ago

Interesting ... I just saw these "admin" tickets for the first time because @jeking3 tagged me in an item. Looking at who is listed as a "member" of this group and we primarily have individuals that are not very active in Boost these days.

I'm working on the "list".

jeking3 commented 6 years ago

@mjcaisse were you able to update the "list"?