Require Maintainers to be Triagers #347
Conversation
|
I understand the idea here, but right now, (and going forward) Triagers are going to be a very different group of people. The requirements for the knowledge submissions will change the...drive to be triagers now, and with that overhead and being part of other portions of this project it maybe overwhelming. |
|
@jjasghar this isn't in reference to the Taxonomy Triagers, it's to the Contributor Role of Triagers defined here: https://github.com/instructlab/community/blob/main/CONTRIBUTOR_ROLES.md#triager |
|
Oh! Sorry miss understood. |
|
@jjasghar No worries! It's an unfortunate collision of terms 😄 |
The project is looking for ways to improve community relationships, and one of the suggestions is to require maintainers to share triager responsibilities to provide timely and useful feedback to contributors on their issues and pull requests. The proposal is to assume privileges and responsibilities and membership is monotonically expanding so that: - all triagers are members (already the case); - all maintainers are triagers (this proposal). Or if these were python sets, then... ;) ``` Contributor <= Member <= Triager <= Maintainer ``` Context: we are considering automatic assignment of a number of Triagers to every new pull request, and it's important that this burden is shared by all seasoned members, incl. maintainers. Note: once this is approved, someone should walk through the list of current Maintainers and add them to Triagers groups for appropriate repos. Alternatively, Maintainers groups can be converted into nested groups, see: https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#nested-teams Signed-off-by: Ihar Hrachyshka <[email protected]>
booxter
force-pushed
the
maintainers-are-triagers
branch
from
1e80918
to
087ef0f
Compare
There was a problem hiding this comment.
This is a "community" roles doc and not just CLI, so...
taxonomy is actually using triagers and needs that distinction, where CLI hasn't really been doing that. I think the change here breaks their model (a little?) just to try to address our attempt at a better way. That's not good in "community".
So I think:
1 - If this change is CLI only, then add these notes saying that's the case.
2 - If we are actually going to put folks in both maintainers and triagers then this doc change is pretty much not needed. If I'm in both, I'm expected to perform both roles. `nuff said, right? But sure... some note saying we intend to have all CLI maintainers in both would be worth noting right now for clarity.
Lastly, I support the re-group thinking effort to make us better and put all maintainers in triagers (either explicitly or perhaps if it is implied for now that could work too)... but I think long-term it is likely that some maintainers might have more specific roles (e.g. maybe a maintainer that is a security specialist) and so maybe all would not be best suited to be tagged as a generic triager. Not a problem in the short-term, but maybe others agree and have thoughts on how that affects this proposal.
This is not for CLI only - triagers is a defined org-level team role and also it is something that exists for the CLI repo as well as several others
Right now it's ambiguous - I think it's worth defining it one way or the other.
Good point! |
|
I would recommend this PR be brought up as an agenda item in the next Community Mtg to discuss to create awareness and get more input from the community. |
| @@ -115,9 +115,13 @@ Maintainers will vote publicly on the issue, expressing their support via a GitH | |||
|
|
|||
| After a [decision has been made](https://github.com/instructlab/community/blob/main/governance.md#decision-making-at-the-instructlab-org-level), a Maintainer will create a PR to add you in the [MAINTAINER file](https://github.com/instructlab/community/blob/main/MAINTAINERS.md) within three weeks. | |||
|
|
|||
| All Maintainers are Triagers. If a candidate is not a Triager at the time of the nomination, they should be added to both Triagers and Maintainers teams. | |||
There was a problem hiding this comment.
Is this saying that you can nominate a user to be a maintainer without them serving as a triager? Does this circumvent the contributor ladder?
There was a problem hiding this comment.
I agree the ladder should be - at least as a rule - followed in steps. But.
AFAIU nothing in the ladder or this document forbids this from happening now. See the line 102 - the only thing required is being a Member for a month. If we think a Triager requirement (time-bound or a general one) is needed, we can update the document to reflect it accordingly, but that is not the goal of this PR. The goal here is to make sure that Maintainers are always Triagers.
The project is looking for ways to improve community relationships, and one of the suggestions is to require maintainers to share triager responsibilities to provide timely and useful feedback to contributors on their issues and pull requests.
The proposal is to assume privileges and responsibilities and membership is monotonically expanding so that:
Or if these were python sets, then... ;)
Context: we are considering automatic assignment of a number of Triagers to every new pull request, and it's important that this burden is shared by all seasoned members, incl. maintainers.
Note: once this is approved, someone should walk through the list of current Maintainers and add them to Triagers groups for appropriate repos. Alternatively, Maintainers groups can be converted into nested groups, see:
https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#nested-teams