I do like the idea of the "mwrong way to raise issues point to the correct ways.
On Fri, Jul 31, 2020, 10:57 AM Brian Hulette <bhule...@google.com> wrote: > 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/ >>>>>> >>>>>
