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