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 <lu...@ltri.eu> 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 20180525161044.ga6...@1wt.eu:
> https://www.mail-archive.com/haproxy@formilux.org/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
>
>

Reply via email to