potiuk commented on code in PR #27262: URL: https://github.com/apache/airflow/pull/27262#discussion_r1008687543
########## ISSUE_TRIAGE_PROCESS.rst: ########## @@ -30,6 +30,52 @@ to fix an issue or make an enhancement, without needing to open an issue first. This is intended to make it as easy as possible to contribute to the project. +Another important part of our Issue reporting process are also Github Discussions. +Issues should represent clear feature requests or bugs which can/should be either implemented or fixed. +Users are encouraged to open Discussions rather than Issues if there are no clear, reproducible +steps, or when they have troubleshooting problems. + +Responding to issues/discussions (relatively) quickly +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +It is vital to provide rather quick feedback to Issues and Discussions opened by our users, so that they +feel listened to rather than ignored. Even if the response is "we are not going to work on it because ...", +or "converting this issue to discussion because ..." or "closing because it is a duplicate of #xxx", it is +far more welcoming than leaving issues and discussions unanswered. Sometimes issues and discussions are +answered by other users (and this is cool) but if an issue/discussion is not responded to for a few days or +weeks, this gives an impression that the user reporting it is ignored, which creates an impression of a +non-welcoming project. + +We strive to provide relatively quick responses to all such issues and discussions. Users should exercise +patience while waiting for those (knowing that people might be busy, on vacations etc.) however they should +not wait weeks until someone looks at their issues. + +Issue Triage team +'''''''''''''''''' + +While many of the issues can be responded to by other users and committers, the committer team is not +big enough to handle all such requests and sometimes they are busy with implementing important huge features +that require focusing for extended periods of time on them. Therefore, we are inviting people who are +regularly contributing and helping other users and shown their deep interest in the project to the +triage team. The current list of triage team members is in `the .asf.yaml <.asf.yaml>`_ file in the +``collaborators`` section. Review Comment: Yeah. Good point. I clarified that this can be both - by invitation and users can ask for it - but I also added point that (and this is very consistent with our committer's, PMC requirements - you have to do something that is "expected" at a given "level" before you are "formally" invited. As everything in ASF - this is based on merit. You need to show that you are already doing something (i.e. almost committer's or PMC's "things") before you are invited to be committer/PMC - same as triager. You need to comment and help users regularly before you become a member of triage team. In Airflow (and all other ASF project) we do not give priviledges to people based on "promises" that they will do something but on the base on them "already doing something". That's how merit is defined as an important part of the Apache Way: https://www.apache.org/theapacheway/ - "Earned authority" or "merit". If you are asking to become a member of the triage team, you need to show you have done a lot of that already (pretty much everything except assigning labels/milestones/closing issues can be done by regular users - commenting, mentioning others, assessing validity of the issues can be done by everyone. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
