Hi all, I think we've had a chance to discuss shortcomings and advantages. I think each person may have a different bias / preference. My bias is to move to Github, to have a more inclusive, approachable project despite the differences in workflow. So I'm +1 on moving.
Could others share their bias? Don't think of this as a vote, but I'd like to get a sense of people's preferences, to see if there's a strong/slight feeling either way. Again, the sticky points are summarized here [1], feel free to add to the doc. [1] https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit# On Mon, Jan 31, 2022 at 7:23 PM Aizhamal Nurmamat kyzy <aizha...@apache.org> wrote: > Welcome to the Beam community, Danny! > > We would love your help if/when we end up migrating. > > Please add your comments to the doc I shared[1], in case we missed some > cool GH features that could be helpful. Thanks! > > [1] > https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit# > > On Mon, Jan 31, 2022, 10:06 AM Danny McCormick <dannymccorm...@google.com> > wrote: > >> > Then (this is something you'd have to code) you could easily write or >> use an existing GithubAction or bot that will assign the labels based on >> the initial selection done by the user at entry. We have not done it yet >> but we might. >> >> Hey, new contributor here - wanted to chime in with a shameless plug >> because I happen to have written an action that does pretty much exactly >> what you're describing[1] and could be extensible to the use case discussed >> here - it should basically just require writing some config (example in >> action[2]). In general, automated management of labels based on the initial >> issue description + content isn't too hard, it does get significantly >> trickier (but definitely still possible) if you try to automate labels >> based on responses or edits. >> >> Also, big +1 that the easy integration with Actions is a significant >> advantage of using issues since it helps keep your automations in one place >> (or at least fewer places) and gives you a lot of tools out of the box both >> from the community and from the Actions org. *Disclaimer:* I am >> definitely biased. Until 3 weeks ago I was working on the Actions team at >> GitHub. >> >> I'd be happy to help with some of the issue automation if we decide that >> would be helpful, whether that's reusing existing work or tailoring it more >> exactly to the Beam use case. >> >> [1] https://github.com/damccorm/tag-ur-it >> [2] https://github.com/microsoft/azure-pipelines-tasks/issues/15839 >> >> Thanks, >> Danny >> >> On Mon, Jan 31, 2022 at 12:49 PM Zachary Houfek <zhou...@google.com> >> wrote: >> >>> > You can link PR to the issue by just mentioning #Issue in the commit >>> message. If you do not prefix it with "Closes:" "Fixes:" or similar it will >>> be just linked >>> >>> Ok, thanks for the clarification there. >>> >>> Regards, >>> Zach >>> >>> On Mon, Jan 31, 2022 at 12:43 PM Cristian Constantinescu < >>> zei...@gmail.com> wrote: >>> >>>> I've been semi-following this thread, apologies if this has been raised >>>> already. >>>> >>>> From a user point of view, in some corporate environments (that I've >>>> worked at), Github is blocked. That includes the issues part. The Apache >>>> Jira is not blocked and does at times provide value while investigating >>>> issues. >>>> >>>> Obviously, users stuck in those unfortunate circonstances can just use >>>> their personal device. Not advocating any direction on the matter, just >>>> putting this out there. >>>> >>>> On Mon, Jan 31, 2022 at 12:21 PM Zachary Houfek <zhou...@google.com> >>>> wrote: >>>> >>>>> I added a suggestion that I don't think was discussed here: >>>>> >>>>> I know that we currently can link multiple PRs to a single Jira, but >>>>> GitHub assumes a PR linked to an issue fixes the issue. You also need >>>>> write >>>>> access to the repository to link the PR outside of using a "closing >>>>> keyword". (For reference: Linking a pull request to an issue >>>>> <https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue> >>>>> ) >>>>> >>>>> I'm not sure how much this could sway the decisions but thought it was >>>>> worth bringing up. >>>>> >>>>> Regards, >>>>> Zach >>>>> >>>>> On Mon, Jan 31, 2022 at 12:06 PM Jarek Potiuk <ja...@potiuk.com> >>>>> wrote: >>>>> >>>>>> Just a comment here to clarify the labels from someone who has been >>>>>> using both - ASF (and not only) JIRA and GitHub. >>>>>> >>>>>> The experience from JIRA labels might be awfully misleading. The >>>>>> JIRA labels are a mess in the ASF because they are shared between >>>>>> projects >>>>>> and everyone can create a new label. "Mess" is actually quite an >>>>>> understatement IMHO. >>>>>> >>>>>> The labels in GitHub Issues are "per-project" and they can only be >>>>>> added and modified by maintainers (and only maintainers and "issue >>>>>> triagers" can actually assign them other than the initial assignment when >>>>>> you create an issue. >>>>>> >>>>>> Thanks to that, it is much easier to agree on the >>>>>> common "conventions" to use and avoid creating new ones accidentally. >>>>>> >>>>>> We have quite a success with using the labels in Airflow as we use >>>>>> some of the stuff below: >>>>>> >>>>>> Re - some fancy enforcement/management, yeah. There are good >>>>>> techniques to control how/when the labels are attached: >>>>>> >>>>>> 1) You can create separate templates for Bugs/Features that can have >>>>>> different labels pre-assigned. See here: >>>>>> https://github.com/apache/airflow/tree/main/.github/ISSUE_TEMPLATE - >>>>>> this way you can delegate to the users to make basic "label choice" when >>>>>> they enter issues (though limited - 4-5 types of issues to choose from is >>>>>> really maximum what is reasonable). >>>>>> 2) The same "Issue Templates" already have the option to choose >>>>>> "selectable fields" at entry - you can define free-form entries, >>>>>> drop-down, >>>>>> checkboxes and a few others. This is as close as it can get to "fields". >>>>>> Then (this is something you'd have to code) you could easily write or use >>>>>> an existing GithubAction or bot that will assign the labels based on the >>>>>> initial selection done by the user at entry. We have not done it yet but >>>>>> we >>>>>> might. >>>>>> 3) In PRs you can (and we do that in Airflow) write your bot or use >>>>>> existing GitHub Actions to automatically select the labels based on the >>>>>> "files" that have been changed in the PR: We are doing precisely that in >>>>>> airflow and it works pretty well: >>>>>> https://github.com/apache/airflow/blob/main/.github/boring-cyborg.yml >>>>>> >>>>>> You are in full control, and you can choose the convention and >>>>>> approach for the project. >>>>>> There are literally hundreds of GitHub Actions out there and you can >>>>>> easily write a new one to manage it and you do not need anything but PR >>>>>> merged to the repository to enable and configure those actions. >>>>>> As maintainers, you do not have to create an INFRA JIRA(ehm!) tickets >>>>>> to manage them. You do not have to share anything with other projects. >>>>>> >>>>>> That's my 2 cents :) >>>>>> >>>>>> J. >>>>>> >>>>>> >>>>>> On Mon, Jan 31, 2022 at 5:45 PM Kenneth Knowles <k...@apache.org> >>>>>> wrote: >>>>>> >>>>>>> Maybe controversial: I think some things implemented "via labels" >>>>>>> shouldn't get full credit so I suggested changing them from green to >>>>>>> yellow >>>>>>> :-) >>>>>>> >>>>>>> There's a really big difference between a free-form label and a >>>>>>> field where you know that there is exactly one value and the value is >>>>>>> from >>>>>>> a limited set of options. For example priorities could be missing, >>>>>>> duplicate (both "P1" and "P2") or invented ("P8") unless labels have the >>>>>>> ability to have some fancy enforcement (I haven't looked at this). Same >>>>>>> for >>>>>>> resolution status (is "Not a problem" just a label added as commentary >>>>>>> or >>>>>>> is it a resolution status?) and issue type (something could be marked >>>>>>> "bug" >>>>>>> and "feature request"). >>>>>>> >>>>>>> Kenn >>>>>>> >>>>>>> On Mon, Jan 31, 2022 at 8:38 AM Kenneth Knowles <k...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Great. I added a few items to the "summary of discussion" even >>>>>>>> though they weren't discussed here just to identify things that I care >>>>>>>> about and how you might do them in GitHub Issues. >>>>>>>> >>>>>>>> Kenn >>>>>>>> >>>>>>>> On Sat, Jan 29, 2022 at 6:20 PM Aizhamal Nurmamat kyzy < >>>>>>>> aizha...@apache.org> wrote: >>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> I summarized the discussion in this document[1]. >>>>>>>>> >>>>>>>>> IMO a lot of the concerns raised can be worked around (multiple >>>>>>>>> milestones, components, tags, sub-issues), while the biggest benefit >>>>>>>>> will >>>>>>>>> be decreasing the barrier for new users to contribute and have better >>>>>>>>> discoverability and linkage between code, issues and PRs. >>>>>>>>> >>>>>>>>> Please assign your priority levels for the various features in the >>>>>>>>> comparison table. I left it out because I have a clear bias here : ) >>>>>>>>> >>>>>>>>> Next steps would be to decide whether (1) to move, and (2) to copy >>>>>>>>> over JIRA issues. IMO, Airflow's approach to not copy everything will >>>>>>>>> be >>>>>>>>> the right choice. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit# >>>>>>>>> >>>>>>>>> On Fri, Jan 28, 2022 at 2:30 PM Brian Hulette <bhule...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks for volunteering to pick this up Aizhamal, while I'm >>>>>>>>>> interested in this change happening I don't have the bandwidth to >>>>>>>>>> push it >>>>>>>>>> along. >>>>>>>>>> >>>>>>>>>> I think there was another point where we're missing consensus: >>>>>>>>>> how would we deal with existing jiras. Do we write some automation >>>>>>>>>> to port >>>>>>>>>> everything, or just flip the switch and encourage users/devs to port >>>>>>>>>> active >>>>>>>>>> jiras over to GitHub? >>>>>>>>>> >>>>>>>>>> Manual porting pros: >>>>>>>>>> - Ambiguous situations get human attention. >>>>>>>>>> - Tickets with no interested parties will be implicitly cleared >>>>>>>>>> out of the backlog. >>>>>>>>>> - No need to write automation for porting tools. >>>>>>>>>> Manual porting cons: >>>>>>>>>> - Unambiguous situations get (unnecessary) human attention. >>>>>>>>>> >>>>>>>>>> A compromise might be to build a simple tool for porting jiras, >>>>>>>>>> but don't automatically run it on everything. >>>>>>>>>> >>>>>>>>>> On Tue, Jan 18, 2022 at 6:04 AM Kenneth Knowles <k...@apache.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I also think that we are at the point where a document >>>>>>>>>>> describing them side-by-side is needed. I would very much like to >>>>>>>>>>> help. I >>>>>>>>>>> strongly support moving to GitHub Issues. >>>>>>>>>>> >>>>>>>>>>> I'm less concerned about pros/cons (I think the one big pro of >>>>>>>>>>> "everyone knows it and already has an account" outweighs almost any >>>>>>>>>>> con) >>>>>>>>>>> but I want to build a very clear plan of how we will map Jira >>>>>>>>>>> features to >>>>>>>>>>> GitHub features. I use quite a lot of Jira's features. In >>>>>>>>>>> particular, a lot >>>>>>>>>>> of things seem like they'll become conventions around labels, which >>>>>>>>>>> I >>>>>>>>>>> expect to often be low enough data quality that we would just not >>>>>>>>>>> bother, unless we can control it a bit. >>>>>>>>>>> >>>>>>>>>>> I eagerly await the link! Feel free to share very early :-) >>>>>>>>>>> >>>>>>>>>>> Kenn >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 13, 2022 at 1:48 PM Aizhamal Nurmamat kyzy < >>>>>>>>>>> aizha...@apache.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> I think I am enthusiastic enough to help with the doc :) will >>>>>>>>>>>> share the link soon. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jan 13, 2022 at 10:12 AM Robert Bradshaw < >>>>>>>>>>>> rober...@google.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I don't know if we have consensus, but it seems that some >>>>>>>>>>>>> people are >>>>>>>>>>>>> quite supportive (myself included), and some are ambivalent. >>>>>>>>>>>>> The only >>>>>>>>>>>>> major con I can see is that github doesn't support tagging an >>>>>>>>>>>>> issue to >>>>>>>>>>>>> multiple milestones (but it's unclear how important that is). >>>>>>>>>>>>> >>>>>>>>>>>>> I would suggest that someone enthusiastic about this proposal >>>>>>>>>>>>> put >>>>>>>>>>>>> together a doc where we can enumerate the pros and cons and >>>>>>>>>>>>> once the >>>>>>>>>>>>> list seems complete we can bring it back to the list for >>>>>>>>>>>>> further >>>>>>>>>>>>> discussion and/or a vote (if needed, likely not). >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jan 13, 2022 at 9:27 AM Alexey Romanenko >>>>>>>>>>>>> <aromanenko....@gmail.com> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > I’m not sure that we have a consensus on this. Since this >>>>>>>>>>>>> thread initially was started to discuss and gather some feedback >>>>>>>>>>>>> then I >>>>>>>>>>>>> think it would be great to have a summary with pros and cons of >>>>>>>>>>>>> this >>>>>>>>>>>>> migration. >>>>>>>>>>>>> > >>>>>>>>>>>>> > — >>>>>>>>>>>>> > Alexey >>>>>>>>>>>>> > >>>>>>>>>>>>> > On 13 Jan 2022, at 00:11, Aizhamal Nurmamat kyzy < >>>>>>>>>>>>> aizha...@apache.org> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi all, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Is there a consensus to migrate to GitHub? >>>>>>>>>>>>> > >>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette < >>>>>>>>>>>>> bhule...@google.com> wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles < >>>>>>>>>>>>> k...@google.com> wrote: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre < >>>>>>>>>>>>> j...@nanthrax.net> wrote: >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Hi, >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> No problem for me. The only thing I don’t like with >>>>>>>>>>>>> GitHub issues is that fact that it’s not possible to “assign” >>>>>>>>>>>>> several >>>>>>>>>>>>> milestones to an issue. >>>>>>>>>>>>> >>>> When we maintain several active branch/version, it sucks >>>>>>>>>>>>> (one issue == one milestone), as we have to create several issue. >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> This is a good point to consider. In Beam we often create >>>>>>>>>>>>> multiple issues anyhow when we intend to backport/cherrypick a >>>>>>>>>>>>> fix. One >>>>>>>>>>>>> issue for the original fix and one each targeted cherrypick. This >>>>>>>>>>>>> way their >>>>>>>>>>>>> resolution status can be tracked separately. But it is nice for >>>>>>>>>>>>> users to be >>>>>>>>>>>>> able to go back and edit the original bug report to say which >>>>>>>>>>>>> versions are >>>>>>>>>>>>> affected and which are not. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I looked into this a little bit. It looks like milestones >>>>>>>>>>>>> don't have to represent a release (e.g. they could represent some >>>>>>>>>>>>> abstract >>>>>>>>>>>>> goal), but they are often associated with releases. This seems >>>>>>>>>>>>> like a >>>>>>>>>>>>> reasonable field to map to "Fix Version/s" in jira, but jira does >>>>>>>>>>>>> support >>>>>>>>>>>>> specifying multiple releases. So one issue == one milestone would >>>>>>>>>>>>> be a >>>>>>>>>>>>> regression. >>>>>>>>>>>>> >> As Kenn pointed out though we often create a separate jira >>>>>>>>>>>>> to track backports anyway (even though we could just specify >>>>>>>>>>>>> multiple fix >>>>>>>>>>>>> versions), so I'm not sure this is a significant blocker. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> If we want to use milestones to track abstract goals, I >>>>>>>>>>>>> think we'd be out of luck. We could just use labels, but the >>>>>>>>>>>>> GitHub UI >>>>>>>>>>>>> doesn't present a nice burndown chart for those. See >>>>>>>>>>>>> https://github.com/pandas-dev/pandas/milestones vs. >>>>>>>>>>>>> https://github.com/pandas-dev/pandas/labels. FWIW jira >>>>>>>>>>>>> doesn't have great functionality here either. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Kenn >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> Regards >>>>>>>>>>>>> >>>> JB >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>> > Le 10 déc. 2021 à 01:28, Kyle Weaver < >>>>>>>>>>>>> kcwea...@google.com> a écrit : >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > I’m in favor of switching to Github issues. I can’t >>>>>>>>>>>>> think of a single thing jira does better. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > Thanks Jarek, this is a really great resource [1]. For >>>>>>>>>>>>> another reference, the Calcite project is engaged in the same >>>>>>>>>>>>> discussion >>>>>>>>>>>>> right now [2]. I came up with many of the same points >>>>>>>>>>>>> independently before >>>>>>>>>>>>> I saw their thread. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > When evaluating feature parity, we should make a >>>>>>>>>>>>> distinction between non-structured (text) and structured data. >>>>>>>>>>>>> And we don’t >>>>>>>>>>>>> need a strict mechanical mapping for everything unless we’re >>>>>>>>>>>>> planning on >>>>>>>>>>>>> automatically migrating all existing issues. I don’t see the >>>>>>>>>>>>> point in >>>>>>>>>>>>> automatic migration, though; as Jarek pointed out, we’d end up >>>>>>>>>>>>> perpetuating >>>>>>>>>>>>> a ton of obsolete issues. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > • We use nested issues and issue relations in >>>>>>>>>>>>> jira, but as far as I know robots don’t use them and we don’t >>>>>>>>>>>>> query them >>>>>>>>>>>>> much, so we’re not losing anything by moving from an API to plain >>>>>>>>>>>>> English >>>>>>>>>>>>> descriptions: “This issue is blocked by issue #n.” Mentions show >>>>>>>>>>>>> up >>>>>>>>>>>>> automatically on other issues. >>>>>>>>>>>>> >>>> > • For component, type, priority, etc., we can use >>>>>>>>>>>>> Github labels. >>>>>>>>>>>>> >>>> > • Version(s) affected is used inconsistently, and >>>>>>>>>>>>> as far as I know only by humans, so a simple English description >>>>>>>>>>>>> is fine. >>>>>>>>>>>>> We can follow the example of other projects and make the version >>>>>>>>>>>>> affected a >>>>>>>>>>>>> part of the issue template. >>>>>>>>>>>>> >>>> > • For fix version, which we use to track which >>>>>>>>>>>>> issues we want to fix in upcoming releases, as well as >>>>>>>>>>>>> automatically >>>>>>>>>>>>> generate release notes: Github has “milestones,” which can be >>>>>>>>>>>>> marked on PRs >>>>>>>>>>>>> or issues, or both. >>>>>>>>>>>>> >>>> > • IMO the automatically generated JIRA >>>>>>>>>>>>> release notes are not especially useful anyway. They are too >>>>>>>>>>>>> detailed for a >>>>>>>>>>>>> quick summary, and not precise enough to show everything. For a >>>>>>>>>>>>> readable >>>>>>>>>>>>> summary, we use CHANGES.md to highlight changes we especially >>>>>>>>>>>>> want users to >>>>>>>>>>>>> know about. For a complete list of changes, there’s the git >>>>>>>>>>>>> commit log, >>>>>>>>>>>>> which is the ultimate source of truth. >>>>>>>>>>>>> >>>> > • We’d only want to preserve reporter and >>>>>>>>>>>>> assignee if we’re planning on migrating everything automatically, >>>>>>>>>>>>> and even >>>>>>>>>>>>> then I think it’d be fine to compile a map of active contributors >>>>>>>>>>>>> and drop >>>>>>>>>>>>> the rest. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > As for the advantages of switching (just the ones off >>>>>>>>>>>>> the top of my head): >>>>>>>>>>>>> >>>> > • As others have mentioned, it’s less burden for >>>>>>>>>>>>> new contributors to create new issues and comment on existing >>>>>>>>>>>>> ones. >>>>>>>>>>>>> >>>> > • Effortless linking between issues and PRs. >>>>>>>>>>>>> >>>> > • Github -> jira links were working for a >>>>>>>>>>>>> short while, but they seem to be broken at the moment. >>>>>>>>>>>>> >>>> > • Jira -> github links only show: “links >>>>>>>>>>>>> to GitHub Pull Request #xxxxx”. They don’t say the status of the >>>>>>>>>>>>> PR, so you >>>>>>>>>>>>> have to follow the link to find out. Especially inconvenient when >>>>>>>>>>>>> one jira >>>>>>>>>>>>> maps to several PRs, and you have to open all the links to get a >>>>>>>>>>>>> summary of >>>>>>>>>>>>> what work was done. >>>>>>>>>>>>> >>>> > • When you mention a GH issue in a pull >>>>>>>>>>>>> request, a link to the PR will automatically appear on the issue, >>>>>>>>>>>>> including >>>>>>>>>>>>> not just the ID but also the PR’s description and status >>>>>>>>>>>>> (open/closed/draft/merged/etc.), and if you hover it will show a >>>>>>>>>>>>> preview as >>>>>>>>>>>>> well. >>>>>>>>>>>>> >>>> > • We frequently merge a PR and then >>>>>>>>>>>>> forget to mark the jira as closed. Whereas if a PR is linked to a >>>>>>>>>>>>> GH issue >>>>>>>>>>>>> using the “closes” keyword, the GH issue will automatically be >>>>>>>>>>>>> closed [3]. >>>>>>>>>>>>> >>>> > • I don’t have to look up or guess whether a >>>>>>>>>>>>> github account and jira account belong to the same person. >>>>>>>>>>>>> >>>> > • There’s a single unified search bar to find >>>>>>>>>>>>> issues, PRs, and code. >>>>>>>>>>>>> >>>> > • Github enables markdown formatting everywhere, >>>>>>>>>>>>> which is more or less the industry standard, whereas Jira has its >>>>>>>>>>>>> own >>>>>>>>>>>>> bespoke system [4]. >>>>>>>>>>>>> >>>> > • In GH issues, links to Github code snippets >>>>>>>>>>>>> will automatically display the code snippet inline. >>>>>>>>>>>>> >>>> > • GH labels are scoped to each project, whereas >>>>>>>>>>>>> ASF Jira labels are an unmanageable, infinitely growing namespace >>>>>>>>>>>>> (see >>>>>>>>>>>>> “flake,” “flaky,” “flakey,” “Flaky,” “flaky-test”...). >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > [1] >>>>>>>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 >>>>>>>>>>>>> >>>> > [2] >>>>>>>>>>>>> https://mail-archives.apache.org/mod_mbox/calcite-dev/202112.mbox/%3CCAB%3DJe-EuaijDjwb6umU_N2TaqFZawE%2BUbgZAgZYvrgPFypfAYQ%40mail.gmail.com%3E >>>>>>>>>>>>> >>>> > [3] >>>>>>>>>>>>> https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword >>>>>>>>>>>>> >>>> > [4] >>>>>>>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > On Wed, Dec 8, 2021 at 9:13 AM Alexey Romanenko < >>>>>>>>>>>>> aromanenko....@gmail.com> wrote: >>>>>>>>>>>>> >>>> > Many thanks for details, Jarek! >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > Actually, your experience proves that the full data >>>>>>>>>>>>> transfer is very expensive (if even possible) and not necessary, >>>>>>>>>>>>> especially >>>>>>>>>>>>> taking the fact that the number of Beam Jira issues is a couple >>>>>>>>>>>>> of orders >>>>>>>>>>>>> more than Airflow one. So, very likely that we will end up by >>>>>>>>>>>>> living with >>>>>>>>>>>>> two issue trackers, at least for some time, to avoid issue >>>>>>>>>>>>> duplications and >>>>>>>>>>>>> have an access to old ones. This can be very confusing. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > In the same time, except the argument of “one tool for >>>>>>>>>>>>> everything”, which is quite strong for sure, I don’t see any other >>>>>>>>>>>>> advantages of GH issues over Jira issues. Also, the more >>>>>>>>>>>>> important is not >>>>>>>>>>>>> to lose what we have for now, as Jan mentioned below. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > So, my vote for now is -0 since it has significant pros >>>>>>>>>>>>> and cons and the final impact is not evident. >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > — >>>>>>>>>>>>> >>>> > Alexey >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> > > On 8 Dec 2021, at 01:38, Jarek Potiuk < >>>>>>>>>>>>> ja...@potiuk.com> wrote: >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > >> Do I understand correctly that this transition (if >>>>>>>>>>>>> it will happen) includes the transfer of all Beam Jira archive to >>>>>>>>>>>>> GitHub >>>>>>>>>>>>> issues with a proper statuses/comments/refs/etc? If not, what are >>>>>>>>>>>>> the >>>>>>>>>>>>> options? >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > Suggestion from the experience of Airflow again - you >>>>>>>>>>>>> can look it up >>>>>>>>>>>>> >>>> > > in our notes. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > We've tried it initially to copy the issues manually >>>>>>>>>>>>> or in bulk, but >>>>>>>>>>>>> >>>> > > eventually we decided to tap into the wisdom and >>>>>>>>>>>>> cooperation of our >>>>>>>>>>>>> >>>> > > community. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > We migrated some (not many) important things only and >>>>>>>>>>>>> asked our users >>>>>>>>>>>>> >>>> > > to move the important issues if they think they are >>>>>>>>>>>>> still >>>>>>>>>>>>> >>>> > > relevant/important to them. We closed the JIRA for >>>>>>>>>>>>> entry and left the >>>>>>>>>>>>> >>>> > > issues in JIRA in read-only state so that we could >>>>>>>>>>>>> always refer to >>>>>>>>>>>>> >>>> > > them if needed. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > So rather than proactively copy the issues, we asked >>>>>>>>>>>>> the users to make >>>>>>>>>>>>> >>>> > > the decision which issues are important to them and >>>>>>>>>>>>> proactively move >>>>>>>>>>>>> >>>> > > it and we left an option of reactive moving if >>>>>>>>>>>>> someone came back to >>>>>>>>>>>>> >>>> > > the issue later. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > That turned out to be a smart decision considering >>>>>>>>>>>>> the effort it would >>>>>>>>>>>>> >>>> > > require to smartly move the issues vs. the results >>>>>>>>>>>>> achieved. And >>>>>>>>>>>>> >>>> > > helped us to clean some "stale/useless/not important" >>>>>>>>>>>>> issues. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > We've had 1719 open JIRA issues when we migrated. >>>>>>>>>>>>> Over the course of >>>>>>>>>>>>> >>>> > > ~1.5 years (since about April 2020) we've had ~140 >>>>>>>>>>>>> issues that refer >>>>>>>>>>>>> >>>> > > to any of the JIRA issues >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> https://github.com/apache/airflow/issues?q=is%3Aissue+is%3Aclosed+%22https%3A%2F%2Fissues.apache.org%2Fjira%22+ >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>> > > Currently we have > 4500 GH issues (3700 closed, 800 >>>>>>>>>>>>> opened). >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > This means that roughly speaking only < 10% of >>>>>>>>>>>>> original open JIRA >>>>>>>>>>>>> >>>> > > issues were actually somewhat valuable (roughly >>>>>>>>>>>>> speaking of course) >>>>>>>>>>>>> >>>> > > and they were < 5% of today's numbers. Of course some >>>>>>>>>>>>> of the new GH >>>>>>>>>>>>> >>>> > > issues duplicated those JIRA ones. But not many I >>>>>>>>>>>>> think, especially >>>>>>>>>>>>> >>>> > > that those issues in JIRA referred mostly to older >>>>>>>>>>>>> Airflow versions. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > One more comment for the migration - I STRONGLY >>>>>>>>>>>>> recommend using well >>>>>>>>>>>>> >>>> > > designed templates for GH issues from day one. That >>>>>>>>>>>>> significantly >>>>>>>>>>>>> >>>> > > improves the quality of issues - and using >>>>>>>>>>>>> Discussions as the place >>>>>>>>>>>>> >>>> > > where you move unclear/not reproducible issues (and >>>>>>>>>>>>> for example >>>>>>>>>>>>> >>>> > > guiding users to use discussions if they have no >>>>>>>>>>>>> clearly reproducible >>>>>>>>>>>>> >>>> > > case). This significantly reduces the "bad issue >>>>>>>>>>>>> overload" (see also >>>>>>>>>>>>> >>>> > > more detailed comments in >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 >>>>>>>>>>>>> ). >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > I personally think a well designed issue entry >>>>>>>>>>>>> process for new issues >>>>>>>>>>>>> >>>> > > is more important than migrating old issues in bulk. >>>>>>>>>>>>> Especially if you >>>>>>>>>>>>> >>>> > > will ask users to help - as they will have to make a >>>>>>>>>>>>> structured entry >>>>>>>>>>>>> >>>> > > with potentially more detailed >>>>>>>>>>>>> information/reproducibility) or they >>>>>>>>>>>>> >>>> > > will decide themselves that opening a github >>>>>>>>>>>>> discussion is better than >>>>>>>>>>>>> >>>> > > opening an issue if they do not have a reproducible >>>>>>>>>>>>> case. Or they will >>>>>>>>>>>>> >>>> > > give up if too much information is needed (but this >>>>>>>>>>>>> means that their >>>>>>>>>>>>> >>>> > > issue is essentially not that important IMHO). >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > But this is just friendly advice from the experience >>>>>>>>>>>>> of those who did >>>>>>>>>>>>> >>>> > > it quite some time ago :) >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > J. >>>>>>>>>>>>> >>>> > > >>>>>>>>>>>>> >>>> > > On Wed, Dec 8, 2021 at 1:08 AM Brian Hulette < >>>>>>>>>>>>> bhule...@google.com> wrote: >>>>>>>>>>>>> >>>> > >> >>>>>>>>>>>>> >>>> > >> At this point I just wanted to see if the community >>>>>>>>>>>>> is interested in such a change or if there are any hard blockers. >>>>>>>>>>>>> If we do >>>>>>>>>>>>> go down this path I think we should port jiras over to GH Issues. >>>>>>>>>>>>> You're >>>>>>>>>>>>> right this isn't trivial, there's no ready-made solution we can >>>>>>>>>>>>> use, we'd >>>>>>>>>>>>> need to decide on a mapping for everything and write a tool to do >>>>>>>>>>>>> the >>>>>>>>>>>>> migration. It sounds like there may be other work in this area we >>>>>>>>>>>>> can build >>>>>>>>>>>>> on (e.g. Airflow may have made a tool we can work from?). >>>>>>>>>>>>> >>>> > >> >>>>>>>>>>>>> >>>> > >> I honestly don't have much experience with GH Issues >>>>>>>>>>>>> so I can't provide concrete examples of better usability (maybe >>>>>>>>>>>>> Jarek >>>>>>>>>>>>> can?). From my perspective: >>>>>>>>>>>>> >>>> > >> - I hear a lot of grumbling about jira, and a lot of >>>>>>>>>>>>> praise for GitHub Issues. >>>>>>>>>>>>> >>>> > >> - Most new users/contributors already have a GitHub >>>>>>>>>>>>> account, and very few already have an ASF account. It sounds >>>>>>>>>>>>> silly, but I'm >>>>>>>>>>>>> sure this is a barrier for engaging with the community. Filing an >>>>>>>>>>>>> issue, or >>>>>>>>>>>>> commenting on one to provide additional context, or asking a >>>>>>>>>>>>> clarifying >>>>>>>>>>>>> question about a starter task should be very quick and easy - I >>>>>>>>>>>>> bet a lot >>>>>>>>>>>>> of these interactions are blocked at the jira registration page. >>>>>>>>>>>>> >>>> > >> >>>>>>>>>>>>> >>>> > >> Brian >>>>>>>>>>>>> >>>> > >> >>>>>>>>>>>>> >>>> > >> On Tue, Dec 7, 2021 at 9:04 AM Alexey Romanenko < >>>>>>>>>>>>> aromanenko....@gmail.com> wrote: >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> Do I understand correctly that this transition (if >>>>>>>>>>>>> it will happen) includes the transfer of all Beam Jira archive to >>>>>>>>>>>>> GitHub >>>>>>>>>>>>> issues with a proper statuses/comments/refs/etc? If not, what are >>>>>>>>>>>>> the >>>>>>>>>>>>> options? >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> Since this transfer looks quite complicated at the >>>>>>>>>>>>> first glance, what are the real key advantages (some concrete >>>>>>>>>>>>> examples are >>>>>>>>>>>>> very appreciated) to initiate this process and what are the >>>>>>>>>>>>> show-stoppers >>>>>>>>>>>>> for us with a current Jira workflow? >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> — >>>>>>>>>>>>> >>>> > >>> Alexey >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> On 6 Dec 2021, at 19:48, Udi Meiri < >>>>>>>>>>>>> eh...@google.com> wrote: >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> +1 on migrating to GH issues. >>>>>>>>>>>>> >>>> > >>> We will need to update our release process. >>>>>>>>>>>>> Hopefully it'll make it simpler. >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> On Sat, Dec 4, 2021 at 2:35 AM Jarek Potiuk < >>>>>>>>>>>>> ja...@potiuk.com> wrote: >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> Just to add a comment on those requirements >>>>>>>>>>>>> Kenneth, looking into the >>>>>>>>>>>>> >>>> > >>>> near future. >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> Soon GitHub issues will open for GA a whole new >>>>>>>>>>>>> way of interacting >>>>>>>>>>>>> >>>> > >>>> with the issues (without removing the current way) >>>>>>>>>>>>> which will greatly >>>>>>>>>>>>> >>>> > >>>> improve iI think all aspects of what You >>>>>>>>>>>>> mentioned). The issues (and >>>>>>>>>>>>> >>>> > >>>> associated projects) will gain new capabilities: >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> * structured metadata that you will be able to >>>>>>>>>>>>> define (much better >>>>>>>>>>>>> >>>> > >>>> than unstructured labels) >>>>>>>>>>>>> >>>> > >>>> * table-like visualisations which will allow for >>>>>>>>>>>>> fast, bulk, >>>>>>>>>>>>> >>>> > >>>> keyboard-driven management >>>>>>>>>>>>> >>>> > >>>> * better automation of workflows >>>>>>>>>>>>> >>>> > >>>> * complete APIs to manage the issues (good for >>>>>>>>>>>>> GitHub Actions >>>>>>>>>>>>> >>>> > >>>> integration for example) >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> Re: assigning by non-committers is one of the >>>>>>>>>>>>> things that won't work >>>>>>>>>>>>> >>>> > >>>> currently. Only comitters can assign the issues, >>>>>>>>>>>>> and only if a user >>>>>>>>>>>>> >>>> > >>>> commented on the issue. But it nicely works - when >>>>>>>>>>>>> a user comments "I >>>>>>>>>>>>> >>>> > >>>> want to work on that issue", a committer assigns >>>>>>>>>>>>> the user. And It >>>>>>>>>>>>> >>>> > >>>> could be easily automated as well. >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> You can see what it will is about here: >>>>>>>>>>>>> https://github.com/features/issues >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> They are currently at the "Public Beta" and >>>>>>>>>>>>> heading towards General >>>>>>>>>>>>> >>>> > >>>> Availability, but it is not available to "open" >>>>>>>>>>>>> projects yet. However >>>>>>>>>>>>> >>>> > >>>> I have a promise from the GitHub Product manager >>>>>>>>>>>>> (my friend heads the >>>>>>>>>>>>> >>>> > >>>> team implementing it) that ASF will be the first >>>>>>>>>>>>> on the list when the >>>>>>>>>>>>> >>>> > >>>> public projects will be enabled, because it looks >>>>>>>>>>>>> like it will make >>>>>>>>>>>>> >>>> > >>>> our triaging and organisation much better. >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> J. >>>>>>>>>>>>> >>>> > >>>> >>>>>>>>>>>>> >>>> > >>>> On Sat, Dec 4, 2021 at 1:46 AM Kenneth Knowles < >>>>>>>>>>>>> k...@apache.org> wrote: >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> This sounds really good to me. Much more familiar >>>>>>>>>>>>> to newcomers. I think we end up doing a lot more ad hoc stuff >>>>>>>>>>>>> with labels, >>>>>>>>>>>>> yes? Probably worth having a specific plan. Things I care about: >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> - priorities with documented meaning >>>>>>>>>>>>> >>>> > >>>>> - targeting issues to future releases >>>>>>>>>>>>> >>>> > >>>>> - basic visualizations (mainly total vs open >>>>>>>>>>>>> issues over time) >>>>>>>>>>>>> >>>> > >>>>> - tags / components >>>>>>>>>>>>> >>>> > >>>>> - editing/assigning by non-committers >>>>>>>>>>>>> >>>> > >>>>> - workflow supporting "needs triage" (default) -> >>>>>>>>>>>>> open -> resolved >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> I think a lot of the above is done via ad hoc >>>>>>>>>>>>> labels but I'm not sure if there are other fancy ways to do it. >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> Anyhow we should switch even if there is a >>>>>>>>>>>>> feature gap for the sake of community. >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> Kenn >>>>>>>>>>>>> >>>> > >>>>> >>>>>>>>>>>>> >>>> > >>>>> On Fri, Dec 3, 2021 at 3:06 PM David Huntsperger < >>>>>>>>>>>>> dhuntsper...@google.com> wrote: >>>>>>>>>>>>> >>>> > >>>>>> >>>>>>>>>>>>> >>>> > >>>>>> Yes, please. I can help clean up the website >>>>>>>>>>>>> issues as part of a migration. >>>>>>>>>>>>> >>>> > >>>>>> >>>>>>>>>>>>> >>>> > >>>>>> On Fri, Dec 3, 2021 at 1:46 PM Robert Burke < >>>>>>>>>>>>> rob...@frantil.com> wrote: >>>>>>>>>>>>> >>>> > >>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>> Similar thing happened for Go migrating to use >>>>>>>>>>>>> GH issues for everything from Language Feature proposals to bugs. >>>>>>>>>>>>> Much >>>>>>>>>>>>> easier than the very gerrit driven process it was before, and User >>>>>>>>>>>>> Discussions are far more discoverable by users: they usually >>>>>>>>>>>>> already have a >>>>>>>>>>>>> GH account, and don't need to create a new separate one. >>>>>>>>>>>>> >>>> > >>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>> GitHub does seem to permit user directed >>>>>>>>>>>>> templates for issues so we can simplify issue triage by users: Eg >>>>>>>>>>>>> for Go >>>>>>>>>>>>> there are a number of requests one can make: >>>>>>>>>>>>> https://github.com/golang/go/issues/new/choose >>>>>>>>>>>>> >>>> > >>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>> On Fri, Dec 3, 2021, 12:17 PM Andy Ye < >>>>>>>>>>>>> yea...@google.com> wrote: >>>>>>>>>>>>> >>>> > >>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>> Chiming in from the perspective of a new Beam >>>>>>>>>>>>> contributor. +1 on Github issues. I feel like it would be easier >>>>>>>>>>>>> to learn >>>>>>>>>>>>> about and contribute to existing issues/bugs if it were tracked >>>>>>>>>>>>> in the same >>>>>>>>>>>>> place as that of the source code, rather than bouncing back and >>>>>>>>>>>>> forth >>>>>>>>>>>>> between the two different sites. >>>>>>>>>>>>> >>>> > >>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>> On Fri, Dec 3, 2021 at 1:18 PM Jarek Potiuk < >>>>>>>>>>>>> ja...@potiuk.com> wrote: >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> Comment from a friendly outsider. >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> TL; DR; Yes. Do migrate. Highly recommended. >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> There were already similar discussions >>>>>>>>>>>>> happening recently (community >>>>>>>>>>>>> >>>> > >>>>>>>>> and infra mailing lists) and as a result I >>>>>>>>>>>>> captured Airflow's >>>>>>>>>>>>> >>>> > >>>>>>>>> experiences and recommendations in the BUILD >>>>>>>>>>>>> wiki. You might find some >>>>>>>>>>>>> >>>> > >>>>>>>>> hints and suggestions to follow as well as >>>>>>>>>>>>> our experiences at Airflow: >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> J, >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>> On Fri, Dec 3, 2021 at 7:46 PM Brian Hulette < >>>>>>>>>>>>> bhule...@google.com> wrote: >>>>>>>>>>>>> >>>> > >>>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>> > >>>>>>>>>> I wanted to start a discussion to gauge >>>>>>>>>>>>> interest on moving our issue tracking from the ASF Jira to GitHub >>>>>>>>>>>>> Issues. >>>>>>>>>>>>> >>>> > >>>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>>> Pros: >>>>>>>>>>>>> >>>> > >>>>>>>>>> + GH Issues is more discoverable and >>>>>>>>>>>>> approachable for new users and contributors. >>>>>>>>>>>>> >>>> > >>>>>>>>>> + For contributors at Google: we have >>>>>>>>>>>>> tooling to integrate GH Issues with internal issue tracking, >>>>>>>>>>>>> which would >>>>>>>>>>>>> help us be more accountable (Full disclosure: this is the reason >>>>>>>>>>>>> I started >>>>>>>>>>>>> thinking about this). >>>>>>>>>>>>> >>>> > >>>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>>> Cons: >>>>>>>>>>>>> >>>> > >>>>>>>>>> - GH Issues can't be linked to jiras for >>>>>>>>>>>>> other ASF projects (I don't think we do this often in jira >>>>>>>>>>>>> anyway). >>>>>>>>>>>>> >>>> > >>>>>>>>>> - We would likely need to do a one-time >>>>>>>>>>>>> migration of jiras to GH Issues, and update any processes or >>>>>>>>>>>>> automation >>>>>>>>>>>>> built on jira (e.g. release notes). >>>>>>>>>>>>> >>>> > >>>>>>>>>> - Anything else? >>>>>>>>>>>>> >>>> > >>>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>>> I've always thought that using ASF Jira was >>>>>>>>>>>>> a hard requirement for Apache projects, but that is not the case. >>>>>>>>>>>>> Other >>>>>>>>>>>>> Apache projects are using GitHub Issues today, for example the >>>>>>>>>>>>> Arrow >>>>>>>>>>>>> DataFusion sub-project uses GitHub issues now [1,2] and Airflow >>>>>>>>>>>>> migrated >>>>>>>>>>>>> from jira [3] to GitHub issues [4]. >>>>>>>>>>>>> >>>> > >>>>>>>>>> >>>>>>>>>>>>> >>>> > >>>>>>>>>> [1] >>>>>>>>>>>>> https://lists.apache.org/thread/w3dr1vlt9115r3x9m7bprmo4zpnog483 >>>>>>>>>>>>> >>>> > >>>>>>>>>> [2] >>>>>>>>>>>>> https://github.com/apache/arrow-datafusion/issues >>>>>>>>>>>>> >>>> > >>>>>>>>>> [3] >>>>>>>>>>>>> https://issues.apache.org/jira/projects/AIRFLOW/issues >>>>>>>>>>>>> >>>> > >>>>>>>>>> [4] https://github.com/apache/airflow/issues >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>> >>>>>>>>>>>>> >>>> > >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>>>> -- >>>>> >>>>> Zachary Houfek >>>>> >>>>> Software Engineer >>>>> >>>>> DataPLS PLAT >>>>> >>>>> zhou...@google.com >>>>> >>>> >>> >>> -- >>> >>> Zachary Houfek >>> >>> Software Engineer >>> >>> DataPLS PLAT >>> >>> zhou...@google.com >>> >>
