Formalising a Working Group#
While any community member can join a Working Group (WG), setting up a WG involves a few extra steps to assess both the need and interest in its development, alongside sharing more information with the broader community. This section is designed to guide the creation of WGs, from brainstorming to establishing structure.
Should this Working Group be Created?#
A few guiding questions that may help with the process of identifying if a WG should be created (or not!) are:
Establishing Need: What need does this WG fulfill for The Turing Way community?
Establishing Requirements: Does this topic or type of work require ongoing support, or can it be integrated into another format? (Should this be a WG, or can this task be accomplished in Collaboration Cafes?)
Establishing Membership: Who would be a member of this WG currently (at the time of founding)?
Establishing Purpose for the Working Group#
To create a WG, its purpose must be established. This can 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 WG may require a series of brainstorming sessions and workshops, with various resources available to facilitate this process.
The The Turing Way Research Community Manager or Research Project Manager may also assist in this process through facilitated sessions conducted at the Collaboration Cafe community call or in separate discussions. Please reach out to them if you have any questions about the process or would like support in getting started.
A WG may focus on:
A specific topic related to or of interest to The Turing Way community (such as, localisation, open-source infrastructure maintenance, research infrastructure roles, research data management).
A type of ongoing task or work currently being done within the project (such, training, mentoring, reviewing issues/pull requests).
Any other aspect you would like to introduce to the community!
Proposing a Working Group#
A short proposal should be created and shared as an issue on The Turing Way’s main GitHub repository. This proposal doesn’t have to be exhaustive but must outline the area of work being proposed and where needs or opportunities have been identified in the project, community, or within the broader open science or research ecosystem of The Turing Way. Please identify and include at least 3 to 4 members who are interested in participating and contributing to the proposed area of work.
Ideally, the proposing party should discuss their plan with The Turing Way Research Community Manager or invite support from other members of the project delivery team.
Once proposed, the Research Community Manager will present this proposal to the rest of the project delivery team and share it with the community more broadly, inviting their inputs. The project delivery team will discuss the proposal in the context of other WGs, feedback from the community, and ongoing projects. Feedback from their discussion will be shared directly on the GitHub issue. Based on the community feedback, the number of members interested, and feasibility for the work to be supported in The Turing Way, a final decision will be made and communicated by the project leadership with the proposing party.
Approval for Esablishing a Working Group#
The approval process for a WG involves engagement from the wider community and the project delivery team to understand what resources might be available in supporting the WG and if the WG’s aims are appropriate for the community.
Open Discussion and/or Q&A: Discuss your idea in community spaces such as the The Turing Way GitHub issue, Slack workspace and/or Community Calls like the Collaboration Cafe. Please reach out to the Research Community Manager will support you with this.
Leadership Approval: The creation of this WG must be approved by The Turing Way leadership at their regular bi-weekly meetings. These meetings happen every two weeks, agenda for which is built by the project manager. Notes from their meetings are archived in the GitHub and outcomes communicated directly with the community members where needed.
What’s next?#
Once approved, the project delivery team will inform the group. Research Community Manager and project manager will coordinate with the group to help them access existing resources they might need and create a public repository to capture notes and documentation from their work. The WG’s approval will be announced, and WG members will be supported in inviting more members to their work.
Action on the group to completed a WG charter: All WGs need to provide ‘way of working’ in their charter document. We have provided a Template for the Working Group’s Charter, which should be filled through group meetings or asynchronously and shared openly on WG’s GitHub repo openly, inviting review and feedback from the project delivery team and community.
Establishing Expectations for WG Members’ Responsibilities#
While the roles and responsibilities may shift or evolve during the lifetime of a WG, having initial discussions enables the group to work together effectively throughout the WG’s duration.
Discuss Expectations: Do all founding members understand the roles and responsibilities (provided in the charter) to support a WG?
Discuss Founding Membership Roles: How will this group distribute responsibilities among the roles listed above?
Discuss Working Styles: Has the group collaborated previously? What working styles do people in this group prefer, and how does that affect the team’s cadence, style, and communication?
Note: Team-building and/or facilitation can be discussed with and/or assisted by the core staff delivery team.
Discuss Previous Experience with WGs or Similar Organisational Formats: What did you like about those formats, and what would you avoid? What kind of organisational histories do members of this WG come from?
Discuss Initial Goals: Are there concrete goals that your WG 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’s Communication Plans: Are there communication tools you might need for your ongoing work (Slack channel, GitHub organisation, emails)?
Logistics for Managing a Working Group#
Once a WG has been established, it is essential to identify and discuss the following topics within your group to establish its cadence and momentum:
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 (such as Collaboration Cafe) for real-time discussions, or develop a separate call for co-working?
Establish a Timeline for the WG: How long should this group be operational? Should it be time-bound or ongoing indefinitely?
Agree on Terms for All Roles: How long should people be appointed in their roles, and how often should these roles change?
Use GitHub Repository for Organising and Documenting WG Activities: All WG activities (including notes and the charter, mentioned below) should be archived in a Turing Way GitHub repository (you can use and adapt this template).
Note: In “WG Resources,” other infrastructure recommendations and needs (permissions, templates, and checklists) are available to help with this process.
Establish a Reporting Mechanism and/or Public Notes Archive: How will you share meeting notes and group progress with the wider community?
Note: All WGs 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 and permissions to carry out its work?
Note: The Community Manager and/or Project Manager can assist with this!
Create a WG Charter: Please follow the Template for the Working Group’s Charter.
Note: All WGs should openly share an updated charter to their respective GitHub repository in The Turing Way organisation.
Create an Open Calendar Invite: This may require support from a core delivery staff member to add the information to the public Google Calendar.
Advertise on Community Channels: Use Slack, GitHub, social media, and/or the The Turing Way newsletter to share information about your WG.
Note: The Community Manager and/or Project Manager can assist 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 communication easier. What other communication channels might this group need?
Add Information about WG in Ways of Working and/or Governance Documents: Is there a public and up-to-date record of this WG?
Maintaining a Working Group#
While initiating a WG, maintaining its activities is integral for the group’s success. On a quarterly basis, a WG should make time to revisit its structures and ways of working to ensure it is adhering to its established purpose.
The following questions can guide this process:
Review Purpose: Is this WG still fulfilling its established purpose?
Review Progress: Has this WG been able to make progress towards its stated goals? What adjustments may need to be made to support this work?
Review Process: Is the existing way of working valuable for this team currently? Are there other processes (decision-making, conflict management) that may need adjustment?
Note: The Community Manager and/or Project Manager can assist with facilitating this!
Review Roles: Is everyone in the group in a role they would like to maintain? If not, how should these roles change?
Pausing or Sunsetting a Working Group#
Deciding when to sunset a WG can be difficult. Often, WGs may continue indefinitely, but there are various reasons to consider sunsetting a WG:
Completion of set goals: If WG has met their initially extablished goals and no longer to operate as WG, a WG can be closed.
Merging with other WG: If a WG’s work hugely overlaps with other existing WG’s work, they may choose to merge the two groups into one group. If all members of one group decide to move to another group, they can formally close their WG (such as indicating the status on their repository).
Decreased capacity: If there are no longer enough people to support this WG (for example, if the number of people in the WG is decreases below two), possibility or need to pause or sunset a WG should be discussed.
Recommendation from project delivery team: If the actions or projects related to the WG are not seen to be in line with The Turing Way project more broadly or if more time investment is expected from the project delivery team (including the Research Community Manager) to support the WG (due to reduced capacity or conflicting priorities in the project), the project delivery team may recommend pausing or sunsetting a project. The WG may decide to pivot their scope or pause their work following their internal or a community voting process (such as via a public GitHub issue).
Disciplinary Action: If there have been actions taken that may have broken The Turing Way code of conduct, the Staff Delivery Team and/or The Turing Way way co-leads reserve the right to retire the WG.
Other reasons!
Once a group has decided to close down its efforts, consider the following:
Document Reasons for Closing Down WG: Documentation is essential for continuous learning—for future and current WGs, as well as the wider community and ecosystem that The Turing Way feeds into!
Change Meeting Information: Remember to cancel meeting invites and archive existing notes in the GitHub repository.
Update Documentation About the Group: Change the information about the group’s activity in all spaces where information has been documented.