FYI: a pretty interesting going discussion on users@infra that I am on a CC
trail about using github issues vs. Apache JIRA, and the experience of Apache
Airflow in switching to GH.
From: Jarek Potiuk
Sent: Saturday, September 25, 2021 7:13 AM
To: Juan Pablo Santos RodrÃguez
Cc: Beckerle, Mike ; us...@infra.apache.org
Subject: Re: Apache JIRA vs. github "issues"
* Did you export / import the jira issues to github?
We initially thought about that and even started doing it, but eventually we
decided not to do that and "leave" the JIRA issues behind. We moved some
"important" ones and then we informed everyone and asked for help with that in
devlist/userlist/slack etc. that if they are still interested in their issue -
they can copy them over. And we keep info about it in our README for quite a
while. A lot of people did.
I personally think this is a really great way to engage with the community and
ask them to help. We have to remember that as committers and PMC members we do
not have to do everything ourselves - we can always reach out to our community
for help. And it worked really nicely. Those authors of issues who did not do
this were apparently not interested any more, or maybe they did not follow the
issues they created, or maybe the issues were gone already (or even if they
were real issues there was no-one to verify them) so we let the issues "rot"
there.
That was a very good choice. A lot of issues we had in jira were already
out-dated or of poor quality, so that automatically cleaned up the state of our
issues. I personally think that if it is not obvious that an issue is really
important and if the author of the issue is not interested in adding extra
information if asked or if they are not following up with them - they are
better if they are "forgotten". They add no value to the project, they only add
"noise". This is why I love GitHub discussions so much. We can convert the
issue to GitHub Discussion if we look at it and it is likely the issue is
caused by user error, deployment issue etc. This does not "close" the issue
(which is quite mean) - but it moves the "responsibility" for the discussion to
continue on the author - it's a very clear sign that the discussion might be
left in the state of "discussing it" and there is no intention or expectation
that it will be fixed. And we can always create an issue from the discussion if
we get to the conclusion this is a real issue. This already happened in the
past.
** if so, how? I've found several articles/projects ([#1], [#2], [#3], [#4],
[#5]) but they all seem to be customized to specific projects needs..
See above. We crowdsourced it by asking the authors to move the issues to GH
:D. Not a "tool", but it was a great choice for user engagement, community
building, etc.
** how an issue assigned to several fix versions is translated to gh issues?
Was any markdown conversion between jira and gh done (issue descriptions,
comments)?
See above. ^^ :).
** If not, how do you handle the issues on the jira side?
We just closed JIRA issues for entry and I think we left a comment in CWIKI
space which we used much more then, that the GH issues are now being used.
* How do you deal with security reports inside github issues?
We have those really nice templates for GitHub Issues as of recently (this is
another benefit of GH Issues - they have those really nicely working Issue
Forms - which do a FANTASTIC job to make our issues much more quality issues -
for example in the forms we instruct the users that if they have no
reproducible steps, they should open GitHub Discussion instead - this already
happened multiple times). One of the options in the issue form configuration is
to provide a "BUTTON" instead of form for some types of issues which link to an
external site. We have a link there to the security pollicy
https://github.com/apache/airflow/security/policy which clearly states that no
GH issues should be opened, but the regular ASF security process should be
followed (with the email to securty@a.o).
I HEARTILY recommend to introduce well thought and prepared issue forms when
you move to GH issues. We already see tremendous improvement in the quality of
reported issues, and a lot more GitHub discussions opened up instead of issues.
The nice things about those forms is that they introduce a bit of "friction".
It's not just copy or type your frustration - you HAVE TO choose version
of Airflow, you HAVE TO describe your OS, you HAVE TO choose deployment - and
if you did not respond to reproducibility steps, there is a clear "No response
was given to that" in your issue which in VAST majority of cases immediately
qualifies the issue to be converted to discussion (which we often do) -
especially that during issue entry we explicitly tell the users that "bugs
without reproduction steps should be opened as discussions instead" - and we
even have links
