Is there interest for GitHub issues in core components?

[Tim Jacomb]

Hello

Is there any interest in moving core components to GitHub issues?

It would involve things like:

- Issue migration

- LTS backporting flow updates

- Documentation updates

- Dashboards / reporting - maybe something like https://github.com/marketplace/actions/issue-dashboard

I would be happy to prototype something / prepare a JEP if there's interest.

Thanks

Tim

[jn...@cloudbees.com]

https://groups.google.com/g/jenkinsci-dev/c/9sZipk1PHns/m/mqtV7K8uAAAJ would report there is the opposite.

Whilst Jira is a PITA, GitHub issues for me has more drawbacks.

We seem to be missing some improvements to Jira that would make it much nicer day to day,
e.g. https://confluence.atlassian.com/jirasoftwareserver/configuring-development-tools-938845350.html 

/James

[Tim Jacomb]

Hi James

That thread is nearly 2 years old and the new GitHub projects and issues have come a long way in that time.

To demonstrate some of what this could look like I did a POC migration based on the INFRA one:

https://github.com/timja/jenkins-gh-issues-poc/issues

I recreated 2 dashboards that we currently use in Jira:

UX:

https://github.com/users/timja/projects/3/views/1

Core maintainers:

https://github.com/users/timja/projects/4/views/3

There's a tool you can use to subscribe to labels in GitHub like with Jira (not built-in but hopefully one day):

https://github.com/orgs/github-community/discussions/16645 

There's some sorting limitations which means I couldn't fully re-create the core maintainers dashboard unfortunately:

https://github.com/github-community/community/discussions/8518

----

We can certainly enhance our Jira setup but I don't see it being as smooth and nicely integrated as GitHub is.

The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

I have started writing a draft JEP to put some more words together but interested in any feedback on the above.

(I'm aware EPIC links are not included in the export, I plan to fix that)

(Web links exporting doesn't work unfortunately https://jira.atlassian.com/browse/JRASERVER-44537)

Thanks

Tim

--
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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/16d883f7-0f80-4cfd-9837-5e57040a9288n%40googlegroups.com.

[Daniel Beck]

On Mon, Jun 13, 2022 at 3:55 PM Tim Jacomb <timja...@gmail.com> wrote:

The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

Is people not reporting issues they experience really a problem we have?

Unless we step up our responsiveness, having a backlog of issues nobody cares about is not useful.

[jn...@cloudbees.com]

Hi Tim

> That thread is nearly 2 years old and the new GitHub projects and issues have come a long way in that time.

Whilst the started was old, the thread history is not and it it it has comments from Basil within the last month that seem relevant today.  Will leave that to Basil to comment on (I am surprised given his last comment was a day before this thread was started that there has been no follow-up (even if it was a "my concerns are all addressed now").

https://groups.google.com/g/jenkinsci-dev/c/9sZipk1PHns/m/mqtV7K8uAAAJ

Regards

/James

[Jesse Glick]

On Mon, Jun 13, 2022 at 10:02 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

On Mon, Jun 13, 2022 at 3:55 PM Tim Jacomb <timja...@gmail.com> wrote:

The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

Is people not reporting issues they experience really a problem we have?

FWIW I filed JENKINS-68727 just a few days ago after receiving private email from someone saying

I would like to report a bug, but the bugtracker on jira does not allow me to create a new account.

Not the first time I have gotten such a message. I do not know if this person had a GitHub account.

It is true that there are more bugs filed than people qualified and willing to triage them. Perhaps making it awkward to report (or comment on) bugs helps by filtering out people who would have filed vague and unreproducible reports anyway; or perhaps it just discourages everyone uniformly.

[Daniel Beck]

On Mon, Jun 13, 2022 at 9:05 PM 'Jesse Glick' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

On Mon, Jun 13, 2022 at 10:02 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

On Mon, Jun 13, 2022 at 3:55 PM Tim Jacomb <timja...@gmail.com> wrote:

The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

Is people not reporting issues they experience really a problem we have?

FWIW I filed JENKINS-68727 just a few days ago after receiving private email from someone saying

I would like to report a bug, but the bugtracker on jira does not allow me to create a new account.

Without more information, I cannot check what could have caused this. In the last 24 hours, 67 people have signed up for new accounts.

I think nobody is currently around anymore to respond to account creation requests when people fail the (not great) spam filter, but that's about an email every other week or so.

[Basil Crow]

On Mon, May 23, 2022 at 1:25 PM Tim Jacomb <timja...@gmail.com> wrote:
> Is there any interest in moving core components to GitHub issues?

Not from me. There is, on the other hand, an interest from me (for the
reasons described in
https://groups.google.com/g/jenkinsci-dev/c/9sZipk1PHns/m/mqtV7K8uAAAJ)
for us to

> (a) stop accepting new issues on GitHub for all core components and (b) move any existing core component issues from GitHub to Jira.

On Mon, Jun 13, 2022 at 6:55 AM Tim Jacomb <timja...@gmail.com> wrote:
> That thread is nearly 2 years old

But my recent posts in that thread are less than a month old.

> the new GitHub projects and issues have come a long way in that time.

Yet I still cannot mark one GitHub issue as caused by or depending on
another GitHub issue, and I still cannot efficiently move a GitHub
issue from the incorrect component to the correct component.

> The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

I do not think the barrier to entry on Jira is prohibitively high. As
others have noted, reporting issues requires a certain degree of due
diligence, including writing steps to reproduce, expected results, and
actual results.

[Tim Jacomb]

Hi all

Thanks for the feedback, I've created a JEP to capture and address it.

https://github.com/jenkinsci/jep/pull/390

Cheers

Tim

--
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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjr6e0R-qpSm9bvcDKwmOMOHyyc_6aLaF42RwAruMQ8neA%40mail.gmail.com.

[Basil Crow]

On Mon, Jun 27, 2022 at 1:15 AM Tim Jacomb <timja...@gmail.com> wrote:
>
> Thanks for the feedback, I've created a JEP to capture and address it.

I read it, but not all of the points are addressed.

> GitHub conveys a lot more information about the status of issues, pull requests and releases than Jira does.

On the contrary, GitHub does not provide enough information about the
status of issues, forcing label-based workarounds. For example, there
is no dedicated field for status (e.g., "Fixed but unreleased", "Won't
fix", "Cannot reproduce", etc) and no capability for searching by
status across components. And there is no dedicated UI element for
linking issues (e.g., "Caused by", "Duplicates", "Depends on", etc)
and viewing issues by links (e.g., viewing all bugs caused by a
particular change). There is also no ability to add custom fields
(e.g., "Released version"). The Jira Query Language (JQL) is a
powerful way to search for issues, and as far as I can tell there is
no equivalent in GitHub.

> Jira allows explicit relationships to be set on links. GitHub requires you to type 'Caused by' and 'Depends on' yourself.

That is an understatement: GitHub does not support relationships to be
set on links at all. Even if you type "Caused by" and "Depends on"
yourself, there is no way to e.g. view all the bugs that were caused
by a particular change for a given component.

> GitHub projects can be used to group issues that are across components. If that project doesn't use GitHub issues then […] A tracking issue can be created that links to a Jira epic or query

As I wrote in https://groups.google.com/g/jenkinsci-dev/c/9sZipk1PHns/m/uy8LVZQsAAAJ
this suggested workaorund is burdensome and therefore unacceptable to
me. The only solution that is not burdensome for users is for the
entire Jenkins project to use a single issue tracker for all
components.

> Jira's mobile support is very poor, commenting doesn't work on mobile web

Sometimes people have written things to me on GitHub that do not make
sense, and when I ask for clarification they explain away their
writing by saying that they were using their mobile device. I think a
good solution to this problem is to discourage people from using
mobile devices when interacting on issue trackers. I would prefer to
interact with people in an environment where they can write clearly
and deliberately and edit their writing using a keyboard before
submitting it.

> Newly opened issues are labelled with `needs-triage`.

This proposed triage process, which is based on issue labels, seems
like it will add additional barriers to new contributors. Today,
anyone with a Jira account can triage issues, but it seems like to
manage issue labels in the proposed system users will first need to be
given GitHub triage permissions.

[Richard Bywater]

Have been following the thread and realise it's only one of the points mentioned but if a barrier to accessing Jira is the login, has any thought been given to allowing GitHub credentials to be used to access Jira? (Not sure about underlying authentication system to know how easy or hard this would be though 😀)

Richard.

--
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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjriE6Xf_hLN_y_XEbyApJ39qSo0Pn%2BRB%3Da_iCH_9CB2eQ%40mail.gmail.com.

[Tim Jacomb]

Yes there's been some work / plans around this for a while. (~2 years)

A number of issues around it here: https://github.com/jenkins-infra/helpdesk/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+keycloak

No progress on it recently though.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwcdVCZHntQJUwQ346gHVRprOabNaTOt7fqizze6ytoZrA%40mail.gmail.com.

[Tim Jacomb]

Hi Basil

I've updated the JEP, could you please take another look when you have time?

Thanks

Tim

[Basil Crow]

On Wed, Jun 29, 2022 at 1:17 AM Tim Jacomb <timja...@gmail.com> wrote:
> I've updated the JEP, could you please take another look when you have time?

My sense from reviewing the additions is that GitHub issues lacks
feature parity with Jira on a number of fronts and that preserving
existing functionality without regression could only be achieved with
significant development effort to write and maintain automation/bots
(or adapt existing ones like Prow or Skara) to work around these
deficiencies. I think the cost of this is high compared to the cost of
staying on Jira (moving from traditional hosted Jira to Jira Cloud
when it becomes necessary) and thereby retaining existing
functionality without needing to invest our own development effort.
Given our limited development resources, my preference would be for us
to use Jira for all issue tracking and focus our development resources
on the existing backlog of user-impacting frontend and backend
projects. In general I think we are stretched thin enough that
building in-house infrastructure is impractical for us; despite the
strong arguments by Dan Luu in favor of building rather than buying in
https://danluu.com/nothing-works/ my experience is that this works
better when one is starting from a material position of strength.

> It is expected that all repositories will transition from Jira to GitHub

I think this statement implies that plugin maintainers would be
expected to take action to migrate their repositories, because if it
did not imply that, then I would expect to see a migration plan
outlined in the JEP. This expectation seems flawed to me, as I
generally think it is incumbent on the party implementing a
large-scale migration to make a good faith effort to migrate the vast
majority of consumers, as was done in JEP-227 and JEP-233. Obviously
there is a point of diminishing returns to such efforts, and different
people have different thresholds as to what that point is, but the
basic point is that the burden on core and plugin maintainers should
be minimized as much as possible and ideally eliminated completely but
for specific (justified) exceptions. For example, moving from our
traditional Jira server to Jira Software Cloud (with HTTP redirects if
necessary) would be almost completely transparent to core and plugin
maintainers from the perspective of existing Jira issues, which are
the vast majority of our existing issues.

> For Jenkins core issues we make use of ChatOps to allow people without privileges to do some triage themselves.

But this does not address the problem of labels in plugins. I see no
reason why core would be any different from a plugin from the
perspective of users needing to be able to label issues (e.g., for
tables-to-divs or SVG icon issues in plugins).

> If we do wish to maintain the ability to move issues for anyone or at least org members

Per JEP-1, JEP submissions should contain "a minimal prototype
implementation sufficient to convey the viability of the design". I do
not see a minimal prototype implementation of this functionality in
the JEP submission.

> Look at the any issue references that show in the issue view

But these issue references do not appear in one place in the issue
view: they are scattered throughout the issue comments, making them
hard to find in long threads. Also I cannot see a way to delete an
incorrect issue reference, so incorrect issue references will clutter
the view as well. In contrast, Jira displays the linked issues in one
visual area, and it provides rich functionality to add, remove, and
edit these links, even allowing you to link to an arbitrary web page
with your own title if the existing relationships are unsuitable.

> Use a GitHub search […] Use a GitHub issue filter in the repository

Seems fragile, as it relies on a non-standard schema ("Caused by:
https://github.com/organization/repository/issues/ID"). Users might
not be aware of this (which would be completely understandable given
the lack of a UI) or might misspell the phrase "Caused by" (or use a
slightly different phrase), and it is unclear to me whether variations
of the issue URL (e.g., no https, just "#ID", or just
"organization/repository#ID") would all be searchable the same way.
Altogether seems weaker than Jira, and I do not think the searching
syntax is as rich as Jira Query Language (JQL).

> Custom fields and statuses

Unclear to me how a regular one-off issue in core or a plugin would
have the release version recorded if it is not part of a GitHub
project (i.e. Jira epic). Many smaller one-off issues are not part of
any GitHub project (i.e. Jira epic), but Jira still provides
visibility into their status (e.g. "In Progress", "In Review", etc)
and released version. I think this proposal would regress this
functionality for issues that are not part of a GitHub project (i.e.
Jira epic), which are the majority of one-off bug fixes. This could
possibly be worked around with a "catch-all" GitHub project, but I see
no mention of this in the JEP and I think it could be awkward to
implement.

> It is also common to have a bot that comments on an issue when it has been released in a version.

Sure but see my earlier comments about JEP-1. My point is that
reaching feature parity sounds like it would require a significant
amount of (as-yet pending) development effort, to say nothing of
long-term maintenance.

[Daniel Beck]

On Thu, Jun 30, 2022 at 10:01 PM Basil Crow <m...@basilcrow.com> wrote:

For example, moving from our
traditional Jira server to Jira Software Cloud (with HTTP redirects if
necessary) would be almost completely transparent to core and plugin
maintainers from the perspective of existing Jira issues, which are
the vast majority of our existing issues.

While I would strongly prefer this solution, Jira Cloud has a limit of 20k users even on their largest plans. While they plan to support more[1], their road map ends at 50k users, and there's a chance these slightly increased limits won't be available to us when migrating and being covered by their open source program[2].

For comparison, we have 130k users in Jira. While many are probably not legitimate users of Jira (some have never logged in but were just created by the account app when someone signed up there), and we can probably remove ones that haven't been logged in in years, I wouldn't be surprised if this limit is going to be a real problem for us.

Before we reject alternatives for not being (enough like) Jira, we should make sure, with support from Atlassian, that we're even in a situation that allows remaining on Jira for more than two years.

1: https://www.atlassian.com/roadmap/cloud?category=scale

2: https://www.atlassian.com/software/views/open-source-license-request

[Jesse Glick]

On Fri, Jul 1, 2022 at 3:22 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

we have 130k users in Jira. While many are probably not legitimate users of Jira […or] haven't been logged in in years

If we expect and even encourage that most plugins switch to GitHub for issue tracking, so that we expect Jira (Cloud) to be used mainly for core and associated components and tools (plus the `SECURITY` project), does that change the calculus? There would still be plenty of people creating an account just to report some sort of core bug (or a bug which they cannot easily map to a particular plugin), but probably not tens of thousands of them.

[Damien Duportal]

>> The barrier to entry on Jira is a lot higher than on GitHub, many people struggle to report issues.

>I do not think the barrier to entry on Jira is prohibitively high. As
others have noted, reporting issues requires a certain degree of due
diligence, including writing steps to reproduce, expected results, and
actual results.

Reporting issues with due diligence is absolutely not related to GitHub or JIRA. Both provides mecanisms (templates, etc.) to help on this area but both can be used and abused to report weird messages.

Using JIRA means "keep the same people and put an entry barrier": that is how we felt for the use case of the infra. By moving to GitHub we lost the "strictness" described by Basil (EPIC, links beetween issue with associated causality such as "blocked by", etc.).

In our case, loosing this "strictness" was clearly an annoyance, but compared to the sudden participation it was clearly worth the change.

As a Jenkins user, I think it took me 6 years before being able even start thinking about opening an issue. The mental energy that it consume only for "creating the account + understand that there is one project for core & ALL plugins + being able to search if an issue already exist + understanding this body syntax which is its own" (not mentioning what could go wrong along: account issue, permission issue, JIRA suddenly loosing message content" is HIGH.

So most of the time, I did not even started the process otherwise I was driven crazy and unable to have the "due diligence" because it was exhausting.

For the infra project, going back is not an option unless we would want to remove any willingness for people to contribute or open issues.

> If we expect and even encourage that most plugins switch to GitHub for issue tracking, so that we expect Jira (Cloud) to be used mainly for core and associated components and tools (plus the `SECURITY` project), does that change the calculus? There would still be plenty of people creating an account just to report some sort of core bug (or a bug which they cannot easily map to a particular plugin), but probably not tens of thousands of them.

Really smart idea!

[Basil Crow]

On Wed, Jul 6, 2022 at 12:33 AM Damien Duportal
<damien....@gmail.com> wrote:
> Reporting issues with due diligence is absolutely not related to GitHub or JIRA.

It is not, but the difficulty and amount of effort required to write
clear steps to reproduce, expected results, and actual results far
exceeds the difficulty and amount of effort required to sign up for
either a GitHub account or a Jira account. The latter can be done in a
few minutes after Googling for the instructions, while the former
often takes me an hour or more and requires original analytical
reasoning. In other words, the limiting factor (bottleneck) for
effective participation is not which issue tracking system is being
used but rather writing a good issue report. That is why I find the
"barrier to entry" argument weak: it lowers the barrier to entry in an
area that is not the limiting factor, much like optimizing the
performance of a rarely used method in an application does little to
help the overall performance of the same application.

[timja...@gmail.com]

Hi,

I would like to revisit this 3 years later.

There are features now available that overcome many of the issues people had at the time:

• Issue dependencies
• Sub-issues

Other new features:

• Issue types
• Marking as a duplicate
• Closing an issue as not planned
• Duplicating an issue
• Triaging an issue with AI (not tested)

595* plugins are using GitHub issues, + most development tools like plugin-pom, ATH etc

~80% of new plugin hosting requests use GitHub issues for tracking.

Other large organisations have done this sort of migration:

• Apache Maven
• Spring
• Swift

Thoughts? - I'm happy to update the JEP and re-run the mock migration.

Thanks

Tim

query*:

repository-permissions-updater/permissions [🌱 master][⏱ 2s]
❯ rg --no-heading -i 'github: \*gh' | wc -l
     595

[Jan Faracik]

I'd support this - I think it'd really help visibility/keeping everything in one spot is nice.

[Daniel Krämer]

+1 from my end.

Would also be a great opportunity to get some clean-up going for stale issues and such.

[Oleg Nenashev]

+1 for GitHub issues from me, at least as a second way of reporting for end users.

[Hervé]

Cf https://github.com/jenkinsci/jep/pull/390#issuecomment-3485221779 and noteworthy, Maven migrated from Jira to GitHub for their issues this summer: https://cwiki.apache.org/confluence/display/MAVEN/JIRA+to+GitHub+Issues+switching

--

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/595916dc-9452-428e-b4b2-6bd39898ab49n%40googlegroups.com.

[Baptiste Mathus]

AFAIK, GH issues still does not have a notion of priority/severity? It's usually all custom per project and label-based, some projects create a severity/p1, severity/p2 labels, etc. (?)

Should we consider having some kind of standard across plugins for this?

I know that some folks like Mark are used to checking the newly reported issues on Jenkins' Jira tracker across the board. 

Is https://github.com/search?q=user%3Ajenkinsci++&type=issues&ref=advsearch&state=open the best entrypoint we can have for this?

--

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/595916dc-9452-428e-b4b2-6bd39898ab49n%40googlegroups.com.

[Jesse Glick]

On a related topic, what is the current recommendation for plugin maintainers wishing to switch their component from Jira to GitHub? The last I saw was https://groups.google.com/g/jenkinsci-dev/c/g3Bn1kvoT2o/m/j8IMgO2MAQAJ pointing to https://github.com/lemeurherve/jira-issues-importer which looks a bit time-consuming. Is that still the best available system, or is there some more automated system that can be requested e.g. from the helpdesk? https://github.com/jenkins-infra/repository-permissions-updater?tab=readme-ov-file#managing-issue-trackers does not mention migration at all.

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.

[Herve Le Meur CB]

I should be able to automate jira-issues-importer if needed.

To be developped in an helpdesk issue, but I imagine it could run in a pipeline or as additional RPU stage, tbd

Le mar. 4 nov. 2025, 16:16, 'Jesse Glick' via Jenkins Developers <jenkin...@googlegroups.com> a écrit :

On a related topic, what is the current recommendation for plugin maintainers wishing to switch their component from Jira to GitHub? The last I saw was https://groups.google.com/g/jenkinsci-dev/c/g3Bn1kvoT2o/m/j8IMgO2MAQAJ pointing to https://github.com/lemeurherve/jira-issues-importer which looks a bit time-consuming. Is that still the best available system, or is there some more automated system that can be requested e.g. from the helpdesk? https://github.com/jenkins-infra/repository-permissions-updater?tab=readme-ov-file#managing-issue-trackers does not mention migration at all.

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.

--

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/CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com.

[Tim Jacomb]

> AFAIK, GH issues still does not have a notion of priority/severity? It's usually all custom per project and label-based, some projects create a severity/p1, severity/p2 labels, etc. (?)

> Should we consider having some kind of standard across plugins for this?

If we feel there's a need then we can yes, I haven't needed it in my plugins that are on GitHub issues but might be more useful when more people are looking at it.

Maven doesn't appear to use it (except on their imported issues): https://github.com/apache/maven/issues?page=1

Kubernetes uses priority/backlog, priority/important-soon etc: https://github.com/kubernetes/kubernetes/labels?q=priority%2F

Go doesn't seem to use it: https://github.com/golang/go/issues

Rust doesn't seem to use it: https://github.com/rust-lang/rust/issues

Spring boot doesn't seem to use it: https://github.com/spring-projects/spring-boot/issues

It definitely doesn't seem to be in widespread use. There's an option to do what Maven did and import from Jira as-is with priority and then see if we really need it or if we feel we're missing something

> I know that some folks like Mark are used to checking the newly reported issues on Jenkins' Jira tracker across the board. 

> Is https://github.com/search?q=user%3Ajenkinsci++&type=issues&ref=advsearch&state=open the best entrypoint we can have for this?

For general GitHub issues yes although sorted by newest would make more sense than best match:

https://github.com/search?q=user%3Ajenkinsci++&type=issues&ref=advsearch&state=open&s=created&o=desc

For Jenkins core you would be able filter by anything supported in issues like:

> which looks a bit time-consuming. Is that still the best available system, or is there some more automated system that can be requested e.g. from the helpdesk? https://github.com/jenkins-infra/repository-permissions-updater?tab=readme-ov-file#managing-issue-trackers does not mention migration at all.

Assuming the process still works smoothly it's a 5-10 minute job, but yes an automated process would be nice.

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CAL-Lwjy6wJEPmONnv4%2B5asw9dY%3DFcW1e2JSK%3DSjM6pS8VeXMfA%40mail.gmail.com.

[Lewis Birks]

I think it is a sensible idea, it would lower the barrier of entry as well as making the approach more consistent across Jenkins (plugins and core)

[Alexander Brandes]

Belated +1 from my side, thanks for driving this effort!

[Andrew Grimberg]

One of my release engineers recently wrote a jira -> github issues
importer for one of our other LF projects for when they migrated off of
Jira late last year / early this year. I'll see if I can find where she
stuck it. I know she had looked at
https://github.com/lemeurherve/jira-issues-importer but it didn't work
properly for current versions of Jira so she ended up writing one from
scratch (with some help from Claude).

-Andy-

On 11/4/25 07:36, 'Herve Le Meur CB' via Jenkins Developers wrote:
> I should be able to automate jira-issues-importer if needed.
>
> To be developped in an helpdesk issue, but I imagine it could run in a
> pipeline or as additional RPU stage, tbd
>
> Le mar. 4 nov. 2025, 16:16, 'Jesse Glick' via Jenkins Developers

> <jenkin...@googlegroups.com <mailto:jenkin...@googlegroups.com>>

> a écrit :
>
> On a related topic, what is the current recommendation for plugin
> maintainers wishing to switch their component from Jira to GitHub?
> The last I saw was https://groups.google.com/g/jenkinsci-dev/c/

> g3Bn1kvoT2o/m/j8IMgO2MAQAJ <https://groups.google.com/g/jenkinsci-
> dev/c/g3Bn1kvoT2o/m/j8IMgO2MAQAJ> pointing to https://github.com/
> lemeurherve/jira-issues-importer <https://github.com/lemeurherve/
> jira-issues-importer> which looks a bit time-consuming. Is that

> still the best available system, or is there some more automated
> system that can be requested e.g. from the helpdesk? https://
> github.com/jenkins-infra/repository-permissions-updater?tab=readme-

> ov-file#managing-issue-trackers <https://github.com/jenkins-infra/
> repository-permissions-updater?tab=readme-ov-file#managing-issue-
> trackers> does not mention migration at all.
>
> 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.
>
> --
> 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

> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> jenkinsci-dev/

> CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
> 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.
>
> --
> 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

> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> jenkinsci-dev/CAL-
> Lwjy6wJEPmONnv4%2B5asw9dY%3DFcW1e2JSK%3DSjM6pS8VeXMfA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAL-
> Lwjy6wJEPmONnv4%2B5asw9dY%3DFcW1e2JSK%3DSjM6pS8VeXMfA%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

--
Andrew J Grimberg
Senior Manager, Release Engineering
The Linux Foundation

NOTICE: The Linux Foundation supports their employees with flexible work
hours. If you recieve mail from me outside of standard business hours
please be aware that I do not expect a response until the next standard
business day.

[Tim Jacomb]

Interesting, if you find it Andrew I'll take a look, could it be Jira cloud it didn't work for?

I'm doing an import right now from Jira 9.12.x and it's working fine using that repo.

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/c49b8b99-d38f-4d7d-ac6e-1a33b3d05dcb%40linuxfoundation.org.

[Andrew Grimberg]

I don't know what the exact issues were, just that it didn't want to
work correctly. It was from Jira server to GitHub Issues. We were in the
middle of migrating other LF managed Jira instances to cloud at the time
the script was produced. The project it was developed for elected to not
switch to Jira cloud and just go to GitHub Issues and the test runs had
issues so my engineer built a new one.

She's trying to find it back.

-Andy-

On 11/5/25 09:39, Tim Jacomb wrote:
> Interesting, if you find it Andrew I'll take a look, could it be Jira
> cloud it didn't work for?
> I'm doing an import right now from Jira 9.12.x and it's working fine
> using that repo.
>
> On Wed, 5 Nov 2025 at 17:34, Andrew Grimberg

> <agri...@linuxfoundation.org <mailto:agri...@linuxfoundation.org>>

> wrote:
>
> One of my release engineers recently wrote a jira -> github issues
> importer for one of our other LF projects for when they migrated off of
> Jira late last year / early this year. I'll see if I can find where she
> stuck it. I know she had looked at

> https://github.com/lemeurherve/jira-issues-importer <https://
> github.com/lemeurherve/jira-issues-importer> but it didn't work

> properly for current versions of Jira so she ended up writing one from
> scratch (with some help from Claude).
>
> -Andy-
>
> On 11/4/25 07:36, 'Herve Le Meur CB' via Jenkins Developers wrote:
> > I should be able to automate jira-issues-importer if needed.
> >
> > To be developped in an helpdesk issue, but I imagine it could run
> in a
> > pipeline or as additional RPU stage, tbd
> >
> > Le mar. 4 nov. 2025, 16:16, 'Jesse Glick' via Jenkins Developers

> > <jenkin...@googlegroups.com <mailto:jenkinsci-
> d...@googlegroups.com> <mailto:jenkin...@googlegroups.com

> <mailto:jenkin...@googlegroups.com>>>
> > a écrit :
> >
> >     On a related topic, what is the current recommendation for plugin
> >     maintainers wishing to switch their component from Jira to
> GitHub?
> >     The last I saw was https://groups.google.com/g/jenkinsci-dev/

> c/ <https://groups.google.com/g/jenkinsci-dev/c/>
> >     g3Bn1kvoT2o/m/j8IMgO2MAQAJ <https://groups.google.com/g/
> jenkinsci- <https://groups.google.com/g/jenkinsci->

> >     dev/c/g3Bn1kvoT2o/m/j8IMgO2MAQAJ> pointing to https://

> github.com/ <https://github.com/>
> >     lemeurherve/jira-issues-importer <https://github.com/
> lemeurherve/ <https://github.com/lemeurherve/>

> >     jira-issues-importer> which looks a bit time-consuming. Is that
> >     still the best available system, or is there some more automated
> >     system that can be requested e.g. from the helpdesk? https://
> > github.com/jenkins-infra/repository-permissions-updater?

> tab=readme- <http://github.com/jenkins-infra/repository-permissions-
> updater?tab=readme->
> >     ov-file#managing-issue-trackers <https://github.com/jenkins-
> infra/ <https://github.com/jenkins-infra/>

> >     repository-permissions-updater?tab=readme-ov-file#managing-issue-
> >     trackers> does not mention migration at all.
> >
> >     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.
> >
> >     --
> >     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

> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>
> >     <mailto:jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>>.

> >     To view this discussion visit https://groups.google.com/d/

> msgid/ <https://groups.google.com/d/msgid/>
> >     jenkinsci-dev/
> >
>  CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com <http://40mail.gmail.com> <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr31GuD6pR4MdhtLbN%3DFYZgS2M5m0bTQ%2BaaKVnM5wJeb8w%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

> >
> >
> > 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.
> >
> > --
> > 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

> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>
> > <mailto:jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>>.

> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > jenkinsci-dev/CAL-
> >
> Lwjy6wJEPmONnv4%2B5asw9dY%3DFcW1e2JSK%3DSjM6pS8VeXMfA%40mail.gmail.com <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/jenkinsci-dev/CAL- <https://
> groups.google.com/d/msgid/jenkinsci-dev/CAL->
> >
> Lwjy6wJEPmONnv4%2B5asw9dY%3DFcW1e2JSK%3DSjM6pS8VeXMfA%40mail.gmail.com <http://40mail.gmail.com>?

> > utm_medium=email&utm_source=footer>.
>
> --
> Andrew J Grimberg
> Senior Manager, Release Engineering
> The Linux Foundation
>
> NOTICE: The Linux Foundation supports their employees with flexible work
> hours. If you recieve mail from me outside of standard business hours
> please be aware that I do not expect a response until the next standard
> business day.
>
> --
> 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

> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> jenkinsci-dev/c49b8b99-d38f-4d7d-
> ac6e-1a33b3d05dcb%40linuxfoundation.org <https://groups.google.com/
> d/msgid/jenkinsci-dev/c49b8b99-d38f-4d7d-
> ac6e-1a33b3d05dcb%40linuxfoundation.org>.

>
> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> jenkinsci-dev/

> CAH-3BieB1buux55jcyvhrFxwnHh88Tyw_BMLkKbwC7vhm%3DM_Qg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/
> CAH-3BieB1buux55jcyvhrFxwnHh88Tyw_BMLkKbwC7vhm%3DM_Qg%40mail.gmail.com?

[Tim Jacomb]

I ran a complete migration here: https://github.com/timja-org/jenkins-gh-issues-poc-11-04/

Please take a look and let me know what you think.

Daniel provided some feedback that I've addressed some of in https://github.com/timja-org/jenkins-gh-issues-poc-11-06/issues

That run isn't a full run and post processing hasn't happened on it (e.g. issue type changing and remapping epics to parent child relationship)

Outstanding feedback:

* Attachments are not migrated

* Some descriptions don't render well as the script in use takes an HTML export from Jira rather than trying to handle Jira markup

Some FAQs are in https://github.com/jenkinsci/jep/pull/415

[Tim Jacomb]

- Attachments are now linked to in the migration.

Setting a deadline for feedback: Thursday 12th November.

Thanks

[Tim Jacomb]

*13th November

[Jesse Glick]

On Thu, Nov 6, 2025 at 10:42 AM Tim Jacomb <timja...@gmail.com> wrote:

I ran a complete migration here: https://github.com/timja-org/jenkins-gh-issues-poc-11-04/

Please take a look and let me know what you think.

These all seem to be rather old issues. It might be more helpful to see the result of a sample of recently filed issues, which may tend to use different idioms and Jira capabilities.

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.

[Tim Jacomb]

Sort by created and you'll see recent ones, the linked export has data up till 3 days ago: https://github.com/timja-org/jenkins-gh-issues-poc-11-04/issues?q=%20is%3Aissue%20is%3Aopen%20sort%3Acreated-desc

See here for the latest migration that includes the attachments improvement: https://github.com/timja-org/jenkins-gh-issues-poc-11-06-a2/issues?q=%20is%3Aissue%20is%3Aopen%20sort%3Acreated-desc

--

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/CANfRfr2B2mKNTFF3P%2BUavDnNW9Bb34_m4dKQnX10i98x4PSSYw%40mail.gmail.com.

[Ullrich Hafner]

I'm not a core developer, but as a plugin developer switching core to GitHub Issues would increase the burden for all of us who still use Jira. It's already a problem that I can't reassign issues to components that no longer exist in Jira. If we decide to move to GitHub Issues, we should migrate all components to GitHub, not only the core ones.

--
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/858968c8-ea04-4648-b9e1-185224653f4bn%40googlegroups.com.

[Tim Jacomb]

I agree but that migration would be a lot more complex.

I think it should be done in phases.

e.g.

* No new components on Jira

* Migration of core components

* Self service migration of plugins

* Migrate existing plugins that have dual issue tracker

* Migrate remaining components

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/B1A4CC0B-D74C-446A-8351-9FEE633E02EA%40gmail.com.