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.