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 >> >
