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
