Add Triage and Review team charter.#79
Conversation
nessita
left a comment
There was a problem hiding this comment.
Thank you for working on this!
|
|
||
| ## Scope of responsibilities | ||
|
|
||
| The objective of the team is to help spread work beyond the [Mergers](https://www.djangoproject.com/foundation/teams/#mergers-team) and into the wider contributor community. The team has elevated permissions in Trac and GitHub to allow them to triage and maintain tickets and pull requests. A pull request approval from a member of the Triage and Review team allows a Merger to merge a minor change that they, themselves have primarily authored. |
There was a problem hiding this comment.
Just a few notes on this paragraph, maybe no change is needed but I figured I'd mention this:
- anyone can triage tickets in Trac as long as they login, a member of the R&T team has no extra privileges there (they can add people as
ccin a ticket which a regular user can't, but that's all) - for GH the extra perm for a R&T member is to add labels to a PR.
There was a problem hiding this comment.
I think the broad statement of "The team has elevated permissions in Trac and GitHub" covers both of those cases (being able to CC someone is an elevated permission). I'm not sure we should list the permissions explicitly in this document. The benefit of not having the explicit permissions listed is that we're more flexible if there are permission changes in the future.
There was a problem hiding this comment.
Agree with Tim, the team can also close duplicate/nuisance PRs, too, which is great, but doesn't need to go in the charter.
priyapahwa
left a comment
There was a problem hiding this comment.
Appreciate the efforts that have gone into drafting these charters. Thanks a lot, Tim 🙌
| Anyone actively engaging in discussions on GitHub, the Forum and/or the new-features repository will be eligible to join the Triage and Review Team. | ||
|
|
||
| The membership will operate as follows: | ||
| - Any existing member can invite an active contributor to join the team |
There was a problem hiding this comment.
Although this is already captured on the wiki (“Once there is agreement from the team that the new member is suitable to join”), restating it in the charter that team consensus is required before member invitations would improve clarity. It would also be useful to specify the approval threshold or percentage required for acceptance.
There was a problem hiding this comment.
| - Any existing member can invite an active contributor to join the team | |
| - Any existing member can invite an active contributor to join the team with a second from an existing team member |
Consensus is defined as +2 in the team's wiki. I'm fine adding that here, but I suspect that's not how things work. @jacobtylerwalls I think you've added people recently, can you clarify this when you have time please?
There was a problem hiding this comment.
I can't locate which part of the wiki you mean.
In my experience, nominations have been so careful that I've never seen a dissent. I've seen one set of nominations get stalled because it had several candidates, so the +1s rolled in separately. I'm actually going to resurrect that thread now.
It's more like "any objections?"
There was a problem hiding this comment.
Sorry, that wasn't so clear. Yes I think the proposed "second" is fine.
There was a problem hiding this comment.
|
|
||
| There is no budget, but requests can be made to the Board as needs arise. | ||
|
|
||
| Django has some professional PyCharm licenses that we can share with our contributors. Team members are eligible to receive these. |
There was a problem hiding this comment.
Are these licenses meant to be lifetime or time-limited? Both ways, adding a brief note that they are dependent on availability or subject to change would help set expectations, since access may not be guaranteed indefinitely.
Additionally, "... share with our contributors" - here, contributors refer to the members of WG, right? We can mention that too explicitly.
There was a problem hiding this comment.
Are these licenses meant to be lifetime or time-limited? Both ways, adding a brief note that they are dependent on availability or subject to change would help set expectations, since access may not be guaranteed indefinitely.
Can those details be handled by the team and/or board itself? I don't know if the charter needs to capture that level of detail.
Additionally, "... share with our contributors" - here, contributors refer to the members of WG, right? We can mention that too explicitly.
No, I didn't meant that. Contributors is meant to be interpreted in a general sense beyond this team. Your concern regarding members of the WG should be covered by the following sentence: "Team members are eligible to receive these."
There was a problem hiding this comment.
Whoops, I didn't answer your question! Sorry. I don't know the duration of those licenses.
There was a problem hiding this comment.
PyCharm renews them for "some time" based on goodwill; let's just keep it vague.
There was a problem hiding this comment.
Alright, thanks for the info.
There was a problem hiding this comment.
@priyapahwa did you want to see changes here still? Not sure where we landed based on your response.
There was a problem hiding this comment.
I think we’re good to leave it as-is. Thanks for checking!
Co-authored-by: Priya <pahwa.priya19@gmail.com>
Co-authored-by: Priya <pahwa.priya19@gmail.com>
|
Updated the member list (pardon me if I shouldn't have). Is it a frozen list, or should we just link to the "live" version: https://www.djangoproject.com/foundation/teams/#triage-review-team |
jefftriplett
left a comment
There was a problem hiding this comment.
Great work! This charter has been approved by the board. We appreciate the time, care, and effort that went into developing it, and understand that changes may still occur before it is finalized. We also plan to follow up with a recommendation for a chair or co-chair, even if the role primarily serves as a central point of contact for the board.
This is part of the DSF's effort to standarize the technical teams (#28)
This is largely a reproduction of the documented processes in DEP 10. However there are some small changes: