Just suggested using jira filters subscription as a low investment
alternative for the POC. Nice initiative imo.
On 10/4/21 23:18, Joshua McKenzie wrote:
> One brief note but otherwise LGTM as a starting point for trying something
> out.
>
> ~Josh
>
> On Sat, Apr 10, 2021 at 11:34 AM Paulo Motta
One brief note but otherwise LGTM as a starting point for trying something
out.
~Josh
On Sat, Apr 10, 2021 at 11:34 AM Paulo Motta
wrote:
> Hi folks,
>
> I consolidated the proposal previously discussed on how to improve JIRA
> ticket hygiene and visibility on this document [1]. For now I focus
Hi folks,
I consolidated the proposal previously discussed on how to improve JIRA
ticket hygiene and visibility on this document [1]. For now I focused on
JIRA to keep things simple, once we have that done we can do the github
part.
I would greatly appreciate the community's feedback and suggesti
Great, thanks for the feedback!
I will consolidate this discussion on a more concrete proposal and share
with the community for validation when I have it.
In the meantime if anyone has additional suggestions feel free to chime in.
Em qua., 24 de mar. de 2021 às 06:23, Benjamin Lerer
escreveu:
The proposal sounds good to me.
Thanks for looking into this problem Paulo.
Le mer. 24 mars 2021 à 09:05, Mick Semb Wever a écrit :
> >
> > What do you think about this alternative proposal?
> >
>
>
> Perfect! All my concerns are addressed, thanks for taking the time Paulo.
>
> Quite excited no
>
> What do you think about this alternative proposal?
>
Perfect! All my concerns are addressed, thanks for taking the time Paulo.
Quite excited now at the prospect of what this undertaking means for us.
> Though in practice, i'm wondering if the second phase should be done
carefully/manually the first couple of times to make sure we're getting it
right. I can think of a number of reasons where it might fail and am not
confident we'll anticipate everything.
Yeah I think it makes sense to start wit
but can't we make list maintenance via JIRA
> Automation [1] instead of requiring manual maintenance?
>
In principle i'm +1 to most of the two phase approaches you suggest. The
labelling of tickets and warning of a pending close/change is a good
approach. And I'm all for automating everything tha
Thanks for contributing to the discussion Mick.
I like the idea of having handy lists for "Triage", "Open", "Patch
Available", "Reviewed Once" to give more visibility and transparency to the
ticket triaging/review process, but can't we make list maintenance via JIRA
Automation [1] instead of requi
Throwing my thoughts out there on this.
> A much harder
> objective is to ensure that all "Patch Available" tickets are reviewed in a
> timely manner. However the current backlog of abandoned PA tickets is also
> large and we need to clean it to "start fresh" so the auto-close proposal
> would a
Thanks for your feedback Stefan!
I totally agree that an important reason for tickets being abandoned is
that committers don't have the bandwidth to review these tickets since they
are focusing on larger-impact tasks. Missing these contributions is very
bad for the project not only because we lose
Hi Paulo,
it might seem as me complaining but that is not the case here so just
hear me out please.
I think that the primary reason for tickets not being resolved / they
are abandoned / they are not worked on anymore is not the fact that
they are just "forgotten" but I believe that it is also bec
Hi everyone,
While triaging tickets for Google Summer of Code I went through dozens of
invalid and stale tickets on JIRA that were still open. In addition to
other issues, this makes it harder for new contributors to identify valid
tickets to work on. Ideally any ticket that was triaged by a contr
13 matches
Mail list logo
