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