Any more comments? Especially about the priorities/areas ? I am ok with just merging current changes and deferring it for later too, J.
On Mon, Oct 31, 2022 at 8:01 PM Oliveira, Niko <oniko...@amazon.com.invalid> wrote: > in the previous description we jumped straight to "labels" but > I believe (and that might be a good point to discuss with the current > triagers and committers) that labeling of priorities/etc. should be > somewhat "last" point of the triaging. We rarely (if at all) look at > those labels and IMHO there are many things triager can do long before > assigning the labels - closing an issue, @-mentioning others, > assigning "good first issue" label, asking for extra information (and > assigning "pending-response" label), converting to a discussion, > assigning next patchlevel release as a milestone - those are all the > actions that are very well embedded in our process and they will > guarantee an almost-automated follow-up and that the issue will be > eventually "acted upon". Those actions I mentioned are taken from > actual actions we've been taking in practice. > > These are exactly the types of things I've found myself doing while > triaging and I agree they are massively more helpful than just adding > labels alone. And speaking which, to your question, IMHO the labels are > best used for issue discovery and sorting. Folks can use them to find open > issues they'd like to work on in a particular area, which I think is > helpful, especially around providers. I find myself doing this, but I have > no data to prove others are also doing it. Overall, I don't feel too > strongly, if the majority opinion is that they're just adding noise, then > I'd be happy to vote to get rid of them. > > Cheers, > Niko > ------------------------------ > *From:* Jarek Potiuk <ja...@potiuk.com> > *Sent:* Saturday, October 29, 2022 5:26:13 AM > *To:* dev@airflow.apache.org > *Subject:* RE: [EXTERNAL][PROPOSAL] Clarifications of triage team role > including strenghtening importance of active triaging > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > Thanks to everyone who added their comments in > https://github.com/apache/airflow/pull/27262 - a lot of the comments > were super valuable and helpful and I re-worked the description a bit > based on them so you might want to take another look. > > I've modified and extended the description a bit to clarify few things: > > 1) I've added clearer role of GitHub Discussions - and added some > clearer criteria on where I believe issues should be converted to > discussions (I think this is a very important part of the issue > triaging process that basically very well filters out the real issues > from just discussions and it can make our issue triaging process much > more efficient > > 2) I also updated a "feature" issue template to clarify that the > potential scope of the feature should be "small" and that you need to > start a GiHub Discussion and likely create an AIP if you want to > propose a "big" feature. It might be loosely related, but I noticed we > do not even tell the users what "feature" issue scope should be. I > think it makes it easy for triagers to convert such a "feature" > request into a discussion if the user had a chance to read that they > should do that if unsure if the scope of the proposal is small enough > for "feature". Yes - they might not read it, but if we explain that in > the template, this is far less of a contention if we convert such an > issue in the discussion because the user was actually instructed to do > so themselves if unsure. > > 3) I added much clearer description of the actions that triagers can > take - in the previous description we jumped straight to "labels" but > I believe (and that might be a good point to discuss with the current > triagers and committers) that labeling of priorities/etc. should be > somewhat "last" point of the triaging. We rarely (if at all) look at > those labels and IMHO there are many things triager can do long before > assigning the labels - closing an issue, @-mentioning others, > assigning "good first issue" label, asking for extra information (and > assigning "pending-response" label), converting to a discussion, > assigning next patchlevel release as a milestone - those are all the > actions that are very well embedded in our process and they will > guarantee an almost-automated follow-up and that the issue will be > eventually "acted upon". Those actions I mentioned are taken from > actual actions we've been taking in practice. I (and others) have > been successfully doing this for years and this already helped a lot > in our issue handling process. What I put there merely explicitly > lists the actions we've been taking - it's nothing new or unexpected. > And putting them down is actually a good reference and if users are > asking why we are doing it, we can point them to that description. > > 4) **QUESTION**: I have however one area that I am not so sure about > and wanted to ask everyone for their opinion: > > I see a great value in assigning "good first issue" and "pending > response" labels. However, assigning the "kind", "priority", "area" > and "providers'', "affected_version" labels on issues is very > different. Those are more "statistics" labels, and I am not really > sure what to do with them as there is no clear benefit of assigning > them. I think they mostly create noise - because they are not even > close to being "correct" in - I think - vast majority of cases. I > think no-one actually uses them and they have very little chance of > being "correct" in our process. I think - since they were introduced, > they were never really used. And one can say - it's because we are not > setting them, but others (including myself) might say - yeah, because > it's next to impossible for people to be incentivised in setting them > correctly, because there are no clear benefits in doing it. > > My personal opinion on that is that we should simply drop them for our > process for issues after those years when we added it as an experiment > (and failed). Some of them (area: providers:) are great for PRs (they > are automatically assigned based on the files you change in the PR - > so they are mostly correct). But they bring really low value for > issues and if no-one actually takes care for them to be correct and > no-one uses them, I think we should drop them. Maybe we should work > out other ways to surface specific areas/priorities. The future > splitting providers to separate repos might be a good way - I will > soon get to that discussion finally, but not yet - however I think the > labelling of those does not really work. > > I do not have a super-strong opinion on that - we can leave them as > they are - but it always hurts me when I see a process that is defined > but not really followed. I see that usually as a sign of useless > red-tape and it also undermines the value of the rest of the process > that actually makes sense, so I am always in favour of as lean and > automated processes as possible. > > J. > > On Fri, Oct 28, 2022 at 12:44 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > I got some good feedback on the wording. Anyone else would like to chime > in? > > > > https://github.com/apache/airflow/pull/27262 > > > > J. > > > > On Tue, Oct 25, 2022 at 9:51 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > BTW. I spoke To Andrey (AKA @Taragolis) and I think (and Andrey > agrees) he would be a great member of the Triage team. > > > > > > PR: https://github.com/apache/airflow/pull/27278 > > > > > > On Tue, Oct 25, 2022 at 9:04 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > >> > > >> > Losing these folks is a bad experience for them but also for us > because we lost perhaps a great future contributor/committer/triager. > > >> > > >> Cannot agree more - that this is what I would really like to avoid ! > > >> Pretty much Every time we lose someone passionate who loves our > > >> product and would be a good contributor (even just small doc changes) > > >> we lose an opportunity to improve Airflow. > > >> > > >> There is one watchout though (and one that it is difficult to make > > >> judgment on) - some of those users we "lost" would be a huge energy > > >> drain on the community rather than improvement. I think - with such an > > >> influx of issues/questions/discussions/requests it's easy to get > > >> yourself too much dragged into useless conversations and it's a bit of > > >> skill to judge when it is better to lose someone rather than drag the > > >> conversation forward. > > >> > > >> Maybe it would be worth updating the docs with a comment about being > > >> assertive as a triager. > > >> > > >> J > > >> > > >> > > >> On Tue, Oct 25, 2022 at 7:56 PM Daniel Standish > > >> <daniel.stand...@astronomer.io.invalid> wrote: > > >> >> > > >> >> 3. I am also getting a true sense of just how overwhelming the > influx of Issues, PRs and Discussions is. I have come across several folks > who submitted PRs and never got feedback and then left the community. > Losing these folks is a bad experience for them but also for us because we > lost perhaps a great future contributor/committer/triager. We certainly > need all the help we can get on this front, for reviewing, providing > feedback and ultimately merging folks' contributions. > > >> > > > >> > Yeah that's very sad and a very important point. > > >> > >
