+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.
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/
