Thanks for the input folks, I'm reading your contributions, I will look into proposing a solution summarizing the conversation at the end of the week, so if you have other ideas share them here.
Thanks! On 2020/08/04 18:42:15, Alex Amato <[email protected]> wrote: > May I suggest we print a URL(and a message) you can use to file bugs at, in > the command line when you run a beam pipeline. (And in any other user > interface we use for beam, some of the runner specific UIs may want to link > to this as well). > > On Tue, Aug 4, 2020 at 9:16 AM Alexey Romanenko <[email protected]> > wrote: > > > Great topic, thanks Griselda for raising this question. > > > > I’d prefer to keep Jira as the only one main issue tracker and use other > > suggested ways, like emails, Git issues, web form or dedicated Slack > > channel, as different interfaces designed to simplify a way how users can > > submit an issue. But in any case it will require an attention of Beam > > contributors to properly create Jira issue and send back a link that can be > > followed for updates. > > > > On 31 Jul 2020, at 20:22, Robert Burke <[email protected]> wrote: > > > > 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 <[email protected]> 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 [email protected] > >> - 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 <[email protected]> > >> wrote: > >> > >>> On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles <[email protected]> wrote: > >>> > >>>> > >>>> On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <[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) > >>>> > >>> > >>> 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 <[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]"; 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]> > >>>>>> 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/ > >>>>>>> > >>>>>> > > >
