Ansible, for example (, 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 <> 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
> > 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]
> [2]
> [3]
> [4]
> [5]
> [6}
> [7]

Reply via email to