You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Alexey Romanenko <ar...@gmail.com> on 2020/08/04 16:16:03 UTC
Re: Making reporting bugs/feature request easier
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 <ro...@frantil.com> 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 <bhulette@google.com <ma...@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 user@arrow.apache.org <ma...@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 <https://github.com/apache/arrow/issues/new/choose>
> On Thu, Jul 30, 2020 at 2:45 PM Robert Bradshaw <robertwb@google.com <ma...@google.com>> wrote:
> On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles <kenn@apache.org <ma...@apache.org>> wrote:
>
> On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <robertwb@google.com <ma...@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 <kenn@apache.org <ma...@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:user@beam.apache.org <ma...@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 <gris@apache.org <ma...@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# <https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335922#>
> [2] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335923# <https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335923#>
> [3] https://beam.apache.org/contribute/ <https://beam.apache.org/contribute/>
> [4] https://beam.apache.org/community/contact-us/ <https://beam.apache.org/community/contact-us/>
Re: Making reporting bugs/feature request easier
Posted by Gris Cuevas <gr...@apache.org>.
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 <aj...@google.com> 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 <ar...@gmail.com>
> 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 <ro...@frantil.com> 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 <bh...@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 user@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 <ro...@google.com>
> >> wrote:
> >>
> >>> On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles <ke...@apache.org> wrote:
> >>>
> >>>>
> >>>> On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <ro...@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 <ke...@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:user@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 <gr...@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/
> >>>>>>>
> >>>>>>
> >
>
Re: Making reporting bugs/feature request easier
Posted by Alex Amato <aj...@google.com>.
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 <ar...@gmail.com>
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 <ro...@frantil.com> 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 <bh...@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 user@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 <ro...@google.com>
>> wrote:
>>
>>> On Wed, Jul 29, 2020 at 7:12 PM Kenneth Knowles <ke...@apache.org> wrote:
>>>
>>>>
>>>> On Wed, Jul 29, 2020 at 11:08 AM Robert Bradshaw <ro...@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 <ke...@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:user@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 <gr...@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/
>>>>>>>
>>>>>>
>