I think I'd prefer continuing to use jira, but GitHub issues are certainly much more discoverable for our users. The Arrow project uses GitHub issues as a way to funnel users to the mailing lists and JIRA. When users go to file an issue they're first given two options [1]:
- Ask a question -> Please ask questions at u...@arrow.apache.org - Report an issue -> Please report bugs and request features on JIRA. With accompanying links for each option. The user@ link actually takes you to the new issue page, with a template strongly encouraging you to file a jira or subscribe to the mailing lists. Despite all these barriers people do still file github issues, and they need to be triaged (usually they just receive a comment asking the reporter to file a jira or linking to an existing jira), but the volume isn't that high. Maybe we could consider something like that? Brian [1] https://github.com/apache/arrow/issues/new/choose On Thu, Jul 30, 2020 at 2:45 PM Robert Bradshaw <rober...@google.com> wrote: > On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles <k...@apache.org> wrote: > >> >> On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <rober...@google.com> >> wrote: >> >>> +1 to a simple link that fills in most of the fields in JIRA, though >>> this doesn't solve the issue of having to sign up just to submit a bug >>> report. Just using the users list isn't a bad idea either--we could easily >>> create a script that ensures all threads that have a message like "we >>> should file a JIRA for this" are followed up with a message like "JIRA >>> filed at ...". (That doesn't mean it won't language on the tracker.) >>> >>> I think it's worth seriously considering just using Github's issue >>> tracker, since that's where our users are. Is there anything in we actually >>> use in JIRA that'd be missing? >>> >> >> Pretty big question. Just noting to start that Apache projects certainly >> can and do use GitHub issues. Here is a quick inventory of things that are >> used in a meaningful way: >> >> - Priorities (with GitHub Issues I think you roll your own with labels) >> - Issue types (with GitHub Issues I think you roll your own with labels) >> - Distinct "Triage Needed" state (also labels; anything lacking the >> "triaged" label) >> - Distinguishing "Open" and "In Progress" (also labels? can use >> Projects/Milestones - I forget exactly which - to keep a kanban-ish status) >> > > Yes, basically everything can is done with labels. Whether having one > hammer is good, well, there are pros and cons. > > >> - Our new automation: "stale-assigned" and subsequent unassign; >> "stale-P2" and subsequent downgrade >> > > Github has a very nice ReST API, making things like this very easy. > > >> - Fix Version for associating fixes with releases >> > > This information is typically intrinsic with when the commits were applied > and the bug closed. It's pretty typical to use milestones for a release, > and then tag "blockers" to it. (IMHO, this is better than having the > default always be the next release, and bumping all open bugs every release > that comes out.) Milestones can be used to track other work as well. > > >> - Affect Version, while not used much, is still helpful to have >> - Components, since our repo is really a mini mono repo. Again, labels. >> - Kanban boards (milestones/projects maybe kinda) >> - Reports (not really same level, but maybe OK?) >> >> Fairly recently I worked on a project that tried to use GitHub Issues and >> Projects and Milestones and whatnot and it was OK but not great. Jira's >> complexity is largely essential / not really complex but just visually >> busy. The two are not really even comparable offerings. There may be third >> party integrations that add some of what you'd want. >> > > Yeah, I agree Github issues is not as full featured. One thing I miss from > other products is dependencies (though Jira's one level of subtasks isn't > the best either.) But maybe I am just not a power user of JIRA, mostly > using it as a (collective) TODO list and place to record state on > bugs/features. It'd be useful to understand what others actually use/would > really miss. > > The primary advantage of Github is to meet users where they are. I think > it'll make it easier for users to find, file, and follow issues with Beam. > > Also, I agree with Max, we should have one source of truth. If we switch > to github, we should actually switch (and such a step shouldn't be taken > lightly). > > >> On Wed, Jul 29, 2020 at 10:30 AM Kenneth Knowles <k...@apache.org> wrote: >>> >>>> Very good points. We want the barrier to filing a bug report to be as >>>> low as possible. Jira adds complexity of a sign up process and a complex >>>> interface, and also users don't know what the fields mean (issue type, >>>> priority, component, tag, fix version, etc). So it currently really doesn't >>>> make sense to just point users at Jira and expect them to figure it out. >>>> >>>> As for using user@beam for bug reports: >>>> >>>> - In practice, we have to edit most of the fields and improve the bug >>>> description anyhow, so it might be no extra work for an experienced >>>> contributor to file the bug based on the user's email. >>>> - Also in practice, we already do this. So it is just a matter of >>>> pointing users that way. >>>> >>>> One downside is that there is not really tracking of resolution of an >>>> email thread, so unless it gets filed as a Jira it may sit unresolved. >>>> >>>> Another option we could consider: I think we could have a "report a bug >>>> / feature request" link that fills in most fields and gives the user a >>>> simplified view (like GitHub issue view where it is just title & body). It >>>> could end up that these Jiras get ignored just as easily as a user@beam >>>> thread. >>>> >>>> You can always have a link like that and it could point to whatever the >>>> current choice is, like "mailto:u...@beam.apache.org"; though I think >>>> mailto links are out of fashion these days. >>>> >>>> Kenn >>>> >>>> On Fri, Jul 24, 2020 at 2:50 PM Griselda Cuevas <g...@apache.org> >>>> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I recently made a few Jira boards [1][2] to help triage and organize >>>>> Beam's backlog. >>>>> >>>>> >>>>> Something that came to my mind is that reporting bugs and feature >>>>> requests using Jira might be imposing a high barrier for users who don't >>>>> have an account. This process might also make it difficult to ask >>>>> follow-up >>>>> questions to reporters who don't monitor Jira's notifications. >>>>> >>>>> >>>>> I want to gather consensus on updating the website to give the option >>>>> to report bugs and feature requests by sending an email to users@b.a.o >>>>> and adding a tag to the subject line ([bug] OR [New Feature]) >>>>> >>>>> >>>>> There are other more sustainable solutions, like looking into using >>>>> GitHub issues, but they will have other costs, like migrating current >>>>> tickets and systems, pointing them out here in case we want to consider. >>>>> >>>>> >>>>> Let me know what you think, >>>>> >>>>> G >>>>> >>>>> >>>>> [1] >>>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335922# >>>>> >>>>> [2] >>>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335923# >>>>> >>>>> [3] https://beam.apache.org/contribute/ >>>>> >>>>> [4] https://beam.apache.org/community/contact-us/ >>>>> >>>>
