dsf-working-groups
dsf-working-groups copied to clipboard
Question for the board: Which teams ought to become Working Groups?
I was reviewing this page: https://www.djangoproject.com/foundation/teams/ and was wondering if some of these teams would better future proofed by becoming working groups to document what they do on behalf of the board, what they are responsible for an what membership requirements are (most are going to be invitation only)
Or am I way off the mark?
Sarah A mentioned to me that these teams are more for the Steering Council to look after. Perhaps a parallel repo can be setup by the new SC when it's elected
@nanorepublica good question. The main point of working groups is to delegate the board’s powers to other volunteers. I’m not clear if those teams would have enough that’s fundamentally delegated by the board, to justify being re-chartered as working groups. The two committees on the other hand have been re-chartered.
Re documentation of what the teams do / responsibilities / membership requirements, that definitely feels worth improving to me even if the teams weren’t working groups? Should we create that as a "content improvement issue" for the website?
I'd say the trigger to re-charter as a working group probably ought to be if either of these two things happen:
- The team wants to start making decisions/taking action in ways that have traditionally been Board responsibilities. For example, we can imagine the infrastructure team wanting to, I dunno, take over management of the DSF's Google Workspace. (Poor example, I think, but hopefully good enough to get the drift).
- The team wants a budget and direct spending authority (instead of always needing board approval to spend money)
I suspect the second will be the most common use-case for a less-formal volunteer team re-chartering as a working group.
I'm looking at this with @tim-schilling from the Teams page:
- Accessibility
- Mergers
- Ops team
- Releasers
- Security team
- Steering Council (I'm not sure this does or does not make sense to join the teams model)
- Translators (is this a team?)
- Triage & review team
I think this will be resolved by #36, which outlines a plan to move working groups and teams all in this one repo. So the answer is – teams would keep being "teams", and would all have a clearer charter, with some nuances acknowledging the different requirements compared to working groups.
#36 is merged so I think this can now be closed. Feel free to reopen or open another issue if needed – I believe we intend to move more teams to this new structure in the future, but it’s something that needs careful thought team-by-team, and in lots of cases ownership needs to be close to the current team members.