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.
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
RFC 35: Sub teams #35
Conversation
Creation and disbandment of sub teams must be agreed on by the core team. This RFC doesn’t propose to create any yet, since ideas for sub teams will be discussed after this RFC is accepted. | ||
|
||
The sub teams that will most strengthen our work will be defined by interest area and involve people with varied skills (e.g. design, marketing, community management) and viewpoints (e.g. designers, experts, stakeholders). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a clear tag/label for each sub-team for Github issues, either using the existing ones or creating new ones (eg. team:accessibility
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment we use GitHub teams for this, for example @wagtail/documentation
within comments. I imagine this could be the same for sub-teams?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think issue labels for areas of work like Accessibility should remain as they are, so their naming is consistent with AoWs that don't have a sub-team. I think all issues with an AoW label that matches a sub team name can be considered as owned by that sub team (and if this isn't the case, one of them should be renamed to make this clear).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tweaked in 50785d1
- They also have more time to write RFCs -- sorry this RFC isn’t as detailed as theirs! | ||
- The Rust project has many components to it (compiler, libs, dev tools) where as Wagtail is just one | ||
- Because of this, the Rust core team is made up of only sub team leaders and they are still able to have a development focused core team. I am not suggesting that we change the core team membership of Wagtail. | ||
- They make most of their decisions through an RFC process, which we don’t do so much so I haven’t included any mention of RFCs here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as an aside, I like that Rust has the 'alumni' team - this appears to be a list of those who were on a team or core team in the past. Nice way to say thanks to those with previous core contributions.
Not looking at leaving anytime soon :) but just flagging this as a great idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great suggestion added a note to that effect
Co-Authored-By: kaedroho <karl@kaed.uk>
Co-Authored-By: kaedroho <karl@kaed.uk>
text/035-sub-teams.md
Outdated
|
||
## The sub teams | ||
|
||
Creation and disbandment of sub teams must be agreed on by the core team. This RFC doesn’t propose to create any yet, since ideas for sub teams will be discussed after this RFC is accepted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creation and disbandment of sub teams must be agreed on by the core team
This feels a bit strong. Are there any circumstances in which we would refuse the creation of a sub-team?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more about making sure new sub teams are raised in team meetings, so if there is any overlap between teams this can be discussed and worked out. I don't think it's likely any team creation would be outright blocked though. Maybe this bit should be reworded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If no one from the core team can participate in a sub team, then is it really a sub team? (sub of what?) I guess it's also for the core team to decide the need of a sub team then, but would be nice if core team is in consensus about such decisions 💯
Creation and disbandment of sub teams must be agreed on by the core team. This RFC doesn’t propose to create any yet, since ideas for sub teams will be discussed after this RFC is accepted. | |
Sub teams are delegated by the core team and a participating core team member is assigned. This RFC doesn’t propose to create any yet, since ideas for sub teams will be discussed after this RFC is accepted. |
I also get that you would like to discuss this RFC without having the discussion of the sub teams themselves. That's a good ideal -- but maybe within this proposal, you should aim to look at choices of stability vs. change, so you don't have tonnes of subsequent recurring discussions about creating sub teams, re-structuring them etc. You know, the CIA Sabotage Manual :)
Discussed in team meeting. All for it, so merging this. Thank you all for your input! |
Rendered