RFC 0006: Governance Amendment

[CheaterCodes]

Rendered Views:

• Governence RFC
• Technical Teams RFC

The following changes were made;

• Removal of technical teams
• Removal of technical leads
• Addition of team leads
• Generalization of team responsibilities
• Reformating of team creation RFC template
• Definition of sub teams
• Redefinition of the administrative board
• Change of admin election process
• Incomplete redefinition of processes

I'd like to see more done for standard processes, possible more in line with the Community Team RFC.

[TheGlitch76]

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"

[triphora]

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.

[TheGlitch76]

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.

[ToffeeMax]

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

[Akarys42]

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.

[Akarys42]

I've commented on the discrepancies that exist between the version suggested by this PR and what's actually applied currently

[Akarys42]

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]

So I heard ya like reviews.

It might be worth getting the policy work done on better defining what the admin board does first, before merging this - such policy work seems likely to require changes to this RFC as well.

[Akarys42]

@gdude2002 consider yourself re-requested for review :P

[gdude2002]

Have some more changes!

[Akarys42]

This PR is placed under FCP, lasting until April 25th.