RFC 0055: Mappings team restructure #55
Conversation
There was a problem hiding this comment.
- Who should be part of the top-level team?
I don't really think there should be anyone on the top level, except maybe a Technical Lead per #47. Rather that this should just be split up into the three different responsibilities.
- Should triage team members be considered as Quilt Developers?
Perhaps I'm biased as a triage team member, but I would say yes. Cheater made a good point in #mappings-internal in saying that QM Triage is very similar to QSL sub-teams, so really there shouldn't be a second class of developers for only QM triage.
Co-authored-by: Emma C. Pointer-Null <[email protected]>
There was a problem hiding this comment.
I've suggested a number of wording changes here. I'd also like to point out a few things in general:
- Team names should be capitalized (
Mappings Team), and you need to use precisely the same terminology for each team throughout the document - Don't abbreviate team names (
QM Team) when those abbreviations aren't defined earlier (formally or informally), or when they conflict with other abbreviations (QMto mean the Quilt Mappings project) - This is a formal document, and it's important to maintain writing consistency:
- There's a lot of mixing of tenses: pretty much everything in this document should be present or future tense, but not a mixture
- The language used is often not assertive enough: "can", "may", "could" vs "will", "would"
- When writing lists, the punctuation at the end of list items should be consistent throughout the list - have it or don't have it, but don't mix
- This is a Markdown document, and you do not need to wrap lines; your margin is set especially short, and this makes reviewing and adding suggestions to review comments rather annoying - instead, please use an editor that soft-wraps at the margin
I think that's about it for now. Thanks for writing this!
|
|
||
| The mappings team was originally created in [RFC 18][RFC18], but has since | ||
| evolved: a triage team was created for [Quilt Mappings][QM], and the need to | ||
| split the mappings team into smaller subteams has appeared. This RFC describes |
There was a problem hiding this comment.
This wording needs some work.
but our needs have changed since then - a
[Quilt Mappings][QM] triage team was created,
and it became necessary to split the mappings team
into smaller subteams.
| from the main Quilt Mappings repository, to all of the toolchain used and | ||
| related to it. By splitting the mappings team, its members can be assigned to | ||
| projects more specifically, and review requests in PRs would only reach to the | ||
| repository maintainers rather than the whole team. |
There was a problem hiding this comment.
More wording work needed here.
The Mappings Team maintains numerous projects - from the
main Quilt Mappings repository, to all the related tooling. This
is quite a large development surface, and splitting the team into
smaller subteams would ensure that tasks will only be assigned
to those that they're relevant to, preventing unnecessary noise
generated by notifications going to people that don't need them.
|
|
||
| The Mappings Tooling team would be in charge of maintaining all of the mappings | ||
| toolchain (ie. [Mappings Hasher][Hasher], [Enigma], [Tiny Remapper][TR], etc.), | ||
| and subsequently for reviewing PRs to these repositories. |
There was a problem hiding this comment.
This section appears to have mixed tenses, which makes reading harder than it should be. Additionally, the terminology is inconsistent - is it named Mappings Team or Quilt Mappings Team?
I'd also avoid abbreviating the team name to QM Team to avoid confusion with the QM project, which has the same abbreviation.
Additionally, all team names should be capitalized - Mappings Team, not mappings team
| ## Drawbacks | ||
|
|
||
| Having different people maintain the toolchain and QM could mean more | ||
| bureaucracy to make changes in both QM and the toolchain at the same time. |
There was a problem hiding this comment.
You don't explain how this is a drawback.
| ## Rationale and Alternatives | ||
|
|
||
| - Having multiple sub-teams instead of one big team can make assigning people | ||
| to tasks easier, who manages each project clearer |
There was a problem hiding this comment.
I'd clarify this a little by saying and would help clarify who is in charge of each project. Also, I'd avoid passive language like can, and replace it with more assertive language like would.
| to tasks easier, who manages each project clearer | ||
| - Even splitting the mappings team into QM and tooling, the number of projects | ||
| handled by the tooling team is very broad. The tooling team could be split | ||
| into more sub-teams |
There was a problem hiding this comment.
The wording here is confusing. How about something like this?
While splitting the Mappings Team into the Quilt Mappings and
Mappings Tooling teams would help to split the workload, there
would still be a large number of projects assigned to the Mappings
Tooling Team - but this split would allow us to further split the Mappings
Tooling team into further sub-teams
However, this begs the question - why is this subdivision not part of this RFC as well, if you're already thinking about it?
| handled by the tooling team is very broad. The tooling team could be split | ||
| into more sub-teams | ||
| - Most of the projects are in charge of one or two people, the sub-teams | ||
| wouldn't be bigger than 2 people in most cases. |
There was a problem hiding this comment.
This wording doesn't make sense. Perhaps you wanted something more like this?
In this situation, most projects belonging to sub-teams would be run
by one or two people, meaning each sub-team would be quite small
| - Most of the projects are in charge of one or two people, the sub-teams | ||
| wouldn't be bigger than 2 people in most cases. | ||
| - Currently, all of the responsabilities mentioned are already handled by the | ||
| mappings team or the triage team. |
There was a problem hiding this comment.
This doesn't seem to make sense as a point in this section.
| - Who should be part of the top-level team? | ||
| - What permissions should top-level team members have in QM, and the toolchain | ||
| repositories? | ||
| - Should triage team members be considered as Quilt Developers? |
There was a problem hiding this comment.
I'd remove as here. Also, this is a discussion that needs to happen before this RFC is merged, in my opinion.
| - Should triage team members be considered as Quilt Developers? | ||
|
|
||
|
|
||
| [RFC 18]: 0018-technical-teams.md |
There was a problem hiding this comment.
You probably wanted to add a References header here.
Akarys42
changed the title
LambdAurora
added
the
structure
This RFC aims to define the new mappings team structure
Rendered view