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? Le mar. 4 nov. 2025 à 11:09, Oleg Nenashev <[email protected]> a écrit : > +1 for GitHub issues from me, at least as a second way of reporting for > end users. > > On Tuesday, November 4, 2025 at 10:19:18 AM UTC+1 [email protected] > wrote: > >> I'd support this - I think it'd really help visibility/keeping everything >> in one spot is nice. >> >> On Monday, 3 November 2025 at 22:26:17 UTC [email protected] wrote: >> >>> 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 >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-issue-dependencies> >>> - Sub-issues >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues> >>> >>> Other new features: >>> >>> - Issue types >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization> >>> - Marking as a duplicate >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/duplicating-an-issue> >>> - Closing an issue as not planned >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/closing-an-issue> >>> - Duplicating an issue >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/duplicating-an-issue> >>> - Triaging an issue with AI >>> >>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/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 >>> >>> <https://open-elements.com/posts/2025/08/08/jira-issue-to-github-issue-migration-in-apache-maven/> >>> - Spring >>> >>> <https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues> >>> - Swift >>> >>> <https://forums.swift.org/t/swift-bugs-are-moving-to-github-issues-and-we-need-your-help/56125> >>> >>> 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 >>> On Wednesday, 6 July 2022 at 16:55:54 UTC+1 [email protected] wrote: >>> >>>> On Wed, Jul 6, 2022 at 12:33 AM Damien Duportal >>>> <[email protected]> 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. >>>> >>> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/jenkinsci-dev/595916dc-9452-428e-b4b2-6bd39898ab49n%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/595916dc-9452-428e-b4b2-6bd39898ab49n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7On_nE4Fv6dX_sAUE_GyKh_YG2w53doxZwkrDwh5KdxQ%40mail.gmail.com.
