Some feedback on the input given about GH:
1.
> markup is harder in JIRA
Not true. In GH:
```
code block
```
or `variable callout`
In JIRA:
{code}
code block
{code}
or {{variable callout}}
For URL embedding w/ a different label:
GH:
JIRA:
So... ok, sure, it's a couple more keystrokes, but it's just as effective once you learn how.
2.
> can't log in with github to use JIRA
> not having to register in yet another tool, even if is just through github sso
And since we're required to use our own dogfood, everyone using che.openshift or dev sandbox
will already have an account to use with JIRA. How's that for single-sign-on?
Definitely not anti-community either as anyone trying the dev sandbox can immediately also use JIRA.
3.
> Having the code next to the issue tracker is a big benefit at the moment, so I prefer to keep using GH.
> Having the code and issue tracker in one system is IMHO great for community involvement
Not to be argumentative but to genuinely flesh out the user stories involved...
Why do people feel issues need to be tracked with the same tool as the code?
Are we not employed in the business of creating a UI that replaces the need for GH's UI?
Are you saying that even with Che being awesome and CRW being rebranded-awesome, you'd
all still rather use a GH UI page to handle PR reviews and merges?
Or is the concern around GH actions and process automation?
Conversely, does anyone here use CLI or alternative UI tools for merging PRs, or diffing changes?
If so, why did you start using a different tool to achieve what could be done w/ GH UI? Was it better?
easier? more feature rich? Could that functionality be brought into Che?
4.
> I like GH better
Could you provide more input into WHY? If it's 'the devil you know' vs. something unknown, that's understandable. But there was a time when we all didn't know what Che was, or what OpenShift was, and now we do. At some point it's OK to embrace the new and discover how it can benefit us. Remember when it was just vim vs. emacs, or svn vs. git?
5.
> I don't use issue metadata or do sprint planning so extra features don't benefit me
Fair point, but if you don't benefit from improved features in JIRA then you also won't be hurt by it. Is it fair to make those who DO benefit from improved features suffer, when there's an alternative available?
And if you have to use JIRA already because of product requirements, wouldn't your life be made easier by not having to use two tools to handle Che/CRW issues?
(Yes, I understand that things upstream of Che - like Theia and Traefik - won't move, and will therefore cause some people to still have to use GH issues, but that's just a couple corner cases. I'm mostly thinking of the greater good for the dozen other projects (server, dashboard, ws loader, devfile 2.0 / devworkspace, operator, machine-exec, jwtproxy, the plugin brokers, the sidecars, the registries, configbump, and whatever else is coming soon :D ).
Thanks for the feedback! Please keep it coming and if you can add more info to the questions above, I'm genuinely interested in hearing what people have to say on this topic.
6.
> cross-linking between GH projects (issues and PRs)
Admittedly, I don't have a 1:1 100% solution offhand for this one in terms of automatically linking between a PR and an issue, BUT Smart Commits in JIRA does partially solve this. It's a bit like using semantic comments (which has been enabled on some of the Che repos) to encourage chore() and bug() labels on commits. If you use smart commit comments in JIRA, we can get crosslinking and even auto-resolve issues.
And there's no good answer for doing cross-linking between JIRA projects and GH projects that I know of, but it's possible something exists there too, eg., from the Debezium project that Lukas mentioned.
But that said, if all the Che issues were in JIRA, we'd get cross-linking of issues between repos automatically, like we do in CRW JIRA today when you refer between a platform JIRA and a plugins JIRA or an editors JIRA. That already works and is great for setting up issue dependencies.
7.
I'm surprised there's been no input from docs or QE yet -- any thoughts on all this? How do you handle the fact that GH issues only has only open or closed status, but no distinction between "resolved by dev, built and ready to test" before "closed by QE once verified", like we have with JIRA? Is having 3 states better than 2, so you can more easily track what's ready for verification vs. what's been verified to be working?
Thanks!
Nick
