I prefer Jira, from a developer and a user perspective: Developer perspective: - Having the ability to move issues from one component to another is very helpful for me. I don’t see how to do this in GitHub. My plugin uses different components and I want to easily move issues from one component to other components. Also it is very helpful to create issues that affect several components. It makes inter-project communication much simpler. - I also think that Jira has far more powerful features: dashboards, Kanban boards, epics and sub-tasks, powerful search, IntelliJ integration, workflows, issue resolution (resolved, fixed, duplicate, etc.), searchable IDs like JENKINS-50000 that you can enter in Google Search, just to name a few. It even has a wonderful mobile App (that we currently can’t use since our Jira version is sooo old).
Users perspective: - Searching for all existing issues in Jira is very easy. Selecting multiple components if the reporter is not sure about the right component is also very simple. I think users will be annoyed if they need to switch between two different systems just because the issue has been reported in a wrong component and in the wrong issue tracker. I understand that GitHub also has some benefits, like a smooth integration with commits and PRs, or the fact that we do not need to host it. GitHub is also fast and modern (but Jira 8.x improved a lot on that side, maybe it would help to upgrade to a more recent version on our side). > Am 11.06.2020 um 17:26 schrieb Jeff Thompson <[email protected]>: > > On 6/11/20 8:32 AM, Slide wrote: >> The big problem with GitHub issues is when a bug involves multiple >> components, or is filed against the wrong component. If you filed an issue >> in the wrong component, what would you expect the maintainers of that >> component to do? I don't think it should be on them to find the right >> component, so the issue just gets closer and possibly not seen by the >> correct people? I definitely prefer GitHub issues, but we need to address >> some issues like I describe above. > These are the big issues with moving away from a system-wide tracker to > individual trackers. Jenkins is a system of interacting components and issues > may involve multiple. > > As Remoting maintainer I see this frequently. Someone may submit an issue > against Remoting, but often it has to do with a plugin and just shows up in > Remoting. Eventually Remoting is removed from the components list and the > correct one is assigned. Then the maintainer of that one has notification. > Sometimes it helps define the problem. Someone submits the issue against > Remoting and a plugin that might show up in the stack trace or messages. I > look at it and have no idea, but the maintainer of the other component > quickly identifies it. > > Sometimes something is submitted against core but we decide it needs to be > fixed somewhere else. Or vice versa. > > And then there are security issues. We manage security issues as a Jenkins > system. > > If we switch to tracking issues solely by individual component we're going to > lose track of a lot of things. Well, a lot more than we already do. > > Jeff > > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/888f8585-767d-b195-8e77-307d3f03c82c%40cloudbees.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 on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E40E03EE-1538-487E-A5AF-D1162E5D4B14%40gmail.com.
