I am also +1 as I also think this would lower the barrier to entry. We do have a lot of crossbow release related utilities to curate the release, cherry-pick commits, generate change logs, etcetera that will require migration too.
El mar, 25 oct 2022 a las 10:56, Nic (<thisis...@gmail.com>) escribió: > I'm also in support of moving over to GH Issues as I think lowering the > barrier to entry is pretty important, and that the effort of the migration > will be well worth it in the long run > > On Tue, 25 Oct 2022 at 00:54, Joris Van den Bossche < > jorisvandenboss...@gmail.com> wrote: > > > I would also support a migration of our issues to GitHub. It seems > > unlikely to me that another third-party tool would be good enough to > > make the whole experience better (given that we already use GitHub for > > PRs). And I agree with others that keep using JIRA is not a good > > option with this change. > > > > Although I regularly cursed JIRA (for its custom markup language, > > ...), it has indeed some nice features to organize issues that I will > > miss. I think that most things (components, issue types, priority) can > > be replaced with a strictly organized set of labels (and milestones > > for Fix version). > > I think the main thing we will miss are the Links (relation between > > issues), but we can try to promote some consistent usage of adding > > "Duplicate of #...", "Related to #..." in top post of an issue when > > appropriate. > > > > And +1 on exploring Discussions for what we currently use issues for > > (i.e. user questions, as alternative for the user mailing list), as > > Jacob mentions. > > > > Joris > > > > On Mon, 24 Oct 2022 at 19:25, Weston Pace <weston.p...@gmail.com> wrote: > > > > > > +1 for GH issues mainly because it lowers the barrier to entry and > > > JIRA won't be an acceptable solution any longer with infra's proposed > > > changes. I suspect I'd be +1 even without the infra change though > > > providing everyone else was willing to make the switch. > > > > > > On Mon, Oct 24, 2022 at 8:19 AM Jacob Wujciak > > > <ja...@voltrondata.com.invalid> wrote: > > > > > > > > +1 > > > > > > > > While there will be some work associated with migrating to Github > > Issues I > > > > think it is the only viable solution that does not impose an > untenable > > > > burden on the PMC. Additionally I think that using gh issues will > > lower the > > > > barrier for new contributions as experienced by arrow-rs. I don't > think > > > > another third-party tool is the solution as it would add maintenance > > burden > > > > on the arrow community (I doubt INFRA will setup anything else in > > addition > > > > to JIRA) with questionable value. > > > > > > > > I have no experience with github discussions but reading about it, it > > might > > > > be a good replacement for the functions our issues currently have > with > > a > > > > more forum/board like format that might increase discoverability of > > > > discussions. Issue template can now do more than just be prefilled > with > > > > text but actually act as forms: [1] > > > > > > > > > * Issue links: It seems that we can't do this. > > > > Well we can mention #issue_number in the comment closing the issue > and > > gh > > > > issues now have two distinct closing states for done and > > > > won't-fix/duplicate. > > > > > > > > [1]: > > > > > > > https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms > > > > > > > > On Mon, Oct 24, 2022 at 8:56 AM Sutou Kouhei <k...@clear-code.com> > > wrote: > > > > > > > > > Hi, > > > > > > > > > > +1 on migration. > > > > > > > > > > > The one thing I would not want to lose, though, is the > > categorization > > > > > > facilities we currently have in Jira. Namely: Component, Affects > > > > > > version, Fix version, Type (bug/improvement/task...), Issue links > > > > > > (superceded by/relates to/is caused by...), Priority (at least > > > > > > Minor/Major/Blocker). > > > > > > > > > > I tried using some GitHub features. > > > > > > > > > > * Component: We already use GitHub's label feature > > > > > * e.g.: lang-c++: > > > > > > > > > > > > > https://github.com/apache/arrow/pulls?q=is%3Apr+is%3Aopen+label%3Alang-c%2B%2B > > > > > * Affects version: Create new labels such as "affect-10.0.0"? > > > > > * Fix version: We can use GitHub's milestone feature > > > > > * I tried creating the "11.0.0" milestone: > > > > > https://github.com/apache/arrow/milestone/1 > > > > > * Type: GitHub's label feature or custom field in GitHub's > > > > > project feature? > > > > > * I tried creating a GitHub project for Apache Arrow: > > > > > https://github.com/orgs/apache/projects/148 > > > > > * All Apache Arrow committers have Admin role. You can > > > > > change anything to learn GitHub's project feature. > > > > > * Issue links: It seems that we can't do this. > > > > > * Priority: GitHub's label feature or custom field in GitHub's > > > > > project feature? > > > > > > > > > > > > > > > Thanks, > > > > > -- > > > > > kou > > > > > > > > > > In <82d49482-706d-081b-32e7-f692bc282...@python.org> > > > > > "Re: [DISCUSS] Move issue tracking to <something>" on Sat, 22 Oct > > 2022 > > > > > 16:19:14 +0200, > > > > > Antoine Pitrou <anto...@python.org> wrote: > > > > > > > > > > > > > > > > > Hi Neal, > > > > > > > > > > > > Le 22/10/2022 à 15:35, Neal Richardson a écrit : > > > > > >> Their email says: > > > > > >> > > > > > >>> Infra knows this process change places an increasing burden on > > PMC > > > > > >>> members > > > > > >>> for managing contributors, and makes it harder for people to > > > > > >>> contribute > > > > > >> bug reports. > > > > > >>> We suggest projects consider using GitHub Issues for > > customer-facing > > > > > >> questions/bug > > > > > >>> reports/etc., while maintaining development issues on Jira. > > > > > >> but I think that having a two-tiered system for issue tracking > > > > > >> presents > > > > > >> some notable downsides for us, including: > > > > > >> * Increased barriers to entry for new contributors and a sense > of > > > > > >> inequality between "us" and "them". There's already too much > > friction > > > > > >> IMO, > > > > > >> and this pushes that up significantly. > > > > > >> * Maintenance burden of triaging and synchronizing issues across > > > > > >> * trackers > > > > > >> sounds like a lot for us to take on. I'd prefer the active > > maintainers > > > > > >> on > > > > > >> the project spend their time shipping useful, reliable software, > > not > > > > > >> doing > > > > > >> bookkeeping. > > > > > > > > > > > > I fully agree with your concerns. So I'm +1 on migrating to > > > > > > *something else*. > > > > > > > > > > > > The one thing I would not want to lose, though, is the > > categorization > > > > > > facilities we currently have in Jira. Namely: Component, Affects > > > > > > version, Fix version, Type (bug/improvement/task...), Issue links > > > > > > (superceded by/relates to/is caused by...), Priority (at least > > > > > > Minor/Major/Blocker). > > > > > > > > > > > > How much of that can be recreated in Github Issues, or any other > > > > > > alternative? > > > > > > > > > > > > A secondary question is whether it's possible to migrate the > > current > > > > > > issues. Would be nice to have, but not blocking either (IMHO). > > > > > > > > > > > > Regards > > > > > > > > > > > > Antoine. > > > > > > > >
