On Mon, 27 Sept 2021 at 11:11, Neil C Smith <[email protected]> wrote: > It was the process aspects of > the two linked posts that seemed to make this more interesting than an > argument over tools. Maybe I picked the wrong subject line! :-) I'll > check with Jarek about reposting both in full here.
OK, both posts from Jarek in full, with permission, below for anyone unable to access the list archive. There's also the possibility some of this will end up revised on a wiki page around GitHub best practices across ASF ... On Thu, 23 Sept 2021 at 15:21, Jarek Potiuk <[email protected]> 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 Sat, 25 Sept 2021 at 12:14, Jarek Potiuk <[email protected]> wrote: > > * 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 [email protected]). > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
