Even with external issue trackers, leave GitHub Issues enabled
Even with external issue trackers, leave GitHub Issues enabled

            Jenkins is a large open source project. Well over two
thousand repositories, almost two thousand committers, four or five GitHub
Organizations, and many thousands of opened, in progress, and closed issues.
Part of the reason we’re called Jenkins is because of GitHub and yet many of
our repositories do not use GitHub Issues. We eschew GitHub Issues in favor
of Jira for a number of reasons, perhaps most
importantly is that GitHub Issues are incredibly difficult to scale across
repositories and teams. What might be considered a shining example of scaling
GitHub Issues would be the Kubernetes ecosystem which
has concocted a rather complex workflow using automated bots, labels, and
comments on Issues. As such, it’s not impossible, but vanilla out-of-the-box
GitHub Issues are tricky to grow with large free and open source projects.

As Jenkins has matured, my own opinions on the time and place for GitHub Issues
has evolved. Unlike the uncompromising opinion that we should simply
disable Issues on our repositories, like we tend to do with Wiki and Projects,
which I do genuinely find mostly useless even for my personal projects, I have
started to think that Issues should be left enabled by default, even if the
“main development” of tickets is handled elsewhere. As a maintainer it’s not
terribly difficult, and dare I say automatable, to triage and move tickets from
GitHub Issues into Jira. What is not automatable is getting the issues
filed in the first place by new users and contributors.

Stated simply, the barrier to entry of GitHub Issues is so low that I would
rather have redundant tickets in two systems than to leave potential bug
reports with no place to go. With newer tools like
Probot I believe the opportunities for
exfiltrating information from GitHub into a better system of record, such as
Jira, is so much more attainable than it once was.

Should you find yourself worried about drowning in the torrent of GitHub
Issues, I will refer you to The Art of
Closing. You needn’t spend
too much time in GitHub Issues, and you don’t owe anybody any more time than
you want to spend on Issues; practice good hygiene and close unnecessary Issues
early and often!

That said, I suggest erring on the side of enabling easier feedback than not.
Filing Issues is typically the first step on the road to contribution.

        