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 <ja...@potiuk.com> Sent: Saturday, September 25, 2021 7:13 AM To: Juan Pablo Santos RodrÃguez <juanpablo.san...@gmail.com> Cc: Beckerle, Mike <mbecke...@owlcyberdefense.com>; us...@infra.apache.org <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&paste 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 there so that the user can click and create discussion easily from the issue form. You can take a look at our issue templates here: https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE And you can try an experience of entering Airflow issue here: https://github.com/apache/airflow/issues/new/choose GitHub Issues were already super-useful when we switched 2 years ago - but now with Issue Forms and GitHub Discussions together, they are GREAT. Also I am discussing with GitHub about the possibility of using the (optional) new "tabular" GitHub Issues experience https://github.blog/2021-06-23-introducing-new-github-issues/ they introduced recently (my friend is a lead engineer in GitHub who developed them and I know the Product Manager of it personally). It is in Private beta stage now and not yet available for Public projects, but they promised October-ish time frame to get it available to Public projects (I also got the promise that ASF is the first on the Beta list to try when they are made available for Public projects). From what I saw in the demo I got from them - this will enable all kinds of automation and management that we miss currently. You will be able to see the issues in spreadsheet-like form, add custom attributes, and build all kinds of automation around the issues more easily. This will enormously help us with automated triaging of the issues. J. On Fri, Sep 24, 2021 at 11:37 PM Juan Pablo Santos RodrÃguez <juanpablo.san...@gmail.com<mailto:juanpablo.san...@gmail.com>> wrote: Hi Jarek, that was an interesting point of view regarding the use of github issues... At JSPWiki I find myself with more or less the same problems you note with jira, although not as painful, as JSPWiki has a considerably slower pace of development, and had thought of asking on our dev ML about changing to gh issues. However I've got myself a few questions regarding this kind of transition before carrying it to the dev list, and this thread looks like a good place to ask O:-) * Did you export / import the jira issues to github? ** 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.. ** 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)? ** If not, how do you handle the issues on the jira side? * How do you deal with security reports inside github issues? thx in advance! regards, juan pablo [#1]: https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues [#2]: https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues [#3]: https://github.com/hbrands/jira-issues-importer [#4]: https://github.com/doctrine/jira-github-issues [#5]: https://gist.github.com/graemerocher/ee99ddef8d0e201f0615 On Thu, Sep 23, 2021 at 4:21 PM Jarek Potiuk <ja...@potiuk.com<mailto:ja...@potiuk.com>> wrote: It's quite OK to only use Github Issues/Discussions - we switched to GH in Apache Airflow ~ 2 years ago I think. And a comment from our perspective of a big project that uses GitHub Issues at its inception, switched to JIRA and finally returned back to GitHub issues when they matured. Others might have different experience but this is ours (and I am pretty sure I am representing view of pretty much whole Airflow community). I witnessed just the last switch - from JIRA to GitHub. We stopped using JIRA in Apache Airflow in favour of GitHub Issues and Discussions and we NEVER looked back. Not a minute. Not even a second. Absolutely no-one missed JIRA. Not by far. That was such an amazing improvement in the overall workflow and contributor's engagement. I don't even imagine how we would be able to run the project with JIRA. The overall experience, integration level, overhead needed to manage JIRA issues, dual-logging-in and syncing between the two were absolutely unmanageable for us. With GitHub Issues we chose to base our "change tracking" based on PR# rather than Issue # optional and it made a whole world of difference. Especially recently with GithubDiscussions added to the mix and ability to convert issues into discussions (and back) if they are not real issues. J. On Thu, Sep 23, 2021 at 4:01 PM Beckerle, Mike <mbecke...@owlcyberdefense.com<mailto:mbecke...@owlcyberdefense.com>> wrote: I read a old blog post from infra about increasing github integration. I am wondering about Apache JIRA, vs. using the issues feature of github, for an Apache project repo. Can we use github's issues feature, or do we have to use Apache's JIRA? Is there a policy, or even strong preference on this issue? Thanks Mike Beckerle Apache Daffodil PMC
