You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Brian Hulette <bh...@google.com> on 2021/12/03 18:45:56 UTC
[DISCUSS] Migrate Jira to GitHub Issues?
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
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Sam Rohde <sr...@google.com>.
+1 for moving to GH
On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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.
>
> Regards
> JB
>
> > Le 10 déc. 2021 à 01:28, Kyle Weaver <kc...@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.dev@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 <bh...@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.dev@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 <ke...@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 <
> dhuntsperger@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 <ro...@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 <ye...@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 <
> bhulette@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
> > >>>
> > >>>
> >
>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <ke...@apache.org>.
I'm +1 on going for it, for sure. My comments are just about having a plan
for the details.
Kenn
On Tue, Feb 15, 2022 at 4:55 AM Jan Lukavský <je...@seznam.cz> wrote:
> Hi,
>
> +1 from my side as well, thanks for the summary. I suppose the migration
> plan is going to be clarified. I think it would be nice to preserve the
> assignee and reporter, but that can be probably resolved at later stage.
>
> Jan
> On 2/15/22 07:06, Jean-Baptiste Onofré wrote:
>
> Hi,
>
> I don't have concerns: if Beam is OK with the issue single milestone use,
> that's fine with me ;)
>
> Thanks for the detailed document, it helps!
>
> Regards
> JB
>
> On Tue, Feb 15, 2022 at 6:52 AM Aizhamal Nurmamat kyzy <
> aizhamal@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 <
>> dannymccormick@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 <
>>> aizhamal@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 <
>>>> aizhamal@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 <
>>>>> dannymccormick@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 <zh...@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 <
>>>>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>>> jarek@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
>>>>>>>>>>>>>>>>> <ke...@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 <dh...@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 <
>>>>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>>
>>>>>>>>> zhoufek@google.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Zachary Houfek
>>>>>>>
>>>>>>> Software Engineer
>>>>>>>
>>>>>>> DataPLS PLAT
>>>>>>>
>>>>>>> zhoufek@google.com
>>>>>>>
>>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jan Lukavský <je...@seznam.cz>.
Hi,
+1 from my side as well, thanks for the summary. I suppose the migration
plan is going to be clarified. I think it would be nice to preserve the
assignee and reporter, but that can be probably resolved at later stage.
Jan
On 2/15/22 07:06, Jean-Baptiste Onofré wrote:
> Hi,
>
> I don't have concerns: if Beam is OK with the issue single
> milestone use, that's fine with me ;)
>
> Thanks for the detailed document, it helps!
>
> Regards
> JB
>
> On Tue, Feb 15, 2022 at 6:52 AM Aizhamal Nurmamat kyzy
> <ai...@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
> <da...@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
> <ai...@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
> <ai...@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
> <da...@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
> <zh...@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 <ze...@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 <zh...@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 <ke...@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
> <ke...@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 <ai...@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
> <bh...@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
> <ke...@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
> <ai...@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
> <ro...@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
> <ar...@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
> <ai...@apache.org>
> wrote:
> >
> > Hi all,
> >
> > Is
> there
> a
> consensus
> to
> migrate
> to GitHub?
> >
> > On
> Wed,
> Dec
> 15,
> 2021
> at
> 9:17
> AM
> Brian
> Hulette
> <bh...@google.com>
> wrote:
> >>
> >>
> >>
> >> On
> Tue,
> Dec
> 14,
> 2021
> at
> 1:14
> PM
> Kenneth
> Knowles
> <kl...@google.com>
> wrote:
> >>>
> >>>
> >>>
> >>> On
> Thu,
> Dec 9,
> 2021
> at
> 11:50
> PM
> Jean-Baptiste
> Onofre
> <jb...@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
> <kc...@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
> <ar...@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
> <bh...@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
> <ar...@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
> <ke...@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
> <dh...@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
> <ro...@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
> <ye...@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
> <bh...@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
>
> zhoufek@google.com
> <ma...@google.com>
>
>
>
> --
>
>
> Zachary Houfek
>
> Software Engineer
>
> DataPLS PLAT
>
> zhoufek@google.com <ma...@google.com>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Danny McCormick <da...@google.com>.
Hey everyone, I've been building out some tooling for the Jira->Issues
migration and wanted to gather some thoughts/feedback on a few things:
1) Given that this is a significant change for everyone, I'd like to set a
target migration date so that everyone has time to make any necessary
adjustments to their workflows and raise any concerns they still have in
advance. Specifically, I'd like to target June 3 (3 weeks from today). Are
there any objections to that date?
2) We didn't get complete consensus on the value of migrating existing
Jiras. I think this is worthwhile and I built out a migration tool that we
can use (code here <https://github.com/damccorm/jira-to-issues>, PRs
welcome). I ran a test migration and it produced these issues
<https://github.com/damccorm/test-migration-target/issues>, which I think
are pretty high-fidelity versions of the initial Jiras, with a few
limitations*. I'd like to use that tool as part of the migration -
does anyone have objections or +1s to that approach?
*Feel free to ignore below this line if you're not interested in the
migration process/current status*
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I've included some notes on status and remaining TODOs below - let me know
if you'd like to help out with anything. For those who have already
volunteered to help on docs, please feel free to start putting up PRs
(draft or final) even if they can't be merged until we migrate.
*Completed Work*
- Issue templates have been added
<https://github.com/apache/beam/pull/17588>
- Rather than porting the existing outdated dependency automation, we added
Dependabot (discussion
<https://lists.apache.org/thread/txnmjmr235o2wg8or9wsp0k312cyvmq2>, PR
<https://github.com/apache/beam/pull/17563>)
- Migration tool <https://github.com/damccorm/jira-to-issues> is complete
*Active Work*
- Some GitHub automation for issue management is in PR
<https://github.com/apache/beam/pull/17661>
- Most pre-migration doc changes are ready to go (this PR
<https://github.com/apache/beam/pull/17594> will remain in draft for a
while and will need another pass closer to the migration to resolve
conflicts + catch any other Jira references that are added)
*Remaining Known Migration Blockers*
- Milestones need to be created to map work to releases
*Other Remaining Known Work*
- Day of migration work (turn on issues, turn off new Jiras, run migration
tool, merge documentation updates)
- (post-migration) Community metrics need to be updated to use GitHub
issues instead of jira
<https://github.com/apache/beam/blob/13869515455f43f94404155463eb9e824ab17a4c/.test-infra/metrics/sync/jira/syncjira.py>
- (post-migration) Additional doc updates will be needed to point some
active jira references to issues instead
- (post-migration) Dependency update Jira creation automation needs to be
removed (replaced by Dependabot)
Thanks,
Danny
* The known limitations of the current migration tool are:
1. It links to the original Jira instead of including all comments (which
would probably not be technically feasible because of how GitHub does rate
limits on issue/comment creation)
2. It does not port any of the following: fix version, associated GitHub
PRs, time tracking, dates, or attachments. Some of these may be feasible if
others think they are important, but they all should also be discoverable
by following the link to the original Jira.
3. It only ports open Jiras. This is actually relatively easily tunable,
but it would take a *very *long time to run with all closed Jiras. If we
want this, I'd recommend doing it as part of a 2nd pass post-migration.
4. It takes about 24 hours to run to completion (because of GitHub's rate
limits).
As a note, in my test migration I overrode the issue assignee to be myself
to avoid spamming y'all with test notifications. Almost all active issues
should get correctly mapped to their owners in the real migration using this
mapping function
<https://github.com/damccorm/jira-to-issues/blob/e38c93ee40aa6db11b36fba73ab84157e58e47f5/shared/translate.ts#L252>
.
On Wed, Mar 30, 2022 at 12:47 PM Aizhamal Nurmamat kyzy <ai...@apache.org>
wrote:
> 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 <
> dannymccormick@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 <
>> dannymccormick@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 <sa...@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 <
>>>> aizhamal@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.dev@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 <ai...@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 <
>>>>>> dannymccormick@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 <
>>>>>>> aizhamal@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 <
>>>>>>>> aizhamal@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 <
>>>>>>>>> dannymccormick@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 <
>>>>>>>>>> zhoufek@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 <
>>>>>>>>>>> zeidoo@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 <
>>>>>>>>>>>> zhoufek@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 <
>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste
>>>>>>>>>>>>>>>>>>>>> Onofre <jb...@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 <
>>>>>>>>>>>>>>>>>>>>> kcweaver@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
>>>>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>>>>>> bhulette@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 <ar...@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 <
>>>>>>>>>>>>>>>>>>>>> ehudm@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 <ke...@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 <dh...@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 <ro...@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 <
>>>>>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Zachary Houfek
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> DataPLS PLAT
>>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <da...@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 <da...@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 <sa...@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 <
>>> aizhamal@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.dev@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 <ai...@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 <
>>>>> dannymccormick@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 <
>>>>>> aizhamal@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 <
>>>>>>> aizhamal@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 <
>>>>>>>> dannymccormick@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 <
>>>>>>>>> zhoufek@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 <
>>>>>>>>>> zeidoo@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 <
>>>>>>>>>>> zhoufek@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 <
>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste
>>>>>>>>>>>>>>>>>>>> Onofre <jb...@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 <
>>>>>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>>>>> bhulette@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 <ar...@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 <
>>>>>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>>>>>> jarek@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 <ke...@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 <dh...@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 <ro...@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 <
>>>>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Zachary Houfek
>>>>>>>>>> Software Engineer
>>>>>>>>>> DataPLS PLAT
>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>
>>>>>>>>>
>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Danny McCormick <da...@google.com>.
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 <da...@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 <sa...@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 <
>> aizhamal@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.dev@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 <ai...@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 <
>>>> dannymccormick@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 <
>>>>> aizhamal@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 <
>>>>>> aizhamal@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 <
>>>>>>> dannymccormick@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 <zh...@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 <
>>>>>>>>> zeidoo@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 <
>>>>>>>>>> zhoufek@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 <
>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre
>>>>>>>>>>>>>>>>>>> <jb...@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 <
>>>>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>>>> bhulette@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 <ar...@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 <
>>>>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>>>>> jarek@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 <ke...@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 <dh...@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 <ro...@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 <
>>>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Zachary Houfek
>>>>>>>>> Software Engineer
>>>>>>>>> DataPLS PLAT
>>>>>>>>> zhoufek@google.com
>>>>>>>>>
>>>>>>>>
>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Danny McCormick <da...@google.com>.
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 <sa...@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 <
> aizhamal@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.dev@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 <ai...@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 <
>>> dannymccormick@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 <
>>>> aizhamal@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 <
>>>>> aizhamal@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 <
>>>>>> dannymccormick@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 <zh...@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 <
>>>>>>>> zeidoo@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 <
>>>>>>>>> zhoufek@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 <ke...@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 <
>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>>> bhulette@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
>>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>>>> jarek@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 <ke...@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 <dh...@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
>>>>>>>>>>>>>>>>>> <ro...@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 <
>>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>>> zhoufek@google.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Zachary Houfek
>>>>>>>> Software Engineer
>>>>>>>> DataPLS PLAT
>>>>>>>> zhoufek@google.com
>>>>>>>>
>>>>>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Sachin Agarwal <sa...@google.com>.
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 <ai...@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 <ar...@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 <ai...@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 <
>> dannymccormick@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 <
>>> aizhamal@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 <
>>>> aizhamal@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 <
>>>>> dannymccormick@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 <zh...@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 <
>>>>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>>> jarek@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
>>>>>>>>>>>>>>>>> <ke...@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 <dh...@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 <
>>>>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>> zhoufek@google.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Zachary Houfek
>>>>>>> Software Engineer
>>>>>>> DataPLS PLAT
>>>>>>> zhoufek@google.com
>>>>>>>
>>>>>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <ar...@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 <ai...@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 <da...@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 <
>> aizhamal@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 <
>>> aizhamal@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 <
>>>> dannymccormick@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 <zh...@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 <
>>>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>> kenn@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 <dh...@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 <
>>>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>> zhoufek@google.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Zachary Houfek
>>>>>> Software Engineer
>>>>>> DataPLS PLAT
>>>>>> zhoufek@google.com
>>>>>>
>>>>>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Alexey Romanenko <ar...@gmail.com>.
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 <ai...@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 <https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#bookmark=id.izn35w5gsjft>
> On Thu, Feb 10, 2022 at 1:12 PM Danny McCormick <dannymccormick@google.com <ma...@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 <aizhamal@apache.org <ma...@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# <https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#>
>
>
> On Mon, Jan 31, 2022 at 7:23 PM Aizhamal Nurmamat kyzy <aizhamal@apache.org <ma...@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# <https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#>
>
> On Mon, Jan 31, 2022, 10:06 AM Danny McCormick <dannymccormick@google.com <ma...@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 <https://github.com/damccorm/tag-ur-it>
> [2] https://github.com/microsoft/azure-pipelines-tasks/issues/15839 <https://github.com/microsoft/azure-pipelines-tasks/issues/15839>
>
> Thanks,
> Danny
>
> On Mon, Jan 31, 2022 at 12:49 PM Zachary Houfek <zhoufek@google.com <ma...@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 <zeidoo@gmail.com <ma...@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 <zhoufek@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <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 <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 <kenn@apache.org <ma...@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 <kenn@apache.org <ma...@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 <aizhamal@apache.org <ma...@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# <https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#>
> On Fri, Jan 28, 2022 at 2:30 PM Brian Hulette <bhulette@google.com <ma...@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 <kenn@apache.org <ma...@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 <aizhamal@apache.org <ma...@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 <robertwb@google.com <ma...@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.dev@gmail.com <ma...@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 <aizhamal@apache.org <ma...@apache.org>> wrote:
> >
> > Hi all,
> >
> > Is there a consensus to migrate to GitHub?
> >
> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bhulette@google.com <ma...@google.com>> wrote:
> >>
> >>
> >>
> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <klk@google.com <ma...@google.com>> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb@nanthrax.net <ma...@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 <https://github.com/pandas-dev/pandas/milestones> vs. https://github.com/pandas-dev/pandas/labels <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 <kcweaver@google.com <ma...@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 <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 <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 <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://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632>
> >>>> > https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all <https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all>
> >>>> >
> >>>> >
> >>>> > On Wed, Dec 8, 2021 at 9:13 AM Alexey Romanenko <aromanenko.dev@gmail.com <ma...@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 <jarek@potiuk.com <ma...@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+ <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 <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 <bhulette@google.com <ma...@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.dev@gmail.com <ma...@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 <ehudm@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <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 <kenn@apache.org <ma...@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 <dhuntsperger@google.com <ma...@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 <robert@frantil.com <ma...@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 <https://github.com/golang/go/issues/new/choose>
> >>>> > >>>>>>>
> >>>> > >>>>>>> On Fri, Dec 3, 2021, 12:17 PM Andy Ye <yeandy@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632>
> >>>> > >>>>>>>>>
> >>>> > >>>>>>>>> J,
> >>>> > >>>>>>>>>
> >>>> > >>>>>>>>>
> >>>> > >>>>>>>>> On Fri, Dec 3, 2021 at 7:46 PM Brian Hulette <bhulette@google.com <ma...@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 <https://lists.apache.org/thread/w3dr1vlt9115r3x9m7bprmo4zpnog483>
> >>>> > >>>>>>>>>> [2] https://github.com/apache/arrow-datafusion/issues <https://github.com/apache/arrow-datafusion/issues>
> >>>> > >>>>>>>>>> [3] https://issues.apache.org/jira/projects/AIRFLOW/issues <https://issues.apache.org/jira/projects/AIRFLOW/issues>
> >>>> > >>>>>>>>>> [4] https://github.com/apache/airflow/issues <https://github.com/apache/airflow/issues>
> >>>> > >>>
> >>>> > >>>
> >>>> >
> >>>>
> >
>
>
> --
>
> Zachary Houfek
> Software Engineer
> DataPLS PLAT
> zhoufek@google.com
> <ma...@google.com>
>
> --
>
> Zachary Houfek
> Software Engineer
> DataPLS PLAT
> zhoufek@google.com
> <ma...@google.com>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I don't have concerns: if Beam is OK with the issue single milestone use,
that's fine with me ;)
Thanks for the detailed document, it helps!
Regards
JB
On Tue, Feb 15, 2022 at 6:52 AM Aizhamal Nurmamat kyzy <ai...@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 <da...@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 <
>> aizhamal@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 <
>>> aizhamal@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 <
>>>> dannymccormick@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 <zh...@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 <
>>>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>>> kenn@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 <dh...@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 <
>>>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>>>> yeandy@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 <bh...@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
>>>>>>>>
>>>>>>>> zhoufek@google.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Zachary Houfek
>>>>>>
>>>>>> Software Engineer
>>>>>>
>>>>>> DataPLS PLAT
>>>>>>
>>>>>> zhoufek@google.com
>>>>>>
>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <da...@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 <
> aizhamal@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 <
>> aizhamal@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 <
>>> dannymccormick@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 <zh...@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 <
>>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>> bhulette@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 <
>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>>> kenn@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 <dh...@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 <
>>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>>> yeandy@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 <
>>>>>>>>>>>>>>> jarek@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 <bh...@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
>>>>>>>
>>>>>>> zhoufek@google.com
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Zachary Houfek
>>>>>
>>>>> Software Engineer
>>>>>
>>>>> DataPLS PLAT
>>>>>
>>>>> zhoufek@google.com
>>>>>
>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Danny McCormick <da...@google.com>.
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 <ai...@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 <
> aizhamal@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 <da...@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 <zh...@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 <
>>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>>> aizhamal@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 <
>>>>>>>>>> bhulette@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 <ke...@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 <
>>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>> >>>
>>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>>> kenn@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
>>>>>>>>>>>>>> <dh...@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 <
>>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>>> yeandy@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 <
>>>>>>>>>>>>>> jarek@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
>>>>>>>>>>>>>> <bh...@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
>>>>>>
>>>>>> zhoufek@google.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Zachary Houfek
>>>>
>>>> Software Engineer
>>>>
>>>> DataPLS PLAT
>>>>
>>>> zhoufek@google.com
>>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <ai...@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 <da...@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 <zh...@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 <
>>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>>> robertwb@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
>>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>>
>>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>>> ehudm@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 <
>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>>> dhuntsperger@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 <
>>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>>> yeandy@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 <
>>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>>> bhulette@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
>>>>>
>>>>> zhoufek@google.com
>>>>>
>>>>
>>>
>>> --
>>>
>>> Zachary Houfek
>>>
>>> Software Engineer
>>>
>>> DataPLS PLAT
>>>
>>> zhoufek@google.com
>>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <da...@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 <zh...@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 <
>> zeidoo@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>>>>> aizhamal@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 <
>>>>>>>>>>> robertwb@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
>>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> > Hi all,
>>>>>>>>>>>> >
>>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>>> jb@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 <
>>>>>>>>>>>> kcweaver@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.dev@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 <
>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>> kenn@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 <
>>>>>>>>>>>> dhuntsperger@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 <
>>>>>>>>>>>> robert@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 <
>>>>>>>>>>>> yeandy@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 <
>>>>>>>>>>>> jarek@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 <
>>>>>>>>>>>> bhulette@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
>>>>
>>>> zhoufek@google.com
>>>>
>>>
>>
>> --
>>
>> Zachary Houfek
>>
>> Software Engineer
>>
>> DataPLS PLAT
>>
>> zhoufek@google.com
>>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Danny McCormick <da...@google.com>.
> 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 <zh...@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 <ze...@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>>>> aizhamal@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 <
>>>>>>>>>> robertwb@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
>>>>>>>>>>> <ar...@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 <
>>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Hi all,
>>>>>>>>>>> >
>>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>>> jarek@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 <
>>>>>>>>>>> kenn@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 <
>>>>>>>>>>> dhuntsperger@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 <
>>>>>>>>>>> robert@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 <
>>>>>>>>>>> yeandy@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 <
>>>>>>>>>>> jarek@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 <
>>>>>>>>>>> bhulette@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
>>>
>>> zhoufek@google.com
>>>
>>
>
> --
>
> Zachary Houfek
>
> Software Engineer
>
> DataPLS PLAT
>
> zhoufek@google.com
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Zachary Houfek <zh...@google.com>.
> 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 <ze...@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 <zh...@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 <ke...@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 <ke...@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 <
>>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>>> aizhamal@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 <
>>>>>>>>> robertwb@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
>>>>>>>>>> <ar...@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 <
>>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Hi all,
>>>>>>>>>> >
>>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <
>>>>>>>>>> klk@google.com> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>>> jarek@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 <
>>>>>>>>>> kenn@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 <
>>>>>>>>>> dhuntsperger@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 <
>>>>>>>>>> robert@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 <
>>>>>>>>>> yeandy@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 <
>>>>>>>>>> jarek@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 <
>>>>>>>>>> bhulette@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
>>
>> zhoufek@google.com
>>
>
--
Zachary Houfek
Software Engineer
DataPLS PLAT
zhoufek@google.com
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Cristian Constantinescu <ze...@gmail.com>.
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 <zh...@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 <ke...@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 <ke...@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 <
>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>> aizhamal@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 <
>>>>>>>> robertwb@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
>>>>>>>>> <ar...@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 <
>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>> >
>>>>>>>>> > Hi all,
>>>>>>>>> >
>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>> >
>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>>>>>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>> jarek@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 <
>>>>>>>>> kenn@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 <
>>>>>>>>> dhuntsperger@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 <
>>>>>>>>> robert@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 <
>>>>>>>>> yeandy@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 <
>>>>>>>>> jarek@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 <
>>>>>>>>> bhulette@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
>
> zhoufek@google.com
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jarek Potiuk <ja...@potiuk.com>.
> 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>
)
Not entirely correct.
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 - and yeah you can have multiple PRs linked to the same JIRA
issue without closing it.
You can also (anyone even with read access) can link the issues and PR by
referring to each other in the comments in GitHub UI. This has the - very
nicely working - auto-complete feature. You just start typing #some words -
and if the words are related to the issue, it will more often than not
allow you to choose the issue via autocomplete.
This is actually one of the reasons why in Airflow we not only have
everything PRs and issue interlinked, but we are even able to make this
kind of automated issues: https://github.com/apache/airflow/issues/20615
which not only refer to the PRs and issues solved since the last release
but also automatically mark people who were involved in solving them. This
is because those users are common among PRs and issues.
J.
On Mon, Jan 31, 2022 at 6:21 PM Zachary Houfek <zh...@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 <ke...@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 <ke...@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 <
>>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>>> aizhamal@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 <
>>>>>>>> robertwb@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
>>>>>>>>> <ar...@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 <
>>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>>> >
>>>>>>>>> > Hi all,
>>>>>>>>> >
>>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>>> >
>>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>>> bhulette@google.com> wrote:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>>>>>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>>>> bhulette@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.dev@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 <
>>>>>>>>> jarek@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 <
>>>>>>>>> kenn@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 <
>>>>>>>>> dhuntsperger@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 <
>>>>>>>>> robert@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 <
>>>>>>>>> yeandy@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 <
>>>>>>>>> jarek@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 <
>>>>>>>>> bhulette@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
>
> zhoufek@google.com
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Zachary Houfek <zh...@google.com>.
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 <ke...@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 <ke...@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 <
>>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>>> aizhamal@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 <
>>>>>>> robertwb@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
>>>>>>>> <ar...@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 <
>>>>>>>> aizhamal@apache.org> wrote:
>>>>>>>> >
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>>> >
>>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <
>>>>>>>> bhulette@google.com> wrote:
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>>> bhulette@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.dev@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 <
>>>>>>>> jarek@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 <
>>>>>>>> kenn@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 <
>>>>>>>> dhuntsperger@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 <
>>>>>>>> robert@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 <
>>>>>>>> yeandy@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 <
>>>>>>>> jarek@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 <
>>>>>>>> bhulette@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
zhoufek@google.com
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ke...@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 <ke...@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 <
>> aizhamal@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 <bh...@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 <ke...@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 <
>>>>> aizhamal@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 <ro...@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
>>>>>>> <ar...@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 <
>>>>>>> aizhamal@apache.org> wrote:
>>>>>>> >
>>>>>>> > Hi all,
>>>>>>> >
>>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>>> >
>>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>>> bhulette@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.dev@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 <
>>>>>>> jarek@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 <
>>>>>>> kenn@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 <
>>>>>>> dhuntsperger@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 <
>>>>>>> robert@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 <
>>>>>>> yeandy@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 <
>>>>>>> jarek@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 <
>>>>>>> bhulette@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
>>>>>>> >>>> > >>>
>>>>>>> >>>> > >>>
>>>>>>> >>>> >
>>>>>>> >>>>
>>>>>>> >
>>>>>>>
>>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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 <
> aizhamal@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 <bh...@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 <ke...@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 <
>>>> aizhamal@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 <ro...@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
>>>>>> <ar...@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 <
>>>>>> aizhamal@apache.org> wrote:
>>>>>> >
>>>>>> > Hi all,
>>>>>> >
>>>>>> > Is there a consensus to migrate to GitHub?
>>>>>> >
>>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>>> jb@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 <kc...@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.dev@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 <
>>>>>> bhulette@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.dev@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 <
>>>>>> jarek@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 <
>>>>>> kenn@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 <
>>>>>> dhuntsperger@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 <
>>>>>> robert@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 <
>>>>>> yeandy@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 <
>>>>>> jarek@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 <
>>>>>> bhulette@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
>>>>>> >>>> > >>>
>>>>>> >>>> > >>>
>>>>>> >>>> >
>>>>>> >>>>
>>>>>> >
>>>>>>
>>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ai...@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 <bh...@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 <ke...@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 <
>>> aizhamal@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 <ro...@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
>>>>> <ar...@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 <
>>>>> aizhamal@apache.org> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> >
>>>>> > Is there a consensus to migrate to GitHub?
>>>>> >
>>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>>>>> wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>>> jb@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 <kc...@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.dev@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 <
>>>>> bhulette@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.dev@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 <
>>>>> jarek@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 <
>>>>> kenn@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 <
>>>>> dhuntsperger@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 <
>>>>> robert@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 <
>>>>> yeandy@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 <
>>>>> jarek@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 <
>>>>> bhulette@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
>>>>> >>>> > >>>
>>>>> >>>> > >>>
>>>>> >>>> >
>>>>> >>>>
>>>>> >
>>>>>
>>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <bh...@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 <ke...@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 <
>> aizhamal@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 <ro...@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
>>>> <ar...@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 <ai...@apache.org>
>>>> wrote:
>>>> >
>>>> > Hi all,
>>>> >
>>>> > Is there a consensus to migrate to GitHub?
>>>> >
>>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>>> wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>>> jb@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 <kc...@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.dev@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 <
>>>> bhulette@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.dev@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 <
>>>> jarek@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 <
>>>> kenn@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 <
>>>> dhuntsperger@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 <
>>>> robert@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 <ye...@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 <
>>>> jarek@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 <
>>>> bhulette@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
>>>> >>>> > >>>
>>>> >>>> > >>>
>>>> >>>> >
>>>> >>>>
>>>> >
>>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Brian Hulette <bh...@google.com>.
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 <ke...@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 <
> aizhamal@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 <ro...@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
>>> <ar...@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 <ai...@apache.org>
>>> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > Is there a consensus to migrate to GitHub?
>>> >
>>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>>> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <
>>> jb@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 <kc...@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.dev@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 <
>>> bhulette@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.dev@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 <
>>> kenn@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 <
>>> dhuntsperger@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 <
>>> robert@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 <ye...@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 <
>>> jarek@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 <
>>> bhulette@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
>>> >>>> > >>>
>>> >>>> > >>>
>>> >>>> >
>>> >>>>
>>> >
>>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ai...@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 <ro...@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
>> <ar...@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 <ai...@apache.org>
>> wrote:
>> >
>> > Hi all,
>> >
>> > Is there a consensus to migrate to GitHub?
>> >
>> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
>> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com>
>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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 <kc...@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.dev@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 <
>> bhulette@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.dev@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 <
>> kenn@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 <
>> dhuntsperger@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 <
>> robert@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 <ye...@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 <
>> jarek@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 <
>> bhulette@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
>> >>>> > >>>
>> >>>> > >>>
>> >>>> >
>> >>>>
>> >
>>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
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 <ro...@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
> <ar...@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 <ai...@apache.org>
> wrote:
> >
> > Hi all,
> >
> > Is there a consensus to migrate to GitHub?
> >
> > On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com>
> wrote:
> >>
> >>
> >>
> >> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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 <kc...@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.dev@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 <bh...@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.dev@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 <
> kenn@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 <
> dhuntsperger@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 <
> robert@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 <ye...@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 <
> jarek@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 <
> bhulette@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
> >>>> > >>>
> >>>> > >>>
> >>>> >
> >>>>
> >
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Robert Bradshaw <ro...@google.com>.
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
<ar...@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 <ai...@apache.org> wrote:
>
> Hi all,
>
> Is there a consensus to migrate to GitHub?
>
> On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com> wrote:
>>
>>
>>
>> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com> wrote:
>>>
>>>
>>>
>>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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 <kc...@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 <ar...@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 <bh...@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 <ar...@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 <ke...@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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
>>>> > >>>
>>>> > >>>
>>>> >
>>>>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Alexey Romanenko <ar...@gmail.com>.
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 <ai...@apache.org> wrote:
>
> Hi all,
>
> Is there a consensus to migrate to GitHub?
>
> On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bhulette@google.com <ma...@google.com>> wrote:
>
>
> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <klk@google.com <ma...@google.com>> wrote:
>
>
> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb@nanthrax.net <ma...@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 <https://github.com/pandas-dev/pandas/milestones> vs. https://github.com/pandas-dev/pandas/labels <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 <kcweaver@google.com <ma...@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 <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 <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 <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://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632>
> > https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all <https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all>
> >
> >
> > On Wed, Dec 8, 2021 at 9:13 AM Alexey Romanenko <aromanenko.dev@gmail.com <ma...@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 <jarek@potiuk.com <ma...@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+ <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 <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 <bhulette@google.com <ma...@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.dev@gmail.com <ma...@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 <ehudm@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <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 <kenn@apache.org <ma...@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 <dhuntsperger@google.com <ma...@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 <robert@frantil.com <ma...@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 <https://github.com/golang/go/issues/new/choose>
> > >>>>>>>
> > >>>>>>> On Fri, Dec 3, 2021, 12:17 PM Andy Ye <yeandy@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632>
> > >>>>>>>>>
> > >>>>>>>>> J,
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Fri, Dec 3, 2021 at 7:46 PM Brian Hulette <bhulette@google.com <ma...@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 <https://lists.apache.org/thread/w3dr1vlt9115r3x9m7bprmo4zpnog483>
> > >>>>>>>>>> [2] https://github.com/apache/arrow-datafusion/issues <https://github.com/apache/arrow-datafusion/issues>
> > >>>>>>>>>> [3] https://issues.apache.org/jira/projects/AIRFLOW/issues <https://issues.apache.org/jira/projects/AIRFLOW/issues>
> > >>>>>>>>>> [4] https://github.com/apache/airflow/issues <https://github.com/apache/airflow/issues>
> > >>>
> > >>>
> >
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Aizhamal Nurmamat kyzy <ai...@apache.org>.
Hi all,
Is there a consensus to migrate to GitHub?
On Wed, Dec 15, 2021 at 9:17 AM Brian Hulette <bh...@google.com> wrote:
>
>
> On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com> wrote:
>
>>
>>
>> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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 <kc...@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.dev@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 <bh...@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.dev@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 <ke...@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 <
>>> dhuntsperger@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 <ro...@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 <ye...@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 <
>>> bhulette@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
>>> > >>>
>>> > >>>
>>> >
>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Brian Hulette <bh...@google.com>.
On Tue, Dec 14, 2021 at 1:14 PM Kenneth Knowles <kl...@google.com> wrote:
>
>
> On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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 <kc...@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.dev@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 <bh...@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.dev@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 <ke...@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 <
>> dhuntsperger@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 <ro...@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 <ye...@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 <
>> bhulette@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
>> > >>>
>> > >>>
>> >
>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <kl...@google.com>.
On Thu, Dec 9, 2021 at 11:50 PM Jean-Baptiste Onofre <jb...@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.
Kenn
>
> Regards
> JB
>
> > Le 10 déc. 2021 à 01:28, Kyle Weaver <kc...@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.dev@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 <bh...@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.dev@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 <ke...@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 <
> dhuntsperger@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 <ro...@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 <ye...@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 <
> bhulette@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
> > >>>
> > >>>
> >
>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Alexey Romanenko <ar...@gmail.com>.
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 <bh...@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 <ar...@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 <ke...@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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jan Lukavský <je...@seznam.cz>.
Hi,
for complete clarity, can we sum up which features of Jira we actually
do use and how would those be mapped onto the functionality provided by
GH issues? Questions from the top of my head:
- do we use nested issues/sub-issues? If yes, how would we map those
on GH issues?
- do we use other Jira relations (depends on, blocks, is blocked by,
is duplicated by, ...) and if yes, do we want to preserve those?
- which fields of Jira (component, type, priority, affected and fixed
version, ...) do we use and how do we map those on GH?
- are we going to preserve reporter and assignee (if any)? Do we have
mapping from Jira ID to GH ID?
I'm generally +1 to the transition, as fewer systems is always better,
but we should be sure of the real impact.
Jan
On 12/8/21 01:38, Jarek Potiuk 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 <bh...@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 <ar...@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 <ke...@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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jarek Potiuk <ja...@potiuk.com>.
> 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 <bh...@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 <ar...@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 <ke...@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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Brian Hulette <bh...@google.com>.
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 <ar...@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 <ke...@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 <
>> dhuntsperger@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 <ro...@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 <ye...@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 <bh...@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
>>
>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Alexey Romanenko <ar...@gmail.com>.
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 <jarek@potiuk.com <ma...@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 <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 <kenn@apache.org <ma...@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 <dhuntsperger@google.com <ma...@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 <robert@frantil.com <ma...@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 <https://github.com/golang/go/issues/new/choose>
> >>>
> >>> On Fri, Dec 3, 2021, 12:17 PM Andy Ye <yeandy@google.com <ma...@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 <jarek@potiuk.com <ma...@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 <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632>
> >>>>>
> >>>>> J,
> >>>>>
> >>>>>
> >>>>> On Fri, Dec 3, 2021 at 7:46 PM Brian Hulette <bhulette@google.com <ma...@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 <https://lists.apache.org/thread/w3dr1vlt9115r3x9m7bprmo4zpnog483>
> >>>>> > [2] https://github.com/apache/arrow-datafusion/issues <https://github.com/apache/arrow-datafusion/issues>
> >>>>> > [3] https://issues.apache.org/jira/projects/AIRFLOW/issues <https://issues.apache.org/jira/projects/AIRFLOW/issues>
> >>>>> > [4] https://github.com/apache/airflow/issues <https://github.com/apache/airflow/issues>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Udi Meiri <eh...@google.com>.
+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 <ke...@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 <
> dhuntsperger@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 <ro...@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 <ye...@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 <bh...@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
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <ke...@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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Kenneth Knowles <ke...@apache.org>.
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 <dh...@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 <ro...@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 <ye...@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 <bh...@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
>>>>
>>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by David Huntsperger <dh...@google.com>.
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 <ro...@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 <ye...@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 <bh...@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
>>>
>>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Robert Burke <ro...@frantil.com>.
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 <ye...@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 <bh...@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
>>
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Andy Ye <ye...@google.com>.
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 <bh...@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
>
Re: [DISCUSS] Migrate Jira to GitHub Issues?
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <bh...@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