Re: [che-dev] Issue tracking, triage, and sprint planning: is there a be

[Eric Williams <ericwill@xxxxxxxxxx>]

Thanks for bringing this up Nick.

From my POV, GitHub issues isn't a suitable issue tracker for complex 
open source projects like Che. There are just so many basic features 
missing. The fact that we had to create an automated Google Sheet to 
extract functionality already present in other issue trackers speaks 
volumes to that.

From my experience, GitHub is well suited to smaller projects that 
focus on one area/scope, and don't have 20+ full time developers working 
on it, or a complex productized version.

Listing other communities using GitHub isn't really an argument for it, 
because the same can be done for communities using Bugzilla or JIRA. The 
Linux kernel, arguably the most successful open source project in the 
world, uses Bugzilla. Instead, we should be looking at the qualitative 
points brought up for/against GitHub, and discuss them in the context of 
our project's needs. Otherwise a lot of this will boil down to personal 
preference and nothing will improve.


On 2/16/21 10:58 PM, Nick Boldt wrote:
> A topic raised recently in a retrospective brought to light the fact 
> that there are some features missing in GH Issues, which are implemented 
> in other issue trackers.
>
> Some of these features involve...
>
> * improving notifications of new issues by component (eg., Che server or 
> Che dashboard) or by team/area label

This is a huge one. As a team lead, I shouldn't have to sort through 
100+ emails every day to find which issues are relevant for my team. 
GitHub also provides no notification when labels are added/removed, or 
when milestones are added/removed. And because we are doing priority via 
labels (GitHub has no built-in priority system), I do not get notified 
if someone changes the priority of issues for my team. The same applies 
to milestones and other important metadata.

Not being notified for such things requires a lot of manual work and 
unneeded overhead.

It would be really nice if we could rely on GitHub only for code 
reviews/PRs. Personally, I have observed strong "notification fatigue" 
in Che, where lots of developers aren't responding to PRs they are 
automatically added to, simply due to the sheer number of emails they 
get every day.


> * improving triage by assigning new issues to team leads instead of via 
> round-robin by non-SMEs

Che is the only project I have encountered that does this, and frankly 
it's still kind of strange to me.

Ideally, incoming issues should be handled on a per-component basis, by 
the component owner (whether that's a TL, or a group of committers) who 
is most familiar with the subject area. Looking in a Mattermost channel 
for a daily triage report (that comes at various times of the day), is 
unnecessarily complicated. It also introduces inconsistencies into the 
triage process, because triaging is done by someone new every day.

To me it also seems that we have this triage system mostly because of 
shortcomings in GitHub's issue tracking functionality. JIRA solves this 
problem with component owners, Bugzilla solves it even further by 
allowing anyone to follow the bug inbox.


> * improving metadata (milestones, new&noteworthy, severity, priority) 
> set on issues, to make it easier to do project/product releases
> * reducing manual steps involved in triage, prioritization, sprint 
> planning, and handling of unplanned urgent issues
> * querying for issues closed across multiple milestones, labels, and/or 
> team assignees
> * identifying resolved issues (fix is merged) vs. verified issues (fix 
> exists in a built binary and has been tested to work)

Agreed on all points. I spend time each sprint doing things manually in 
GitHub when the same workflow in JIRA is quite a bit easier. Things like:

- bulk editing of issues (labels, milestones)
- querying: JIRA has vastly superior querying abilities, and they can be 
saved for future use
- sprint planning: in JIRA this would just be a simple query instead of 
a list of GitHub issues
- no manual duplication of upstream and downstream issues
- better metadata, instead of forcing our use cases into GitHub labels
- notifications for important events like when someone edits a comments, 
modifies issue metadata, and more


> Here's a quick comparison of how some of the above concerns might be met 
> by using a more feature-rich tracker:
>
> https://docs.google.com/document/d/1FJCqjzuQKLm-b00tmCJtvXHbOIzsqzZdlOZBz1VGayc/edit# 
> <https://docs.google.com/document/d/1FJCqjzuQKLm-b00tmCJtvXHbOIzsqzZdlOZBz1VGayc/edit#>
>
> Maybe it's time to consider using a different tool? If the Eclipse 
> Foundation can move from bugzilla and gerrit to gitlab, maybe we could 
> consider continuing to use Github for pull requests and code, but try 
> JIRA for its project management features? We already centralized all 
> issues into a single tracker -- could we take it to the next level?
>
> What do other community members think of this idea? Any technical 
> reasons why this couldn't work?


So far the arguments for GitHub appear to be: ease of issue linking, and 
user account integration on GitHub.

For issue linking, I will agree it is easier on GitHub. But it's not 
that much more onerous on JIRA (copy + pasting a link into a box), and 
the features that JIRA brings outweigh the ease of issue linking on 
GitHub, IMO.

For user account integration, I will also agree that more people have a 
GitHub account, than a JIRA one. However it's also important to point 
out that users will need an account to access DevSandbox, and that 
account can also be used for JIRA (as I understand it). Most of our 
current community contributors already have such accounts because they 
are using openshift.io/devsandbox, so I don't think it's that great of a 
burden.


Overall, I strongly support a move to JIRA, as having two issue trackers 
is costing development time and creates overhead. If we had to pick one 
or the other, I'd choose JIRA, simply due to feature completeness and 
product requirements. I think if we do go with JIRA, we should invest 
some time in making it as convenient as possible, i.e. implement the 
GitHub features that people are missing via JIRA plugins or other workflows.


Eric