Thank you for putting this together, Danny! I can help with the label creation task.
Anyone else want to help? On Thu, Mar 17, 2022 at 11:55 AM Danny McCormick <dannymccorm...@google.com> wrote: > Here's a spreadsheet to sign up if you'd like to help with the migration! > https://docs.google.com/spreadsheets/d/1hqztI7ECf8NjcmfQ8ZfUj6OU0U-6orJzhG6OMufmTFE/edit?usp=sharing > > Thanks, > Danny > > On Thu, Mar 17, 2022 at 1:59 PM Danny McCormick <dannymccorm...@google.com> > wrote: > >> Hey everyone, >> >> Aizhamal is currently out for a little bit and asked me to start to put >> together a more detailed plan for migrating from Jira to GitHub since we >> seem to have consensus here (or close to it). Here's my proposal on a plan >> to migrate - >> https://docs.google.com/document/d/1powrXGbjMLMYl9ibRzMda5o5HM_p44XvBy5MZu75Q5E/edit?usp=sharing >> - I'd really appreciate any feedback or recommendations you have! In >> particular, I imagine people will have thoughts on the plan to migrate >> Jiras to Issues - I included that as a section and think its worth it, but >> others may disagree (or disagree on the fields we care about keeping). >> >> If anyone is interested in helping with the migration itself, please >> chime in as well! We will almost certainly need PMC help for some of the >> settings level work, but there's also a decent bit of parallelizable work >> available to update templates/documentation, update automation, and help >> build/design the issue migrator! >> >> Thanks, >> Danny >> >> On Thu, Feb 17, 2022 at 5:28 PM Sachin Agarwal <sachi...@google.com> >> wrote: >> >>> Thank you! I believe the benefits to make it easier for folks to >>> contribute to Beam will pay significant dividends quickly. >>> >>> On Thu, Feb 17, 2022 at 2:09 PM Aizhamal Nurmamat kyzy < >>> aizha...@apache.org> wrote: >>> >>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>
