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