Skip to content

RFC 0055: Mappings team restructure #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

RFC 0055: Mappings team restructure #55

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cc29565
RFC 55: Mappings team restructure
IotaBread Apr 23, 2022
3f62046
Apply suggestions from code review
IotaBread Apr 23, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions structure/0055-mappings-team.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# Mappings team restructure

## Summary

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

the proposed structure for the top-level team and those subteams.


## Motivation

The scope of the repositories maintained by the main mappings team is very big,
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.



## Explanation

The mappings team would be split into three sub-teams: Quilt Mappings, Mappings
Tooling, and the existing Mappings Triage sub-team.

The Mappings Triage team is only in charge of reviewing mappings submitted to
QM, ensuring their quality and making sure they stick to the conventions.
This team only has triage access to the QM repository.

The Quilt Mappings team would be in charge of maintaining QM, and also shares
the responsibilities of the triage team. The main difference between the triage
team and the QM team is their access level to the repository, meaning only QM
members can merge PRs or push commits directly.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- Currently, all of the responsabilities mentioned are already handled by the
mappings team or the triage team.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to make sense as a point in this section.



## Unresolved Questions

- 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?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd remove as here. Also, this is a discussion that needs to happen before this RFC is merged, in my opinion.



[RFC 18]: 0018-technical-teams.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably wanted to add a References header here.

[QM]: https://github.com/QuiltMC/quilt-mappings
[Hasher]: https://github.com/QuiltMC/mappings-hasher
[Enigma]: https://github.com/QuiltMC/enigma
[TR]: https://github.com/QuiltMC/tiny-remapper