@Kamil Breguła <kamil.breg...@polidea.com> - I believe we already base it on the experience of others (see the discussion before). I think in our case the will of people and their commitment to do so is far more important than any tools we would like to use (community over code). I think we should first let the people who want to do it try to do the task and we can introduce tools afterwards. No matter what, those people will need access. And then they can propose and choose any tool that make sense to them.
Paola, Elead,Vikram (and anyone who wants the triage permission) - please state your github users here, so I can create the ticket :) J. On Sun, Sep 13, 2020 at 9:40 PM Kamil Breguła <kamil.breg...@polidea.com> wrote: > Hello, > > I agree that it is worth considering changes in the way of handling > issues. Google has created a tool that can help us the issue and PR triage > for large open-source projects > https://github.com/google/triage-party > It was built from the Google Container DevEx team's experience contributing > to popular open-source projects, such as minikube, Skaffold, and Kaniko. Is > this something we should consider? > > How do other projects handle issues? Maybe we can base our process on the > experience of others. > > Best regards, > Kamil Breguła > > On Sun, Sep 13, 2020 at 9:09 PM Vikram Koka <vik...@astronomer.io> wrote: > > > Sounds good! > > > > In the meantime, I will draft up a proposal for the set of labels and > > milestones that we are using to eliminate duplication to factor in the > 2.0 > > timeline. > > > > > > On Sun, Sep 13, 2020 at 7:40 AM Jarek Potiuk <jarek.pot...@polidea.com> > > wrote: > > > > > Fantastic initiative! > > > > > > However, currently you have no way to give access to either of the > > > people involved to modify the labels or assign them to issues. > > > > > > But .... Wait for it ... ASF *JUST DAYS AGO* allowed the projects to > > assign > > > people to the "Triage" role I was talking about: > > > https://infra.apache.org/github-roles.html > > > > > > Can you please send me your github issues Vikram, Paola, Elad > > > > > > I will then create an INFRA ticket to add you? > > > > > > Unfortunately, there is no possibility yet to self-manage it, so it has > > to > > > be done through an INFRA ticket and it might take a few days to > process. > > > > > > Anyone else willing to join our Triage squad :) ? > > > > > > J. > > > > > > > > > On Sun, Sep 13, 2020 at 2:31 AM Vikram Koka <vik...@astronomer.io> > > wrote: > > > > > > > I agree. > > > > > > > > Paola and Elad, I would like to help on this one as well. Let's get > > > > together and nail this. > > > > > > > > I spent a couple of hours looking through the open Github issues > > earlier > > > > today to look for some patterns. > > > > Currently, we have 576 open and "not invalid" issues. > > > > Out of these, we have around: > > > > - 270 open feature requests, which span the full gamut of > > functionality, > > > > from user visible to internal CI process. > > > > - 220 bugs including some going back to March as noted by Tomasz. > There > > > > seem to be a fair number of these which need some categorization at > > > least. > > > > - 70 docs issues. These are categorized sometimes as "area:docs" and > > at > > > > other times as "kind:documentation". > > > > - 50 already assigned to milestones: Either Airflow 2.0.0 or > 10.10.13 > > > > - 80 provider related issues > > > > > > > > There was a set of 6, created in March 2019 which was rather > peculiarly > > > > categorized as "Waiting for AIP". > > > > > > > > These don't all add up the total, since there are issues which are > > > > categorized (correctly) in multiple labels. However, we do seem to > have > > > > proliferation of labels which would be useful to cleanup. > > > > > > > > Overall, I do think some time spent on documenting the use of labels, > > > then > > > > categorizing and cleaning up the issues would be very useful. > > > > > > > > Happy to help take care of this. Let's do it. > > > > > > > > Vikram > > > > > > > > > > > > On Fri, Sep 11, 2020 at 12:00 PM Jarek Potiuk < > > jarek.pot...@polidea.com> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > On Fri, Sep 11, 2020 at 7:12 PM Kaxil Naik <kaxiln...@gmail.com> > > > wrote: > > > > > > > > > > > Yeah I agree and looks like Paola and Elad have already > volunteered > > > to > > > > > help > > > > > > triage. > > > > > > > > > > > > Regards, > > > > > > Kaxil > > > > > > > > > > > > On Fri, Sep 11, 2020, 18:09 Tomasz Urbaszek < > turbas...@apache.org> > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > The main reason I suggested the stale bot was the lack of any > > > > > > > widespread prioritization/reviewing of issues which results in > > big > > > > > > > pile of never addresses issues. > > > > > > > > > > > > > > I think that triage access is a better answer to this problem > as > > > > > > > engaging more people will help us all. I'm +1 for that. > > > > > > > > > > > > > > Cheers, > > > > > > > Tomek > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 11, 2020 at 5:00 PM Paola Peraza Calderon > > > > > > > <pa...@astronomer.io> wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Paola here from Astronomer. I've been working at Astro since > > our > > > > > early > > > > > > > days in both Customer and Product-centric roles and have of > > course > > > > been > > > > > > > closely following all-things Airflow for a long time. > > > > > > > > > > > > > > > > I happened to read this conversation around GH Issue > management > > > and > > > > > > > figure I can step up to volunteer as someone familiar with the > > > > project > > > > > + > > > > > > > Product Ops principles, if that'd be helpful. I could always > > start > > > > by: > > > > > > > > > > > > > > > > - Cleaning up/commenting on duplicate issues (or close given > > the > > > > > right > > > > > > > permissions) > > > > > > > > - Commenting on stale issues and investigate whether they're > > > still > > > > a > > > > > > > problem or already addressed > > > > > > > > - Asking questions as needed if issues need clarification or > > > > > additional > > > > > > > scoping > > > > > > > > > > > > > > > > If this would be helpful, I'm more than happy to get involved > > and > > > > > pick > > > > > > > at these over time. It'll likely be a journey that never ends, > > but > > > I > > > > > > think > > > > > > > a compelling need to keep the community momentum going. Let me > > > know - > > > > > and > > > > > > > great to meet you all. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Paola > > > > > > > > > > > > > > > > On 2020/09/10 11:56:22, Tomasz Urbaszek < > turbas...@apache.org> > > > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > Currently, we have about 582 open issues on Github. The > > oldest > > > > > opened > > > > > > > > > in March. Do you think we should consider using stale bot > as > > we > > > > do > > > > > > for > > > > > > > > > PRs? > > > > > > > > > > > > > > > > > > I don't think that issue that is open since March is "so > > > > important" > > > > > > to > > > > > > > > > keep it still open. This would also automate the process of > > > > > verifying > > > > > > > > > the issue (the author will be notified and asked for an > > > update). > > > > If > > > > > > > > > the issue is something that we want to keep open we should > be > > > > able > > > > > to > > > > > > > > > use the "pinned" label. > > > > > > > > > > > > > > > > > > Other projects use it and I don't see anything wrong with > > it. I > > > > > would > > > > > > > > > say that 30d is a good period for keeping an issue open. > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > Bests, > > > > > > > > > Tomek > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Jarek Potiuk > > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > > > > > > > > > > > -- > > > > > > Jarek Potiuk > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > M: +48 660 796 129 <+48660796129> > > > [image: Polidea] <https://www.polidea.com/> > > > > > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
