Issues Tracker Battle (Github vs JIRA)

[Nikolas Falco]

Hi developers,
As a new maintainer of bitbucket-branch-source-plugin I found myself with a lot of open issues to manage, this might be normal. What doesn't seem normal to me, is having two different issue trackers.
When I became maintainer there were about 100 issues on gibhub and more than 100 on JIRA. Now, the effort I'm spending to match issues on github -> JIRA and vice versa, collecting comments, use cases, steps to reproduce the problem... is way too much.
I had a look in this group to see what the decision was for the default issue tracker, but from what I read in a couple of threads it's that the decision was never made but only discussed.
Since most of the core plugins are on JIRA and other plugins I'm the mantainer are on JIRA and, my preference is JIRA because of the workflow, notifications are not mixed with CD tasks notifications, it's easy to switch components, automatic assenee etc etc... all without losing history.
I am here to ask you if the maintainer is able to freeze one of the issue trackers as documented on https://github.com/jenkins-infra/repository-permissions-updater?tab=readme-ov-file#managing-issue-trackers
with the report attribute set to false.
Then I would announce the choose in the README.MD place in the plugin repository and, after all issues are resolved or manually migrated to JIRA (if not already present from another reported), finally remove the issue tab.

[Mark Waite]

On Friday, December 6, 2024 at 5:09:30 AM UTC-7 nikola...@gmail.com wrote:

Hi developers,
As a new maintainer of bitbucket-branch-source-plugin I found myself with a lot of open issues to manage, this might be normal. What doesn't seem normal to me, is having two different issue trackers.

Thanks for asking.  I have a similar problem in one or more plugins that I've adopted.

 

When I became maintainer there were about 100 issues on gibhub and more than 100 on JIRA. Now, the effort I'm spending to match issues on github -> JIRA and vice versa, collecting comments, use cases, steps to reproduce the problem... is way too much.
I had a look in this group to see what the decision was for the default issue tracker, but from what I read in a couple of threads it's that the decision was never made but only discussed.

The decision remains with the plugin maintainer.

 

Since most of the core plugins are on JIRA and other plugins I'm the mantainer are on JIRA and, my preference is JIRA because of the workflow, notifications are not mixed with CD tasks notifications, it's easy to switch components, automatic assenee etc etc... all without losing history.
I am here to ask you if the maintainer is able to freeze one of the issue trackers as documented on https://github.com/jenkins-infra/repository-permissions-updater?tab=readme-ov-file#managing-issue-trackers
with the report attribute set to false.

That is allowed as far as I understand it.

 

Then I would announce the choose in the README.MD place in the plugin repository and, after all issues are resolved or manually migrated to JIRA (if not already present from another reported), finally remove the issue tab.

That's the same transition that I'm likely to make on a few of the plugins that I maintain, because I prefer Jira for reasons that are similar to yours.

Mark Waite 

[Nikolas Falco]

Thanks Mark!

I had also open a PR at https://github.com/jenkins-infra/repository-permissions-updater/pull/4215

[Hervé]

Related: https://groups.google.com/g/jenkinsci-dev/c/GUFCfBM1j_4

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/93dad35f-b498-43be-b624-7f40cc6288e2n%40googlegroups.com.

[Ullrich Hafner]

I think it would be helpful if we can enforce during the review process that a plugin uses only one issue tracker. So either GitHub or Jira, but not both. Having two different access points for all Jenkins users globally already is a bad user experience but having two access points for a single plugin makes absolutely no sense.  

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CAE1M8%2B8aPVMi5Dv%3DZd3dJo1RUJaBFu0eaP7_eN%3Dd%3D9K_aQxRZA%40mail.gmail.com.

[Tim Jacomb]

It's not something that has come up as far as I can remember, when someone actively transitions the issue tracker one gets turned off.

There's about 200 historical ones which have both assigned, (from enabling GitHub issues and not migrating the Jira issues away)

99% of issues will just go to GitHub, users don't really get confused, but occasionally one will get raised in Jira.

We could probably mark all of the double ones as report: false for Jira, assuming that 99% of the time it will be this case.

----

Longer term better to get these issues migrated and that's something https://github.com/jenkins-infra/helpdesk/issues/4862 will help with

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/C9BF48F9-83B0-49C1-88CF-58744D6148D5%40gmail.com.

[Tim Jacomb]

If by review process you mean during adoption, maybe but that may not be the maintainers first priority but we can mention it then

[Nikolas Falco]

I agree with Ullrich: the maintainer should decide which one to use to avoid duplications, which are difficult to track when closing issues on GitHub or Jira—that is, which is the duplicate. Some people open issues on both because they don't know which one the maintainer considers.
When I had to manage two, I ran into trouble, considering that I had already announced which was the main one in the README.MD file, yet users continued to open issues on GitHub.

When I finally closed the issues section on GitHub (losing the history), life became easier.

Also consider that a lot of plugins change maintenance every 2-3 years, you can't keep switching from one to another

[Daniel Beck]

On Fri, Nov 7, 2025 at 10:36 AM Nikolas Falco <nikola...@gmail.com> wrote:

I agree with Ullrich: the maintainer should decide which one to use to avoid duplications, which are difficult to track when closing issues on GitHub or Jira—that is, which is the duplicate. Some people open issues on both because they don't know which one the maintainer considers.

The one with the link to report on plugins.jenkins.io / the Jenkins plugin manager :) But yes, if users are used to going directly to issue trackers, it's trickier.

 

When I had to manage two, I ran into trouble, considering that I had already announced which was the main one in the README.MD file, yet users continued to open issues on GitHub.

When I finally closed the issues section on GitHub (losing the history), life became easier.

AFAICT:

* Jira to GitHub can be done by archiving the component, which prevents its use in new issues

* GitHub to Jira can be done with issue template definitions (or rather, explicit lack thereof): https://github.com/daniel-beck/do-not-report

CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.