Any other opinions? So far we have 3 +1, and 1 -1
This isn't asking that we move everything over, but make it easier for new plugin maintainers to use GitHub issues. Thanks Tim On Mon, 3 Feb 2020 at 13:06, Chris Kilding <chris+jenk...@chriskilding.com> wrote: > I'm inclined to agree with Joseph and Tim. > > When maintaining my plugin I often wonder how many bug reports I'm losing > because users either: > > - Can't find their way through our bug tracking system (and all the labels > and categories that a bug must be annotated with), compared to GH Issues > which is very simple. > - Get discouraged from reporting a bug because they're more annoyed by > making yet another online account / username + password. > > Occasionally, users have reported their bugs in comments on active GitHub > PRs where wholly different bugs are being worked on, as this is the only > way they've been able to reach out within the GitHub ecosystem, and it's > still lower friction than Jira. > > My plugin is a leaf node in the plugin ecosystem, i.e. it is an > implementation of a Jenkins API with no further code dependents. Possibly > as a result, issues that have been reported tend not to reach beyond the > plugin itself in scope, and I've never seen an issue that was incorrectly > reported (and needed to be transferred). This category of plugins would be > ideal to move to GH issues as a first step. > > Chris > > On Sun, 2 Feb 2020, at 3:34 PM, Joseph P wrote: > > As a maintainer I find it very difficult that I have to use Jira for inter > project work. > > - Question what username you have on Jira not always the same > - find Jira searching very bothersome compared to some of the logical > either code searches or be it issue searches. > - Tim and I have been very thankful to be able to search across > JenkinsCI org on github. > Here is a good example of inter project communication: > https://github.com/jenkinsci/bom/pull/172 > > - do not find components very useful. > - Have to ask to be made default assignee > - That means going to IRC and poking people š» > - I might miss someone because only one can be assigned and people do > not use watchers. > - find it a lot easier to look in the pom.xml or see commit history > and ping those who might know something on github. > - Getting these dreaded emails that just keep pilling up in our inbox š°. > - Prefer github that allows you to subscribe and unsubscribe and their > web notifications JUST WORKS and even better with the new Notification beta. > - often forget in Jira on the components that might interest me. > - You have to be a JQL wizard to find anything again! š§āāļø > > - Jira is slow compared to GitHub. > > - Jira integration is just bad compared to what you can get from > interlinking issues and pull requests on GitHub. > > - Jenkins already has a bad situation of too many systems to handle > messaging and source configuration management. Case in point being this > mailing list š > - Would be awesome to simplify on a single chat platform and a single > SCM. > > Again finding something again in Jenkins means I have to look either into > mailing lists, Jira, confluence, IRC, gitter, slack or GitHub. > Perhaps I missed something. > > Would be great if we could boil it down to two š¤Æ > > For crying out loud I had to ask on GitHub where to find this body of > work: > https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871 > > > On Sunday, February 2, 2020 at 3:10:33 PM UTC+1, Ullrich Hafner wrote: > > I donāt think that this is a good idea to support two different issue > tracker landing pages. As we encourage every body to host everything in > *one* location (i.e., GitHub) we should also enforce (well at least work > towards) a unique landing page for issues from our users. Otherwise users > are confused where to report issues, where to look for existing issues etc. > > Also it makes inter-project communication for developers more complicated. > Very often issues are not only related to one component, and currently it > is quite easy to ping the component lead of the other component or to > reassign to a different component, etc. For instance, some time ago I > reported an incompatibility of a Jenkins plugin with the JCasC plugin: it > was very cumbersome to check if I should use GitHub or Jira to report the > issue. > > What might make sense to discuss is, if we should replace Jira with GitHub > issues for all projects? I doubt that GitHub issues are already a > replacement for such a sophisticated tool like Jira, but maybe other > developers see that differently. > > On the other hand, maybe we can improve our existing development process > so that the missing peaces from your requirements get integrated into Jira: > > > - Easy subscription to issues / pull requests for repositories I > maintain / co-maintain > > > This is quite easy in Jira as well. > > > - Much easier to be a co-maintainer, with JIRA only the ācomponent > leadā gets notified by default, you _can_ create your own filters and > subscriptions, but itās a lot more effort and most people (including me) > donāt do that. > > > I think I donāt get the point here, maybe you need to clarify why Jira is > here more complex > > > - Tight integration with SCM, issues are closed when a pull request is > merged, and you can click on a commit to see what version it was released > in, JIRA on the other hand is very out of sync. > > > We had that in Jira as well. The service was located on Kohsukeās server > is now not running anymore. I think it would be awesome if we could restore > that integration. Maybe we can use the existing Jira Jenkins plugin for > that task. > > Am 02.02.2020 um 12:13 schrieb Tim Jacomb <timja...@gmail.com>: > > Hi > > GitHub issues use is growing in the ecosystem, many plugins are now using > it, > > Some benefits from my experience in using it: > > - Easy subscription to issues / pull requests for repositories I > maintain / co-maintain > - Much easier to be a co-maintainer, with JIRA only the ācomponent > leadā gets notified by default, you _can_ create your own filters and > subscriptions, but itās a lot more effort and most people (including me) > donāt do that. > - Tight integration with SCM, issues are closed when a pull request is > merged, and you can click on a commit to see what version it was released > in, JIRA on the other hand is very out of sync. > > > Some repositories that are using them: > https://github.com/jenkinsci/configuration-as-code-plugin, > https://github.com/jenkinsci/slack-plugin, > https://github.com/jenkinsci/google-compute-engine-plugin > And many more... > > Iāve heard that this was raised a year ago or so, and there were two > reasons that it wasnāt adopted: > > - Delete issues support - for security fixes, GitHub now supports this > - Transferring issues - now supported, but I think you need write > access, may need a bot to ease this, but we can see how this goes. > - Cross repository / component work - Thereās now organisation level > projects that can be used to group and track issues across projects > https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), > https://github.com/orgs/jenkinsci/projects/1 (Community Bridge: > Jenkins Configuration-as-Code developer tools), this doesnāt solve the > issue of a bug in multiple components, thereās a few ways this could be > solved, one issue for tracking it, tagging the maintainers teams in the > issue, reporting it multiple times and linking the issues together > (possibly the best option?). > > > I think it makes sense to offer an option during the hosting process on > which issue tracker the maintainer wants to use. > > Currently maintainers are able to enable GitHub issues themselves after > the repo is hosted but that leaves them with a JIRA component that users > who are used to Jenkins JIRA might report issues into. > > I would also suggest that we add some text to the Component field that > says: > āMany components use GitHub issues now, if you canāt find the component > create an issue on componentās GitHub repository. > > Any feedback or questions? > > 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 jenkin...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/7f2ffee6-9a49-475f-afa8-e09628527d0f%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/7f2ffee6-9a49-475f-afa8-e09628527d0f%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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/56145d0a-7eb1-4414-ad5b-a7991d8b918d%40www.fastmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/56145d0a-7eb1-4414-ad5b-a7991d8b918d%40www.fastmail.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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie8jJ%2BY_RrFQD%2BJ_qChjdHN7evrjtJ93viavVRKsCaE2A%40mail.gmail.com.
