Closed CheaterCodes closed 1 year ago
We currently have a subteam that we don't consider full Quilt Developers (Mappings Triage). They don't have the Quilt Developer role, or (as far as i'm aware) access to our internal dev chat or meetings.
We should clearly define this relationship, or make Mappings Triage members also "Quilt Developers"
Does this address anything regarding the addition of staff? I could find removal of staff, but nothing about addition. On another note, I think that the Community Team RFC (0007) could be generalised a bit more in alignment with RFC 6. For example, the keyholder is specified in the community team RFC for some reason, and the general idea of our vote system is rather similar to that specified here, just with some changed specifics.
Addition of staff is very specific to the team, and isn't defined for the organization as a whole on purpose IMO.
Most developer teams "elect" members by a quick voice vote (@Team is it ok if we add John Doe
in #dev-chat
), but some can be joined by anyone already on a parent team (QSL subteams), or are appointed by a parent team instead of self-managing (Mappings Triage).
The Community Team has a completely different, well-defined process for addition of staff that is intentionally long and difficult.
I am generally content with the changes put forward by this PR. There would need to be a review of the core documents to make sure this does not cause any clashes -- but it sees you have done this to a good extent.
I do think this would be a fantastic chance to also clarify the way that PRs are merged overall -- which is outlined in RFC-0001 and make it crystal clear. As sometimes I cannot even recall the general method: Possibly specifying the team responsible. In this case: this would be a team wide approval
This PR has been going for about a year and a half now, and has virtually been in effect for a year already. Team Leads are already implemented, two Admin Board votes have been performed according to this RFC, and probably some other things I'm not remembering.
I would suggest to do one last round of fixing, and put this RFC into FCP. It seems clear so far there are no fundamental issues with it, and the bikeshed nightmare it has ended up in is quite detrimental to the project.
All outstanding comments on this RFC have been resolved. Sadly, I cannot actually mark them as resolved due to GitHub limitations.
My plan is to request an FCP for this PR this weekend.
@gdude2002 consider yourself re-requested for review :P
This PR is placed under FCP, lasting until April 25th.
Rendered Views:
The following changes were made;
I'd like to see more done for standard processes, possible more in line with the Community Team RFC.