Awesome, thanks for the feedback everyone. Then I will go ahead, and start documenting the plan in detail and share it here afterwards.
On Tue, Feb 15, 2022 at 3:17 PM Alexey Romanenko <aromanenko....@gmail.com> wrote: > First of all, many thanks for putting the details into this design doc and > sorry for delay with my response. > > I’m still quite neutral with this migration because of several concerns: > > - Imho, Github Issues is still not well enough mature as an issue tracker > and it doesn’t provide the solutions for all needs as, for example, Jira > and other tracker do (though, seems that there are many features upcoming). > For example, many things in GH Issues still can be resolved only with > “labels" and we can potentially end up with a huge bunch of them with a > different naming policy, mixed purposes and so on. > > - If we won’t do a transfer of the issues/users/filters/etc from Jira to > GH Issues then, it looks, that we will live with two trackers for some > (unknown) amount of time which is not very convenient (I believe that we > need to specify our workflows with having this). > > - If we do a transfer then what kind of tools are going to be used, how > much time it will take - so, we’d need a detailed plan on this. > > On the other positive hand, for sure, GH Issues has, by design, a solid > integration with other Github services which is, obviously, a huge > advantage for the long term as well. > > In any case, adding (or substitute) a new tool should help us to make the > development process, in general, easier and faster. So I hope we can > achieve this with Github Issues. > > — > Alexey > > On 15 Feb 2022, at 06:52, Aizhamal Nurmamat kyzy <aizha...@apache.org> > wrote: > > Very humbly, I think the benefits of moving to GitHub Issues outweigh the > shortcomings. > > Jan, Kenn, Alexey, JB: adding you directly as you had some concerns. > Please, let us know if they were addressed by the options that we described > in the doc [1]? > > If noone objects, I can start working with some of you on Migration TODOs > outlined in the doc I am referencing. > > > [1] > https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#bookmark=id.izn35w5gsjft > > On Thu, Feb 10, 2022 at 1:12 PM Danny McCormick <dannymccorm...@google.com> > wrote: > >> I'm definitely +1 on moving to help make the bar for entry lower for new >> contributors (like myself!) >> >> Thanks, >> Danny >> >> On Thu, Feb 10, 2022 at 2:32 PM Aizhamal Nurmamat kyzy < >> aizha...@apache.org> wrote: >> >>> 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 >>>>>> >>>>> >
