diff --git a/book/website/_toc.yml b/book/website/_toc.yml index 200de775d33..4ae96b03e9d 100755 --- a/book/website/_toc.yml +++ b/book/website/_toc.yml @@ -691,6 +691,7 @@ chapters: - title: Examples of Open Source Business Models file: collaboration/oss-sustainability/oss-sustainability-examples + # ===== Guide for Ethical Research ======================================== - file: ethical-research/ethical-research sections: @@ -756,6 +757,7 @@ chapters: - title: Ethical Considerations for Open Source Governance Models file: ethical-research/ethics-open-source-governance + # ===== Community Handbook ======================================== - file: community-handbook/community-handbook sections: @@ -890,6 +892,17 @@ chapters: file: community-handbook/fireside-chat/fireside-chat-roles - title: Giving a Turing Way Talk file: community-handbook/presenting + - title: Working Groups + file: community-handbook/working-groups + sections: + - title: Guidelines for the Working Groups + file: community-handbook/working-groups/working-groups-guideline + - title: Formalising a Working Group + file: community-handbook/working-groups/working-groups-formalisation + - title: Charter Template for the Working Groups + file: community-handbook/working-groups/working-groups-charter-template + - title: References + file: community-handbook/working-groups/working-group-resources - title: Template Collection file: community-handbook/templates sections: @@ -929,3 +942,6 @@ chapters: file: afterword/glossary - title: Bibliography file: afterword/bibliography + + + diff --git a/book/website/community-handbook/working-groups.md b/book/website/community-handbook/working-groups.md new file mode 100644 index 00000000000..1a056a0b0bf --- /dev/null +++ b/book/website/community-handbook/working-groups.md @@ -0,0 +1,46 @@ +(ch-working-groups)= +# *The Turing Way* Working Groups + +A working group (WG) is an organised group or committee within a project, organisation or community. +WGs are formed for a specific purpose, such as addressing a need or opportunity identified in a project or community. +WGs are composed of individuals who bring their interests, expertise, or willingness to engage with a specific topic or context for which the WG is formed. +WG members collaborate to provide accountability, solve problems and make decisions to achieve the goals set for the group. +WGs scope can be time-bound (short-term or long-term) or open-ended based on the type of tasks the group is assigned. + +WGs are used across many sectors including government, academia, business and nonprofit or volunteer-led organisations to decentralise operations and decision making. +In open science, many communities carry out their work through established WGs. +Projects like [Jupyter](https://jupyter.org/governance/standing_committees_and_working_groups.html), [Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md), [Eclipse Foundation](https://www.eclipse.org/org/workinggroups/process.php#wg-member-roles), [Sustain OSS](https://sustainoss.org/working-groups/), [The Carpentries](https://carpentries.org/) and [CHAOSS](https://chaoss.community/cgi-sys/suspendedpage.cgi) are few examples where WGs have been organised to ensure timely and open engagement with their communities. + +Within *The Turing Way*, WGs are formed by a small groups of people who work together on specific topics, themes, or types of work identified by community members as areas of interest. +From the onset, different kinds of work in *The Turing Way* project have been led and executed by different groups of people. +For example, since 2020, localisation and translation work is being carrying out by a group international community members, who although initially worked in an ad-hoc manner, later were named and recognised as 'Translation and Localisation Team'. +Similarly, in 2021, after moving Book Dash as online-first event, a 'Book Dash Planning Committee' was convened yearly joined by a few previous attendees of Book Dashes who supported the planning and delivery of the event. +Nonetheless, formation of WGs had largely remained informal: after existing streams of work had been identified, community members engaged with the work were formally recognised and encouraged to develop ways of working that align with their needs. + +However, as the community has grown, creating explicit pathways for formalising WGs is the only way for ensuring that everyone has the same opportunity to navigate and benefit from structure that WGs provide. +We also recognise that lack of guidance leads to the [tyranny of structurelessness](https://www.jofreeman.com/joreen/tyranny.htm), where navigating information may be easier for people who have been involved from the beginning, the uncertainty of roles and responsibilities can ultimately exclude those who don't have direct contact with the project team. + +In *The Turing Way*, the formalisation of WGs started in 2022. +The current research community manager of the project started her familiarity with the project through community mapping work in 2022. +The goals were to (1) formalise already existing and ongoing work within the community, and (2) support new areas of work that could address the observed and documented needs of the project and community. + +We believe that everyone in *The Turing Way* community has expertise to share, and thereby anyone can join our project and community. +We describe different ways to contribute to the project in our [contribution guideline](https://github.com/the-turing-way/the-turing-way/blob/main/CONTRIBUTING.md). +Similarly, we encourage anyone who would like to join an existing WG to reach out to the specific chairs and leads of those group ({ref}`find details of our current WG`). + +While anyone who joins *The Turing Way* can attend a WG meeting and join the WG, joining a WG is **not** a requirement for engaging with *The Turing Way*. + +We have also been hosting _The Turing Way_ Community Forums where WG members share updates and provide resources for the community members to get involved ([recordings on our YouTube channel](https://www.youtube.com/theturingway)). + +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 Turing Way* team, as well as to openly get recognition for their work within the community. +However, there are a few requirements for community members to *create* a working group, process and documentation for which is provided in this chapter. + +With information shared in this chapter, we want to ensure that community members can identify infrastructure and support they need, as well as ways to sustain WGs' efforts. +A standard approach for establishing and managing WG will also allow *The Turing Way* leadership and project delivery team to provide the oversight and support needed to bring cohesiveness across all WGs and align WGs goals with the project's overarching goals. + +The process described in this chapter adheres to our commitment to ensuring transparency and engagement with our community. +For WGs this means that our community members are informed of the WGs work and can participate openly, ensuring critical mass required to establish, maintain and sustain a WG. + +In addition to {ref}`guidelines` and {ref}`process for formalising a WG`, we provide {ref}`a template` (in the final subchapter) for interested members of the community to self-organise, incubate, maintain, and/or eventually sunset a working group. +This document, as is the case with *The Turing Way* guides themselves is a living document. +Please help us keep this updated as the community and its governance evolves. \ No newline at end of file diff --git a/book/website/community-handbook/working-groups/working-group-resources.md b/book/website/community-handbook/working-groups/working-group-resources.md new file mode 100644 index 00000000000..a8cee612b24 --- /dev/null +++ b/book/website/community-handbook/working-groups/working-group-resources.md @@ -0,0 +1,26 @@ +# References + +The following resources were used in drafting and creation of templates for this documentation: + +* Gitlab: [Working Groups](https://about.gitlab.com/company/team/structure/working-groups/) +* The Carpentries: [Executive Council's Standing Committees](https://docs.carpentries.org/topic_folders/governance/executive-council.html#executive-council-s-standing-committees) +* OLS (Open Life Science): [OLS Working Groups](https://docs.google.com/document/d/1EUHvYv5wvZiJSK4yYDwwDHs9Ds6tCjqB3XezqCaetEI/edit#) +* Project Jupyter Governance: [Standing Committees and Working Groups](https://jupyter.org/governance/standing_committees_and_working_groups.html) +* HOTOSM: [Humanitarian OSM Team Working Groups](https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Working_groups) +* Kubernetes: [Community Governance](https://github.com/kubernetes/community/blob/master/governance.md) +* Decidim: [Our Governance](https://meta.decidim.org/assemblies/our-governance) +* Open Life Science: [Open Life Science Charter](https://docs.google.com/document/d/1pD_P8oKLenyxCM39PZxu3X8a6hZQ4jZi-fA-xBB3DXQ/edit#heading=h.gjdgxs) +* Django: [Django Internals Organization](https://docs.djangoproject.com/en/dev/internals/organization/) +* Social.coop: [Governance](https://wiki.social.coop/wiki/Governance) +* Brockwell Greenhouses: [Governance at BPCG](https://www.brockwellgreenhouses.org.uk/governance-at-bpcg/) +* data.coop (danish): [Data.coop Governance](https://data.coop/#) +* Code for Science & Society: [Fiscal Sponsorship Model](https://www.codeforscience.org/) +* HOT OpenStreetMap: [HOT Working Groups Governance](https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Working_groups/Governance) +* Wikipedia: [Wikimedia Foundation](https://foundation.wikimedia.org/wiki/Home) +* Pyladies: [PyLadies Global Council](https://pyladies.com/blog/Announcing-the-Inaugural-PyLadies-Global-Council/inaugural-pyladies-council/) +* Wikipedia Education WG: [Wikipedia Education Working Group](https://en.wikipedia.org/wiki/Wikipedia:Education_Working_Group) +* Eclipse: [Eclipse Working Groups Process](https://www.eclipse.org/org/workinggroups/process.php) +* IEEE SA: [Mobilizing Working Group](https://standards.ieee.org/develop/mobilizing-working-group/governedwg/) +* W3C: [Working Group Charter](https://www.w3.org/Guide/process/charter.html) +* Loomio: [Working Groups](https://www.loomio.coop/working_groups.html) +* Metaarchive: [Metaarchive Charter 2021](https://metaarchive.org/wp-content/uploads/2021/06/ma_charter_2021.pdf) \ No newline at end of file diff --git a/book/website/community-handbook/working-groups/working-groups-charter-template.md b/book/website/community-handbook/working-groups/working-groups-charter-template.md new file mode 100644 index 00000000000..c9909be1492 --- /dev/null +++ b/book/website/community-handbook/working-groups/working-groups-charter-template.md @@ -0,0 +1,162 @@ +(ch-working-groups-charter-template)= +# Template for the Working Group's Charter + +__*The template provided here is a revised version of the [Sample group charter provided by Collaborative Leader Network](https://collaborativeleadersnetwork.org/strategy-tools/sample-group-charter). WG conveners should use this document to discuss different aspects of their work, build a shared understanding of the ways of working and adapt this document for their respective WGs.*__ + +## *The Turing Way* Working Group Charter: [GROUP's NAME HERE] + +### Purpose + +``` +This section should articulate the purpose and needs co-developed by the WG. +It should also provide context for how the group intends to fulfil its purpose by addressing specific challenges and needs. +``` + +The [GROUP's NAME HERE] is a collaborative space for WG members to prioritize challenges, create a roadmap, and openly share them on GitHub repositories (such as issues on *The Turing Way* main repo or a dedicated repo for the WG). + +The WG keeps the project delivery team informed and invites their input or support when needed. + +Additionally, the WG engages with the broader community, inviting their participation and feedback on their work. This includes selecting the best course of action in the projects the WG undertakes. +The WG also considers alternatives suggested by WG members, community members, and the project delivery team in the context of community goals, current issues, concerns, and competing interests or preferences. + +### Roles and Responsibilities + +#### Structure of the WG + +*Guidance and recommendations are provided in the chapter, {ref}``.* + +- Chairs: [NAMES] +- Documentarian: [NAMES] +- `Add other roles here` +- Delivery Team Contact: [NAME] +- Members at large: [NAMES] + +``` +Describe the responsibilities of all roles following the guidance document. +Provide links to resources and additional information WG members should have access to. +``` +### Responsibilities for Chair and Co-Chairs: + +1. Provide leadership for the WG, following the Code of Conduct and WG Charter to guide its direction and activities. +2. Facilitate the WG's work by organising and chairing meetings effectively. +3. Ensure that responsibilities within the WG are distributed fairly among members. +4. Ensure that the WG members are provided with timely information and remain accountable for their actions and decisions. +5. Represent the WG in the community spaces and in conversations with *The Turing Way* leadership. +6. Participate in meetings where representation from the WG in wider governance spaces is required. +7. Relay feedback, announcements, and discussions from the leadership or *The Turing Way* delivery team to the WG. +8. Identify a member from the WG to represent the group in meetings if unable to attend themselves. + +### Responsibilities for Documentarian: + +1. Documenting and reporting on the logistical aspects of the group's activities. +2. Assist the chair in maintaining meeting schedules and ensuring timely proceedings. +3. Note-taking during WG meetings and uploading notes to the designated repository, ensuring they are free from private or sensitive information. +4. Communicate about the group's activities in a transparent, open, and accessible manner to facilitate broader engagement. +5. Maintain documentation regarding the distribution of duties, especially if shared among multiple individuals, in the WG's repository. + +### Responsibilities for *The Turing Way* Delivery Team Contact: + +1. Serve as a liaison between the WG and *The Turing Way* project delivery team to facilitate support when needed. +2. Provide assistance with operational activities, and logistics, or work with the delivery team in advocating for resource allocation as required by the WG. +3. Clarify the potential impact of WG decisions on the project and broader community, and ensure leadership involvement where necessary. +4. Maintain open lines of communication and connection between the WG and the project delivery team. + +#### Responsibilities of All Members of the WG: + +- Provide specific expertise, including identifying emerging challenges and opportunities. +- Review WG's documentation and provide comments, such as on GitHub. +- Attend WG meetings and prepare appropriately to contribute to the agenda, specifically those assigned to them. +- Complete all necessary actions assigned prior to each meeting. +- Support the distribution of information to other WG members after each meeting and gather information/feedback. +- Articulate and reflect the interests of community members through community engagement. +- Maintain a focus on the roadmap co-created with the WG members for the benefit of the broader community. +- Contribute to the documentation of the WG and share them broadly in *The Turing Way* book. +- Represent and share WG's work, recommendations, and accomplishments in community spaces such as Collaboration Cafe, Community Forum + +### Guiding Principles + +- The WG members establish clear roles and responsibilities (read guidelines in {ref}`working-groups-guideline`). +- The WG chairs facilitate open and regular meetings to discuss agenda points invited from the WG members. +- In areas where the WG has decision-making authority, members will strive to reach an agreement by consensus. +- For decision-making related to agenda points or matters discussed in the WG, consensus-based recommendations and decisions are clearly communicated. +- In matters where consensus within the WG is not met, the broader community is engaged via the WG's GitHub repository in a meaningful way to evaluate the proposed recommendation or decision. Community members are invited through other communication channels to share their feedback by commenting on the GitHub issue. +- Matters that affect the broader project and community are escalated to the project leadership and project delivery team to ensure their input on decision-making. Recommendations and decisions will be openly communicated. +- All decisions and recommendations take into account the timeline and available resources to support the work. +- If required resources are lacking, input and support from the project delivery team are sought before making the decision. + +#### Reciprocity and Transparency in Decision-Making + +This section is developed using recommendations from {ref}`the WG Guidelines`. + +``` +Notes from how the WG operationalises reciprocity and transparency in decision-making. +``` + +### Terms of Membership + +Community members agree to participate openly and responsibly until they are able to volunteer and stay involved in *The Turing Way* community. + +``` +Terms of different roles should be decided by the WG members and added here! +``` + +Specific positions will be open in the WG if the post holder: + +- steps down from their role +- can no longer serve in their role +- wants to take a break from their duty or leave the WG + +In a case where a member’s position is declared vacant, the WG chairs will invite WG members to volunteer to fill the role or hold a formal process within the WG to fill the position, especially if more members are interested in filling limited positions. + +### Meetings and Communications + +#### Convening of Meetings + +- Meetings are held at a time and platform chosen by the WG in the course of their work. + - `Provide current plans for meetings and point to the document where this information can be found.` +- [INSERT NUMBER] meetings will be held monthly unless communicated otherwise. +- WG members will be informed of meetings through [Slack channel or direct emails]. + - The chairs will announce the details about an upcoming meeting and invite an agenda. + - A shared document will be used to capture notes from the meeting. +- Notes will be maintained and archived by the documentarian. + - `Provide a link to the folder where meeting notes are archived.` + - `Some WGs may decide to record their meetings to allow members who are unable to attend the meeting to catch up asynchronously. Provide details here.` + +#### Communication + +- Meetings will be advertised via the WG's communication channels: [CHANNEL DETAILS (Slack channel or email)]. +- Project documents and announcements will be posted on the WG's communication channels. +- WG members should also use the WG's communication channels to ask or share information. +- Emails: + - In emails to the WG members, chairs should be copied on all correspondence they should be aware of to ensure that everyone in the WG has the same information. + - If chairs choose to open a dialogue via email, all WG members will be copied. + +#### Conduct of Meetings + +- Time, duration, frequency, and platform for the WG's meetings will be identified through consensus in the WG. +- Meetings will be open to all WG members and to the broader community. +- It will be communicated if a meeting will be closed for invited members only. +- Meetings will be facilitated by the chairs, and a documentarian will take notes. +- In meetings outside the WG's regular meeting, an informed member will be encouraged if the WG chairs cannot attend. +- After all agenda items have been addressed, time will be provided for non-members in attendance to voice their opinions. +- Meetings will end with a clear understanding of actions, expectations, and assignments for the next steps. +- A documentarian will keep a record of meeting attendees, key issues raised, and actions required. +- The previous meeting record and a meeting agenda will be forwarded to members of the WG before the next meeting. Any changes to the record of the past meetings shall be communicated in writing prior to or during the next meeting. + +#### Meeting Ground Rules + +- Chairs will communicate ground rules for how attendees contribute (like raising a physical or digital hand, or by writing on the shared notes or in the chat). +- Chairs will also communicate any additional ground rules that the WG follows before the meeting starts and provide links to relevant resources in a shared document. +- Some general etiquettes to follow: + - Speak one at a time to avoid interrupting others. + - Wait for the facilitator to indicate the next speaker/person speaking. + - The facilitator may call on people who have not yet spoken before calling on someone a second time for a given subject. +- Share the space – ensure that all members who wish to have an opportunity to speak are afforded a chance to do so. +- Maintain a respectful tone toward all participants. +- Listen to other points of view and try to understand other interests. +- Share information openly, promptly, and respectfully. +- If requested to do so, hold questions until the end of each presentation if planned during the meeting. +- Support the documentarian in taking notes. +- Ensure that notes taken are accurate. + +*Please refer to some more useful resources in the {ref}`cl-organising-meetings`* diff --git a/book/website/community-handbook/working-groups/working-groups-formalisation.md b/book/website/community-handbook/working-groups/working-groups-formalisation.md new file mode 100644 index 00000000000..dfe851526fd --- /dev/null +++ b/book/website/community-handbook/working-groups/working-groups-formalisation.md @@ -0,0 +1,122 @@ +(ch-working-groups-formalising)= +# 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: +1. 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). +2. A type of ongoing task or work currently being done within the project (such, training, mentoring, reviewing issues/pull requests). +3. 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. + +1. **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. +2. **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 {ref}`ch-working-groups-charter-template`, 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](https://github.com/the-turing-way/working-group-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](https://github.com/the-turing-way/the-turing-way/). 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 {ref}`ch-working-groups-charter-template`. + * Note: All WGs should openly share an updated charter to their respective GitHub repository [in *The Turing Way* organisation](https://github.com/the-turing-way/the-turing-way/). +* **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. \ No newline at end of file diff --git a/book/website/community-handbook/working-groups/working-groups-guideline.md b/book/website/community-handbook/working-groups/working-groups-guideline.md new file mode 100644 index 00000000000..d33cf2aa159 --- /dev/null +++ b/book/website/community-handbook/working-groups/working-groups-guideline.md @@ -0,0 +1,156 @@ +(ch-working-groups-guidelines)= +# Guidelines for the Working Groups + +All WGs, teams, and people within *The Turing Way* are responsible for adhering to our [Code of Conduct](https://the-turing-way.netlify.app/community-handbook/coc) and our (upcoming) [Accessibility Policy](https://github.com/the-turing-way/the-turing-way/issues/3145), both in organising WGs and facilitating WGs' activities. + +Members of WGs will be responsible for establishing their group structures which are: +1. **Open & Transparent** for others to learn about, and join in on; +2. **Inclusive** for all kinds of people and expertise; +3. **Accessible** to join and participate in. + +Each WG will also be responsible for documenting their ways of working and ongoing projects. +WGs should discuss specific support they might need in their work with the *The Turing Way* team, specifically our Research Community Manager (but you can reach out to any of the co-leads and project manager too!). + +In this subchapter, we discuss the roles and responsibilities of WG, in the next subchapter, you will learn about how to propose and manage a WG. + +(ch-working-groups-guidelines-roles)= +## Roles and Responsibilities + +We provide examples of structure and roles for different members in the WG. +However, please note that the roles suggested below are not meant to be permanent (for example, a WG chair should not be a permanent appointee), but rather a guiding structure that WGs can begin their work with, and then expand, remix, and reuse for their purposes. +All roles may be temporary appointments or long-term, as agreed within the WG. + +One person may occupy multiple roles. +However, one person should not chair multiple WGs, to enable the diffusion of responsibilities and ensure the representation of different members in leadership roles. + +Community members can join any number of WGs, however, we discourage joining more than one or two WGs to prevent the over-extension of individuals within the community. + +Roles are suggested not to create hierarchy within a WG, but to enable the smooth operation and maintenance of the collective team, as well as to define responsibilities clearly (and avoid the tyranny of structurelessness). + +### Chair and Co-Chairs + +These person(s) are responsible for the creation and continuation of a WG. +Chairs provide leadership and facilitate the WGs' work. +Chairs are responsible for organising and chairing meetings, ensuring that the responsibilities are fairly distributed, 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 equitably. + +The Chair will serve as the "Liaison" for *The Turing Way* leadership and will participate in meetings where representation from the WG in wider governance spaces might be needed. +Chairs will also be responsible for relaying feedback, announcements and discussions from the leadership or *The Turing Way* delivery team to the WG. +If a chair is unable to represent their WG in a specific meeting, they must identify a member from the WG who can represent the group and share notes from the meeting. + +### Documentarian + +The documentarian supports the WG in improving transparency around their work so that those who are not yet part of the WG but are interested in their work can follow or engage with their work. +The documentarian is responsible for ensuring the logistical reporting of the group's work. +They are responsible for uploading meeting notes (without any private and sensitive information), helping the chair in time-keeping and communicating about the group's activities in a way that remains transparent, open, and accessible for others to access. +For example, if the duties of the chair are distributed across multiple people, the documentarian is responsible for documenting this format in the WG's repository. + +### *The Turing Way* Delivery Team Contact + +While WGs should be able to operate with autonomy in most decisions that apply to their work, sometimes they require help from *The Turing Way* project delivery team to scope and test some ideas of work within their group or make decisions that impact the project and the broader community. + +To make it easy to invite support, such as with operational activities, logistics or resources, each WG should have an assigned contact. +It could be a chair or other existing role, or someone else from the WG who keeps the line of communication and connection open with the project delivery team. +In the initial stages of a WG, this person could also be a member of the project delivery team like the Research Community Manager or Project Manager of *The Turing Way*. + +### WG Members + +Any Turing Way community member is encouraged to join a WG without restriction, and without taking on a leadership role. + +Responsibilities of all Members of the WG include the following, and can adapted in shared in the WG's charter document: + +- Providing specific expertise, including identifying emerging challenges and opportunities. +- Reviewing WG's documentation and providing comments, such as on GitHub. +- Attending WG meetings and preparing appropriately to contribute to the agenda, specifically those assigned to them. +- Completing all necessary actions assigned prior to each meeting. +- Supporting the distribution of information to other WG members after each meeting and gathering information/feedback. +- Articulating and reflecting the interests of community members through community engagement. +- Maintaining a focus on the roadmap co-created with the WG members for the benefit of the broader community. +- Contributing to the documentation of the WG and sharing them broadly in *The Turing Way* book. +- Representing and sharing WG's work, recommendations, and accomplishments in community spaces such as Collaboration Cafe, Community Forum + +### Advisors and Experts + +This is a suggested role that can be invited or appointed by WG on an ad-hoc basis. +An advisor will advise WG about key aspects of the project, provide a community perspective on key considerations, and be a sounding board for deliverables set within a WG. + +An advisor or expert's participation in a WG meeting or asynchronous work may include facilitating specific conversations, providing feedback on specific pieces of work or supporting WG towards building consensus among members on the desired project goals, building resources, sharing them openly and identifying risks or mitigation measures. + +## Infrastructure Requirements for WGs + +- Dedicated Github Repository using the template provided in the GitHub organisation + - Right permissions for members +- Dedicated Slack channel +- A shared document (such as Framapad) for meeting notes (that are archived on GitHub) +- Calendar invites with joining link (ask Research Community Manager for support if needed) for WG meetings + +(ch-working-groups-guidelines-charter)= +## WG Charter + +Each WG should develop a document that centralises information about the WG by providing the purpose of the WG, ways of working, different roles and responsibilities of the WG members, and anything a new member of the WG might need to participate. + +We provide a {ref}`working group charter template` to help develop this document, which should be shared in the GitHub repository of the WG. + +The group charter should provide, to the degree WG members can, the following information: + +- **Purpose**: a clear statement describing the area of WG's work +- **Roles and Responsibilities**: developed based on the guidance provided in this chapter +- **Infrastructure and Resources**: selected by WG to support their work +- **Guiding Principle**: suggestions are provided in the template document +- **Terms of Membership**: WGs can discuss and agree on appropriate terms and length of membership, such as for each role +- **Meetings and Communications**: details about WG meetings, and suggestions are provided in the template document + +(ch-working-groups-principles)= +## Reciprocity and Transparency in Decision-Making + +In addition, all WGs should ensure open communication of WG's practices and ways of working through: +1. **Reciprocity** within and towards the broader Turing Way community. +2. **Transparency in decision-making**. + +Below we share a few examples of questions that will help WG members in operationalising these practices. + +### Reciprocity + +All WGs within *The Turing Way* will foster reciprocal relationships with the wider community to promote cooperation, trust, and cohesion. +This involves supporting community members' engagement with topics or subjects related to the work of the WGs. + +To facilitate this, the WG should actively ask the following questions to identify information and knowledge to share with the community: +- Where in the WG's work can community members engage or contribute? +- Are there things that the WG is trying to do within a small group that the broader community can help with? +- Are there lessons the WG has learned that can be fed back to *The Turing Way* book and the wider community? +- What progress has the WG made that should be highlighted and shared more broadly? +- Are there places where feedback and active discussions with more members outside the WG can be invited? + +Recommendations and insights from answering these questions can be shared in the charter document. + +The active sharing and reciprocity can be maintained through engagement in various forms, including: +- Using Community Calls like the Collaboration Cafe for WG 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 WG 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 recommendation and guidance in the Community Handbook to promote how *The Turing Way* community works. +- Collaborating with existing WGs on projects related to infrastructure, accessibility, translation, or other themes. + +All WGs should be represented at (such as through the WG chair), and contribute to the *The Turing Way* Community Forums (such as by sharing updates and inviting new members to participate in their work). +Although it might not always be possible due to the time zones or other factors, all WG members are encouraged to attend these events. + +All WG activities should be documented transparently so that members outside the WG (including those not already engaging with *The Turing Way* community) can learn about the WG's activities and projects. + +The WG members should also ask the following questions (and more) when creating their process documentation: +- How can more community members join WG activities or start their own? +- How visible are various WG's activities for the rest of the community? +- How can transparent reporting invite more people to participate in the conversation? + +### Transparency in Decision-making + + + +In principle, primary decision-making should lie with the WG team itself. +However, there may be different types of decisions that might require input from different people across the community, project leadership and/or project delivery team for consultation and support. + +To identify where in their work a decision may or may not require inputs, support, or involvement from a specific party outside the WG, we recommend that WGs use the following questions when creating their documentation, and invite clarity from the project delivery team: + +- What decisions does the WG feel *empowered to take as an autonomous WG*? (for example, Accessibility WG develops accessibility guidelines) +- What decisions does the WG want to invite *consultation and support* from the broader community? (for example, Book Dash WG invites support from the community in planning their next agenda) +- What decisions should WGs involve *consultation and support* from the project delivery team? (for example, resource or support needed to execute a plan) +- What decision should be escalated to the leadership? (for example, Infrastructure WG will need input and approval when starting a new platform) +- What other decisions would WGs want to make that don't fall under the above three categories?