Ansible, for example (https://github.com/ansible/ansible/issues), uses some advanced automation and templates to manage their enormous issues stream. Issue are checked against conforming rules/tests/codestyle checks or, for example, automatically closed due inactivity I believe most if not all soluitons they use are opensource.
On Sun, Jan 6, 2019 at 7:32 PM Lukas Tribus <[email protected]> wrote: > Hello everyone, > > > as per Tim's suggestion I'm restarting the discussion about the issue > tracker, started in "haproxy 1.9 status update" (2018-05-25), > Message-ID [email protected]: > https://www.mail-archive.com/[email protected]/msg30139.html > > > > It would be nice to show what's pending or being worked on, and > > to sometimes add extra info regarding a given task. > > Yes, we are in need of an issue tracker, not only to handle open bugs, > but even more so to handle feature/change requests that often need > more time. Those do get lost on the mailing list, even when everyone > already agreed it's needed. > > > > The problem we've faced in the past with GitHub's issue tracker > > is that it's impossible to restrict the creation of new issues to > > participants. Given that haproxy is a complex component, the boundary > > between human error, misunderstanding and bug is extremely thin. > > It is, but I don't like restricting the creation of new issues to > participants. > > Issue templates need to be clear that the issue tracker is not a > support forum. Triaging new issues will be needed anyway, and that > also includes closing misdirected support request. > > > To be clear: I think developers should not receive an email > notifications for new or untriaged issues - only when specifically > assigned to the issue or if they commented previously on it. Instead, > maybe an automated weekly report or something like that (similar to > what we have now for the stable-queue) could go out to the mailing > list with a summary of the open issues, grouped by it's labels. > > > > It resulted in the issue tracker being filled with wrong bugs, 100% of > > which were in fact requests for help. It makes the utility totally > > useless for development and bug fixing as it requires more time to > > maintain in a clean state than it takes to put issues in a mailbox. > > What you are describing basically is a unmaintained issue tracker, > which is of course useless. > > But keeping people from filing new issues is the wrong approach to > this, imho. Proper templating, triaging and correct labeling of the > issues is the difference between a useless and a useful issue tracker > from my point of view. > > > So I guess we ultimately have to decide between: > > - an issue tracker open to everyone, however requiring some > volunteers to triage incoming bugs (and close invalid ones) > - an issue tracker that is open to "previous participants", with the > expectation to require less manpower for triage > > > I'm in favor of the former, because I believe triage will be required > for both and I don't think the amount of bogus issues will be > unmanageable. I'd also volunteer to triage incoming issues - not that > it's much different from what's currently done discourse anyway - as > Tim already said. > > Regarding what tool to use, in the "open to everyone" case I'd opt for > github simply because it has the lowest barrier of entry for everyone, > as well as me being mildly familiar with it personally. Pre-existing > github labels would have to be replaced by useful ones and a issue > template would have to be created. > > > > A limitation that isn't addressed by any of them is that an issue has > > a single status and not one per maintenance branch. Some will say that > > labels replace this but I'd say that this isn't true, it just vaguely > > emulates this. Anyway if we don't have better we can go with this. I > > often dream of the day someone pissed of by using prehistoric issue > > trackers writes a modern one, just like when Linus created Git... > > There are some niche tools allowing a "distributed issue tracking > system" within git, but they seem very fragmented, none of it gets a > lot of traction and it would certainly over complicate things for a > lot of people, including myself. See git-bug [1] and it's HN > discussion [2], containing a log of other references [3-7]. > > Well I guess we would certainly not have many bogus issues reported on > those systems ;) > > > > Regards, > Lukas > > > [1] https://github.com/MichaelMure/git-bug > [2] https://news.ycombinator.com/item?id=17782121 > [3] http://bugseverywhere.org/ > [4] http://mrzv.org/software/artemis/ > [5] https://github.com/sit-fyi/issue-tracking > [6} https://github.com/dspinellis/git-issue > [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html > >
