Try   HackMD

Theory and Practice of Working Groups

Note: not all charters have been drafted! This information is prepared with additional needs for:

  • Working Group charter (example drafted) - in template repository
  • Meeting Notes template - in template repository
  • Working Group audit
  • Working Group infrastructure needs (i.e. creating own repository)
  • Shutting down working group documentation
  • Community Call schedule

Working Groups

Within The Turing Way, working groups are smaller groups of people that work together on a focus topic, theme, or type of work. Many communities within the wider open source ecosystem have establised working groups (i.e. Project Jupyter, Kubernetes, Eclipse Foundation, Sustain OSS, amongst others), and working groups have been used as an organisational structure across many institutions and government bodies.

Historically, roles in the The Turing Way working groups have been informal: after existing streams of work had been identified, participants in working groups have been encouraged to develop ways of working that align with their needs. However, in some cases this has lead to the tyranny of structurelessness, where lack of structure has lead to uncertainty of roles and responsibilities, and ultimately, stagnation of some existing groups.

We believe that everyone in The Turing Way community has expertise to share, and thereby anyone can join, and/or be a part of a working group. While there are a few more more requirements for community members to create a working group, this is primarily to ensure to there is sufficient support for their efforts, and to ensure that they are aligned with the aims of the project, and that there is enough critical mass to warrant a working group as opposed to another organisational structure.

While joining a working group is not mandatory to join The Turing Way community (meaning, all are welcome to get involved in The Turing Way project without getting involved with a working group), joining a working group provides an opportunity to do focused tasks in a specific area. For informal groups that are interested in formalising their work, developing a working group offers an opportunity for groups to benefit from formalised support from the core staff delivery team (employees of the Alan Turing Institute that are deployed to work on and with The Turing Way), as well as formal recognition of their efforts within the community.

Within The Turing Way, working groups have historically been established with the help of the Community Manager, as a means of (1) formalising already existing and ongoing work within the community and/or (2) enabling work that addresses observed and documented needs of the project and community. This was primarily the case in 2022 and 2023.

However, this document and enclosed templates hopes to make it possible for interested members of the community to self-organise, incubate, maintain, and/or eventually close a working group. This document, as is the case with The Turing Way guides themselves aims to be a living document, updated as the community and its governance evolves.

Guidelines

All working groups, teams, and people within The Turing Way are responsible for adherring to The Turing Way Code of Conduct and our (upcoming) Accessibility Policy, both in working group organisation and meeting facilitation.

That is to say, every working group is responsible for establishing structures that that are:

  1. Open & Transparent for others to learn about, and join in on;
  2. Inclusive for all kinds of people and kinds of expertise;
  3. Accessible to join and participate in.

Within a community that prioritises documentation, each working group has a responsibility to hold themselves accountable to document their ways of working and ongoing projects, as documented below in 'Roles & Responsibilities'.

Roles

These roles suggested below are not meant to be permanent roles (i.e. a chair should not be a permanent appointee), but rather a guiding structure that working groups may build off of, expand, remix, and reuse for their own purposes. They are suggested not in order to create hierarchy within a working group, but in order to enable the smooth operation and maintenance of the collective team.

At least 3 to 4 people are required to create a working group. These roles may be temporarily appointments, but one person may occupy multiple roles. However, one person should not chair multiple working groups, in order to enable diffusion of responsibilities as well as prevent over-extension of individuals within the community. People are allowed to join any number of working groups.

  • Chair and co-chairs: These person(s) are responsible for the creation and continuation of a working group. They play the role of the facilitator of the group, and are responsible for organising and chairing meetings, distributing responsibilities, and ensuring the broader accountability of the assembled group. While this role may be occupied by multiple people, it is important to establish how each person upholds the responsibilities of a chair in an equitable way. This person will serve as the "Leadership Council Liason", and will be obliged to participate in leadership council meetings, and represent the working group in wider governance meeting spaces. They will be responsible for relaying feedback, announcements, and discussions from the leadership council to the working group.
  • Secretary: This person is responsible for ensuring the logistical reporting of the group. They are responsible for uploading meeting notes, ensuring that time-keeping is set in meetings, and that records of the group's activities are transparent, open, and accessible for others to access. For example, if the duties of the chair are distributed across multiple people, the secretary is responsible for documenting this format in the working group's repository.
  • Turing Staff Delivery Team Contact: While working groups should be able to operate with autonomy in most decisions that apply to their work, sometimes they may require help from the TTW core staff delivery team in order to enable their operations, and/or support the incubation of the group. Each working group should have an assigned contact from the staff delivery team, most likely either the project Community Manager or Project Manager.
  • Member: Any Turing Way community member may join a working group without restriction, and without taking on a leadership role.

Responsibilities

All working groups within the community have the responsibility to adhere to these three practices, as they relate to:

  1. Reciprocity within and towards the broader Turing Way community;
  2. Open reporting of practices and ways of working;
  3. Transparent decision-making within the working group;

Reciprocity

All working groups within the Turing Way have a responsibility to facilitate a reciprocal relationship with the wider community, as they represent a sustained engagement by community members on a topic or subject.

This engagement can take a variety of forms, and can look like:

  • Using TTW Community Calls like the Collaboration Cafe for working group meetings, discussions, and/or ongoing co-working
  • Hosting Fireside Chats and/or separate events (in consultation with and supported by the core staff delivery team) on topics related to the working group activities
  • Documenting related practices and/or topics in The Turing Way guides, either in the Community Handbook or other ongoing guides within the project
  • Creating a new guide related to the topics covered in the working group
  • Collaborating wtih existing working groups on projects related to infrastructure, accessibility, translation or other themes

At minimum, all working groups are required to participate in and contribute to the The Turing Way Community Town Hall, a quarterly event that brings together core team delivery staff, advisory groups, and working group liasons. All community members are invited to attend these events.

Transparency

All working group activities should be documented transparently so that non-working group members (and even non-Turing Way community members!) can learn about the working group's activities and projects.

This will help to address questions like:

  • How can more community members join in on working groups activities, or start their own?
  • How visible are various working group's activities for the rest of the community?
  • How can transparent reporting invite more people to participate in the conversation?

Decision-making

In principle, primary decision-making should lie with the working group team itself. However, they may be different types of decisions that might require different people from across the project for consultation and support.

This section details examples of decisions that may or may not require escalation for this aforementioned support.

Currently am consulting with working groups about these decisions

Decisions they feel empowered to take as an autonomous WG

  • Accessibility: Documenting guidelines and principles for community members to adopt access-centered practices
  • Translation & Localisation: Switching platforms for translation and localisation work for TTW
  • Infrastructure: Maintaining existing infrastructure (i.e. JupyterBook, netlify) and installing updates
  • Book Dash: Releasing and promoting application process for working group and participants
  • All:

Decisions that they invite consultation and support from the broader community

  • Accessibility: Starting new guide related to accessibility and access-related practices
  • Translation & Localisation: Recruiting new translatios
  • Infrastructure: Voting on a new domain name for the
  • Book Dash:
  • All: Voting processes (i.e. what I had recently suggested for the infrastructure wg?)?

Decisions that they invite consultation and support from the core staff delivery team

  • Accessibility: Subscribing to access-related service (i.e. transcription software) for use by the community
  • Translation & Localisation: Applying
  • Infrastructure: Process of buying a custom url/domain name
  • Book Dash: Deciding Book Dash dates and organising London hub logistics
  • All: Permissions for TTW organisation

Other decisions that don't fall under the above three categories?

  • Code of Conduct violations and/or enforcement
  • Decisions that may involve multiple working groups across each other (i.e. collaborations)
  • Applying for grants and/or funding to support working group-related work

Guidelines

The following guidelines listed below have been created to help with the creation of working groups, from brainstorming to establishing structure.

Getting started

While any community member can join a working group, setting up a working group has a few extra steps, in order to gage both need and interest in the development of the working group, alongside sharing more information with the broader community.

A few guiding questions that may help with this process:

  • Establish need: What need does this working group fulfill for The Turing Way community?
  • Establish requirements: Does this topic or type of work require ongoing support, or can it be contained into another format? (i.e. should this be a working group, or can this task be accomplished in 4 Collaboration Cafes?)
  • Establish membership: Who would be a member of this working group currently (at time of founding)?

Establishing Purpose

In order to create a working group, the purpose of the working group must be established. This may be done independently, and/or with the assistance of core delivery team staff and/or brainstorming with other community members and leaders. Establishing the purpose of a working group may take a series of brainstorming sessions and workshops, and there are a number of resources that may help with that self organising process.

The Turing Way Research Community Manager or Research Project Manager may also help with that process, in a series of facilitated sessions done at the Collaboration Cafe community call or in a separate set of discussions. Please reach out to them if you have any questions about the process, and/or would like some support in getting started.

A working group may focus on:

  1. A specific topic related to or of interest to The Turing Way community. (Examples of this may include: localisation, open source infrastructure maintenance, research infrastructure roles, research data management, etc.)
  2. A type of ongoing task or work currently being done within the project (i.e. training, mentoring, reviewing issues/pull requests)
  3. Anything else you would like to introduce to the community!

Establishing (Founding) Roles & Responsibilities

While these roles and responsibilities may shift or evolve during the lifetime of a working group, having initial discussions that enable you to broach topics that will enable you to work together for the during of the working group.

  • Discuss expectations: Do all founding members have an understanding of the roles & responsibilities listed above to support a working group?
  • Discuss founding membership roles: How will this group distribute responsibilities in the roles listed above?
  • Discuss working styles: Has the group assembled for the working group collaborated previously? What working styles do people in this group prefer, and how does that affect the cadence, style and communication of the team?
    • Note: Team-building and/or facilitation can be discussed with and/or assisted by the core staff delivery team.
  • Discuss previous experience with working groups or similar organizational formats: What did you like about those formats, and what would you avoid? What kind of organisational histories do members of this working group come from?
  • Discuss initial goals: Are there concrete goals that your working group would like to accomplish at its founding? Have these goals been scoped appropriately based on resources, availability, and interest?
    • Note: Frameworks like SMART goals, Agile, Kanban, Scrum methodology may be valuable here.
  • Discuss the group communication plans: Are there communication tools you might need for your ongoing work (i.e. Slack channel, Github organisation, emails, etc)

Processes for Establishing a Working Group

Once a working group has been established, it is important to identify and discuss the following topics within your group, as this will help to establish the candence and momentum of the group.

  • Establish regular meeting times and/or other group communication needs: How often should the group meet? Would they like to use an existing community call (i.e. Collaboration Cafe) for real-time discussions, or develop a separate call for coworking?
  • Establish a timeline for the working group: How long should this group be operational? Should it be time-bound or shift indefinitely?
  • Establish roles timeline: How long should people be appointed in their roles, and how often should these roles change?
  • Create a github repository for organising working group activities: All working group activities (including notes and the charter, mentioned below) should be archived in The Turing Way Github repository. TEMPLATE LINKED HERE
    • Note: In "Working Group Resources", other infrastructure recommendations & needs (i.e. permissions, templates, and checklists are available for you to use) can help with this process.Note: the infrastructure needs of the working group are something that I am working on documenting too. This is actually its own section, because continuity for bots, permissions, automations etc should be something that I need to document here
  • Establish a reporting mechanism and/or public notes archive: How will you share-out meeting notes and group progress to the wider community?
    • Note: All working groups should upload notes to their respective github repository in The Turing Way organisation. For a template, please see this template repository:
  • Establish appropriate permissions for accounts: What accounts does this group need access to? Does this group have the proper account access & permissions in order to carry out your work?
    • Note: The Community Manager and/or Project Manager can help with this!
  • Create a working group charter: There is a template on in a PR on the TTW repository: https://github.com/the-turing-way/working-group-template
  • Create an open calendar invite: This may require support of a core delivery staff member to add the information to the public google calendar
  • Advertise on Community channels: Slack, Github, social media and/or the TTW newsletter to share the information about your working group
    • Note: The Community Manager and/or Project Manager can help with this! Ask them on Slack or tag them on Github to share out this information, or co-create a communication plan.
  • Create a slack channel for collaboration (not required - but encouraged): Having an ongoing channel makes it easier to communicate across. What other communication channels might this group need?
  • Add information about working group in Ways of Working and/or Governance documents: Is there a public and up-to-date record of this working group?
  • Is there something about CoC that needs to go here?

Also what might need to go here: setting up infrastructure in the form of Github repositories: README.md, CONTRIBUTING.md, bots, protect main brain, etc.

Approving a Working Group

The approval process for a working group requires a bit more involvement from the wider community and leadership council, as it is important to understand what resources might be available to supp, and/or if the working group's aims are appropriate for the community.

  1. Completed community charter: All working groups need to fill out a proposed working group charter (template here) that should be presented to the TTW leadership council and broader community for discusssion and review
  2. Open discussion and/or Q&A: All Discuss your idea in community spaces: such as the TTW Slack workspace, Github discussions/issues, and/or Community Calls like the Collaboration Cafe.
  3. Leadership council approval: This creation of this working group must be approved by The Turing Way leadership council at their regular organisating calls. These meetings happen every three months, which you can find out about in this schedule.

Maintaining a Working Group

While initiating a working group, maintaining a working group's activities is integral for the group's success.

On a quarterly basis, a working group should revisit its structures and ways of working in order to establish that the group is adhering to its established purpose. The following questions can be guidelines for doing so. These questions have also been compiled into this working group quarterly audit template:

  • Review purpose: Is this working group still fulfilling its established purpose?
  • Review progress: Has this working been able to make progress towards its stated goals? What adjustments may need to be made in order to support this kind of work?
  • Review process: Is the existing way of working valuable for this team currently? Are there other processes (decision-making, conflict manage)
    • Note: The Community Manager and/or Project Manager can help with facilitating this!
  • Review roles: Is everyone in the group in a role they would like to stay in? If not, how should these roles change?

Other things that might be needed here: voting processes for broader community consultation, code of conduct references, and cross-working group collaboration

Sunsetting a Working Group

Deciding when to sunset a working group can be difficult. Often, working groups may continue on indefinitely, and while there are a variety of reasons for this, this may be because there are not means of recognising when a group's aims and/or goals have shifted, or if a group's work is no longer needed. Knowing when it might be time to sunset a working group or shift its aims or direction is an important

Reasons for sunsetting a working group can be for the following

  • Decreased capacity: Are there no longer enough people to support this working group? If the number of peope able to sustain a working group decreases to below two, the possibility of shutting down the working group should be discussed.
  • Disciplinary action: If there have been any actions taken that may have broken The Turing Way code of conduct, the Staff Delivery Team and/or TTW way co-leads reserve the right to retire the working group.
  • Decision from leadership council: If the actions or projects realted to the working group are not seen to be relevant to The Turing Way project more broadly, it is possible for the leadership council to disban a working group through a voting process.

Once a group has decided to close down its efforts, consider the following:

  • Document reasons for closing down working group: Documentation is important for continuous learnings - for future and current working groups, as well as the wider community and even ecosystem that The Turing Way feeds into!
    • If you need help with this documentation process, check out this template
  • Change the meeting information: Remember to cancel meeting invites, and archive existing notes in the github repository
  • Change the documentation about the group: Remember to change the information about the groups activity in all spaces where information has been documented

Sources

The following resources were used in drafting this documentation:

Notes

7 August notes

  • Did not have time to review in the team delivery meeting

7 August notes

  • Did not have time to review in the team delivery meeting

19 July notes

  • Accountability to community
    • Scribe? chairs?
    • Who is responsible?
  • Participating in fireside chats? Collaboration Cafes? Overall health of the project?
  • Resources from core team
  • Reciprocity should be two ways
  • Special interest groups at CS&S: templates, public notes archive, more structure around that we'll have stuff in 6 different platforms
  • Specific area for folks hosting specific notes
  • Charters - have a template (lightweight)
  • How can a meeting time be created? H
  • There may be a reason why a working group may be sunsetted:
    • Can require the involvement o
    • Every year we will have an annual review process, where we can decide in groups need to be sunsetted
  • Code of conduct should be updated to include this kind of behaviour f
    • WG is not being accountable
    • Behavioural
  • https://github.com/alan-turing-institute/the-turing-way/blob/main/ways_of_working.md#commitments
  • No core team accountability?
  • How do the working groups interact with the core team?
  • Chair of working group is member of Turing Way Leadership Team
  • Take out references to Core Team 9because it's been sunsetted
  • Format questions around
    • Chair
    • Deputy Chair
  • Not everyone should be able to
  • Leadership does need to approve a working group right?
    • If there's not a working group that meets your needs, then here's how you can start one
    • WG does require accountability and approval from leadership team
  • What do you want to achieve? What do you need to know in order to do it?
  • Transparency -> as a part of processes & wider documentation
  • Can we mandate that people are going to have 4+ people?
  • What is the role of an external organisation in the working group?
  • Responsibility of working groups should be to engage in the community important that folks are recuited from the community
  • Can the chair also be a representative to the leadership council?
    • Is recognition in the leadership council giving people a voice?
    • If they are taking on the responsibility of chairing, shouldn't they also be in the room?
    • Can there be multiple chairs? Or rotating chairs
    • Co-chairs vs Chair & Deputy Chair
    • Accountability for the chairs