On Thu, Jul 30, 2020 at 6:37 AM Maximilian Michels <[email protected]> wrote:
> +1 for making it easier to report bug. Very often we have users report a > bug and then they have to rely on a developer to report the issue > because they don't want to bother creating a JIRA account (which is > understandable). If you have a JIRA account it is easy because you don't > need any additional permissions to create a ticket. > > We would need to tag such externally created issues and triage them from > time to time. That requires a regular review of some sort. We just have > to put something in place that will remind us, e.g. a weekly email. > We do have a "Triage Needed" status and there's a saved search for your convenience: https://issues.apache.org/jira/issues/?filter=12345682 <https://issues.apache.org/jira/issues/?filter=12345682#> I would imagine also that a new "incoming" component would be useful so neither users nor a bot have to guess what to put for component. Kenn Generally, I'm against using more than one bug tracker. There is nothing > inherently wrong with JIRA and we have our processes mapped there. > However, if Github Issues would lower the barrier significantly, I > suppose we could use it as an Inbox, but JIRA should remain the source > of truth. > > -Max > > On 30.07.20 04:12, Kenneth Knowles wrote: > > > > > > On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <[email protected] > > <mailto:[email protected]>> 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) > > - Our new automation: "stale-assigned" and subsequent unassign; > > "stale-P2" and subsequent downgrade > > - Fix Version for associating fixes with releases > > - 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. > > > > Kenn > > > > > > On Wed, Jul 29, 2020 at 10:30 AM Kenneth Knowles <[email protected] > > <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>" > > though I think mailto links are out of fashion these days. > > > > Kenn > > > > On Fri, Jul 24, 2020 at 2:50 PM Griselda Cuevas <[email protected] > > <mailto:[email protected]>> 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 [email protected] 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/ > > > >
