From Fedora Project Wiki
(Add Logic Model)
(update based on CommOps proposal in GDocs)
 
Line 3: Line 3:
Community Ops was born in Fedora in 2015. A lot changed in Fedora since then, and so has Community Ops. The goal of this effort is to rebuild the team with a focus on rising to the challenges that Fedora faces now in the 2020s.
Community Ops was born in Fedora in 2015. A lot changed in Fedora since then, and so has Community Ops. The goal of this effort is to rebuild the team with a focus on rising to the challenges that Fedora faces now in the 2020s.


 
= Purpose =
= Logic Model =
 
[[File:Logic Model - Community Ops 2024 Reboot.png|900px|thumb|center|alt=A logic model of the Community Ops 2024 Reboot Community Initiative. There are five columns: Inputs, Activities, Outputs, Outcomes, Impact.|Last updated on 12 January 2024]]
 
 
= Charter =
 
The team charter is the governance for Community Ops 2.0. These are the guiding principles for the team going through the process of a rebuild.


== Vision ==
== Vision ==


The Fedora Community Operations Team enables a highly-collaborative Fedora community ecosystem, where contributors thrive in achieving objectives of the Fedora 2028 strategy and friction in the contribution process can be identified and improved for Fedora contributors.
The Fedora Community Operations Team enables a highly-collaborative Fedora community ecosystem, where contributors thrive in achieving objectives of the Fedora 2028 strategy and friction in the contribution process can be identified and addressed for Fedora contributors.


== Mission ==
== Mission ==


The Fedora Community Operations Team achieves a highly-collaborative Fedora community ecosystem through two key areas: '''process improvement''', to partner with others in making the contribution process more open and transparent and '''community social analysis''', to better understand contribution pathways without prescribing a specific journey.
The Fedora Community Operations Team achieves a highly-collaborative Fedora community ecosystem through two key areas: process improvement, to partner with others in making the contribution process more open and transparent, and community social analysis, to better understand contribution pathways without prescribing a specific journey.


== Key directives ==
= Objective Leads =


These are the key areas of focus for the team, in detail.
* Co-Lead: [[User:Jflory7|Justin W. Flory]]
* Co-Lead: [[User:Rwright|Robert Wright]]
* Executive Sponsor: TBD


=== Process improvement ===
= Time-frame =


Fedora Community Operations helps other Fedora teams develop, document, and improve processes that can enhance the functioning of various teams. Community Operations contributors may contribute to other teams as a temporary embedded member, to help understand the team workflow and methods of participation. These Community Operations contributors then help the teams create documentation and guidance (e.g. “playbooks”) about their own existing processes, so they are transparent and clear to other contributors. Ultimately, Community Operations contributors work in concert with other teams to partner with them on process improvement, where the teams ultimately own the process.
Targeted completion within one month after Flock 2024 (i.e. September 2024).


=== Community social analysis ===
The success of this Initiative may or may not spur on a new follow-on Initiative after the completion of this Initiative.


Using data from various contribution pathways, the Fedora Community Operations Team will offer insights and recommendations to help teams plan for the future and make more data-driven decisions. The data would come from both quantitative and qualitative sources, such as the Fedora Messaging bus, annual community surveys, and other platform-specific metrics and data (e.g. GitLab, Pagure, Fedora Badges, Fedora Discussion, etc.). Specifically reviewing and analyzing this data enables the Community Operations team to provide unique insights to other teams and community stakeholders, to enable them to adapt and remain flexible amid a constantly-changing environment.
= Logic Model =


[[File:Logic Model - Community Ops 2024 Reboot.png|900px|thumb|center|alt=A logic model of the Community Ops 2024 Reboot Community Initiative. There are five columns: Inputs, Activities, Outputs, Outcomes, Impact.|Last updated on 12 January 2024]]


= Expression of Interest (EoI) =
== Expanded (full text) ==


Do you want to be a part a rebooted Community Operations team? Edit this wiki page and add your name and details to the table below. As we get closer to rebooting the team, this list will serve as the starting place for getting a group of motivated Fedora contributors together.
=== Inputs ===


{|class="wikitable"
* Past and current Community Operations members
|- style=" color: #fff; background-color: #3074c2;" tablewidth="98%"
* Fedora Join SIG members
| '''Name (nickname)''' || '''FAS username''' || '''Current participation in Fedora''' || '''Community Ops topics I am interested in''' || '''Other notes'''
* Fedora Marketing Team
|-
* Fedora Infrastructure
| Justin W. Flory (JWF) || [[User:Jflory7|jflory7]] || Council, Mindshare, DEI, some Websites & Apps || Data science, product operations, storytelling || I can help act as the team lead/chair, modernize our ticket tracker, and run regular meetings.
* Ambassadors and Advocates, both historical and aspirational
|-
* Matthew Miller (via velociraptorizer and brontosaurusifier)
| Hanku Lee (hank) || [[User:hankuoffroad|hankuoffroad]] || Documentation writer, Join SIG, Magazine writer || Data science, storytelling || I can help with data definition and analysis of metrics requirements
|-
| Robert Wright (rwright) || [[User: rwright | rwright]] || New || Product operations, Data Science || I can help bring Service Design strategies to product operations, and building data models / SQL.
|-
| Fernando F. Mancera (ffmancera) || [[User: ffmancera | ffmancera]] || Mindshare, packager || Product operations, storytelling || I can help with the product operations and with the storytelling.
|}


=== Activities ===


= What should Community Ops be? =
* '''Process Improvement:'''
** Write a new SOP about how to run virtual Fedora events.
** Review existing, documented best practices about contributing to Fedora. Propose improvements, where applicable. Unify existing content into a single resource to be used consistently across teams.
** Write 2-3 case study Community Blog posts about how a team collaborates in Fedora (e.g. Fedora Design workflow in GitLab, DEI Team workflow for meetings, etc.).
** Kickstart surveys as a function/capability of Community Ops.
** Execute the data governance framework created by the Community Social Analysis team, with a focus on asking questions that do not collect personally identifiable information.
** Documenting the process involved in creating a community-wide survey.
** Plan, execute, and promote the 2024 annual contributor survey.
** Run a newcomer onboarding clinic as a dedicated day and time where new contributors can come and ask for help on getting started in Fedora.
** Run planning calls for the Fedora Linux 40 and 41 Release Parties, starting two months before each event.
** Organize volunteer teams for the Release Party:
*** Graphic design & visual art
*** Event programming (e.g. content and scheduling)
*** Event infrastructure (e.g. Hopin, possibly Matrix/Jitsi)
*** Marketing & outreach
*** Media partner management
*** Project management (e.g. writing meeting agendas, sending reminders, doing follow-up tasks and emails, opening tickets, etc.)
*** Event support staff (e.g. moderators, Q&A wranglers, hype people)
** Create a LimeSurvey survey and interview a small group of contributors who both went through the Join SIG process or support as mentors. Collect feedback on strengths and weaknesses of existing processes.
** Invite five or more experienced Fedora contributors to help out in the Join SIG channel (either for fixed or indefinite terms).
** Implement and test 2-3 improvements to the Join SIG process, based on feedback surfaced from interviews.
** Create a template for Community Blog monthly reports on this month’s new contributors from the Join SIG. Include a place to identify active mentors.
** Publish new contributor reports for at least three months.
** Create a Fedora Badge for a mentor who is mentioned as an active mentor in the monthly reports.
* '''Community Social Analysis:'''
** Kickstart surveys as a function/capability of Community Ops.
** Provide guidance and define requirements for data governance of Fedora LimeSurvey surveys.
** Analyze and review survey responses. Publish a summarized report, raw data, or both on request of the survey requestor.
** Identify trends and questions that help to better understand community health.
** Create methods/scripts in Python to visualize subsets of data related to team needs / community health.
** Write Community Blog article(s) about findings to a specific question or group of questions (i.e. not a full report).
** Run a data contribution workshop that introduces Fedora tools for data, our data sets, and how to work with them.
** Kickstart analytics as a function/capability of Community Ops.
* '''All:'''
** Provide periodic updates on Initiative progress to the Fedora Council (e.g. monthly posts or video meeting updates).
** At the end of the Initiative, conduct an Initiative report that shares successes, failures, and recommendations for the next steps.


If Community Ops could only do three things, what should those things be?
=== Outputs ===


* '''Data science''': In the simplest terms, looking at our large pool of data and making insightful and actionable observations about Fedora, our community, and our software. This includes programmers (to use and build tools for data analysis), designers (to devise a publishing format and outreach strategy), writers (to document and write summaries and articles about the data), or anyone with a mix of these skills.
* '''Process Improvement:'''
* '''“Product operations”''': A team to handle unique requests that involve coordinating and working together with two or more community teams. Basically, a role for contributors who work in several different groups; Community Ops is a place where a wide network in the community becomes a superpower. A new Community Ops better enables cross-sectional collaboration. “Product operations” in quotes here because this may not be the best name for this kind of work.
** '''Documentation''': Existing documentation about newcomer onboarding is enhanced. New documentation is created about running a virtual Release Party, organizing community-wide surveys, user stories about team workflow, and a template for team onboarding health reports.
* '''Storytelling''': Making sure the important messages and stories about the Fedora community are being captured and told. This is a “culture” type of role that helps create a type of documentation that describes what it means to be in Fedora and who are the people behind it. There are some examples of how Community Ops did this in the past, [https://docs.fedoraproject.org/en-US/commops/latest/contribute/commops-landing/#_culture here] and [https://docs.fedoraproject.org/en-US/commops/latest/contribute/commops-landing/#_storytelling here].
** '''Documentation''': Create best practices for launching a new Fedora SIG or Working Group, maintained by the Community Operations team.
** '''Merge/Pull Requests''': Improving READMEs, documentation, and other first contact points for new contributors in the Join SIG.
** '''Fedora Linux 40 and 41 Release Parties''': A team of volunteers works together in executing the next two virtual Release Parties for a Fedora release.
** '''5+ active contributors from three time zone regions in Join SIG''': Five or more contributors across three major time zone regions participate in Fedora Join SIG channels. Monitored channels include Fedora Discussion and Fedora Chat.
** '''Contributor recognition''': A Community Blog series with a corresponding Fedora Badges series that recognizes contributors who participate in onboarding newcomers.
* '''Community Social Analysis:'''
** A data dictionary for Fedora.
** A hub for published datasets, visualizations, and data tools (e.g. Fedora People to start, something else later).
** A managed data infrastructure that can be supported long-term by Fedora Infra using tools and FOSS software (e.g. Python, Fedora Linux, containers).
** Select and implement a dashboard solution that extends the managed data infrastructure.
** Create a community health report to be shared by the Fedora Project Leader in the State of Fedora keynote at Flock 2024.


== 2023 June questions for consideration ==
=== Outcomes ===


* Could ''Data Science'' be another part of ''Storytelling''? What makes the two activities different?
* '''Process Improvement (phase 1 — onboarding):'''
* Should ''"Product Operations"'' instead focus on creating a "Changes" process unique to non-engineering teams of Fedora? What would this kind of work look like and who would do it?
** Anyone can discover accepted best practices for creating a new team effort in Fedora.
* Could Community Ops exist as an innovation incubator for emerging community ideas? This way, Community Ops is always helping projects move forward, but never fully owning them. We work with partners who will own the work, but who seek guidance and mentoring of Community Ops team members on how to shepherd changes in the Fedora community.
** Fedora Release Parties are celebrated virtual events that are organized by the community, for the community.
** The Fedora Join SIG is enhanced with improved documentation, new mentors, and an improved onboarding process based on real feedback from Fedora community members.
** Contributors who are mentors receive greater recognition and appreciation for their mentoring efforts.
* '''Community Social Analysis:'''
** There is a standard approach for working on data work in the Fedora community.
** More data-driven indications are available to indicate whether Fedora is on track to meet the 2028 Strategy.
** Community members have a forum to share ideas and requests for data analysis on a team or a component of Fedora.
** An exhaustive data source for contributors to start from.
** Gather data based on an agreed-upon standard of privacy that fits between the rights of users and the needs of the Fedora Project.
** Both Community Operations sub-teams are integrated (i.e. process improvement and community social analysis are linked).


--[[User:Jflory7|Jflory7]] ([[User talk:Jflory7|talk]]) 22:12, 1 June 2023 (UTC)
=== Impact ===


== 2023 August feedback from Flock workshop ==
* '''Fedora 2028 Strategy objectives:'''
** We have insight into community health and trends through meaningful metrics.
** More (active) SIGs, fewer images. (or, SIGs have useful, real work)


The items listed below came from sticky notes shared by participants in the Flock 2023 workshop for CommOps 2.0. These sticky notes came from an open-ended question where participants were asked to define what they thought CommOps was or should be, before any information was shared or presented to the audience about the team. So, this feedback is unprompted and mostly original based on whatever preconceptions people arrived with to our Flock workshop.


* Managing organizational & project processes
= Stakeholders =
* Support for community folks
(todo)
* Finding stuff-n-things (triage)
* Enhance Fedora community collaboration and effectiveness
* Execution on strategic plans (project management / PgM)
* Implement and provide feedback on Fedora Council policies
* Define and quantify the roles and responsibilities of CommOps team so as to remain focused and head off scope creep.
* Care and nurturing of the community
* Health and belonging in the community
* Ensuring member safety
* Inclusion programmes
* Code of Conduct
* Maintaining harmony
* Creating spaces for community discussion and interaction
* Communication
* Identifying the needs that are common across communities and addressing them from that broader perspective
* Manage chat platforms behind the scenes so people can meet and work easily in the community
* The cement between the bricks, OR the oil keeping the engine running
* Infrastructure contributor / user experience
* Politics and diplomacy
* Sociology and group dynamics
* Swag and funding
* Governance
* Partnering with bigger contributors
* Coordinating projects across multiple teams and making connections
* Event planning & promotion
* Facilitating meetups and processes for teams
* Conflict resolution
* Events
* Community advocacy towards Red Hat, or maybe Red Hat advocacy towards community (RH propaganda??)
* Building and maintaining systems and workflows for community releases
* Creating and updating governance processes
* Organize the community??
* Contributor journey
* Supports community members who are getting started in the project (technical, resources, etc.)
* Check-ins with groups
* Follow-ups
* Establishing SOPs
* Fingerposting: manned or unmanned
* Driving transparency
* General “glue work”
* Transparency
* Coordination of community and goals
* Manage cross-org infrastructures
** Community metrics
** Fedmsg
** Fedora blogs?
** Fedora policy docs?
* “Progress, not perfection.” To be a catalyst of wharever you interact with.
* Do not just talk (or write, or whatever).
* Statistics
* Responsible for contributor analytics
* A report on community health
* Establish an initiative to track new contributors through their first contributions and for a period after to determine if they are a drive-through/fly-by contributor
* Enhance engagement and diversity
* Recruit, mentor, develop
* CommOps supports the community by providing help in turning ideas into results
* Own the contributor funnel or lifecycle after the Join SIG stage
* CommOps brings together teams in Fedora, helping them to achieve goals which improve the community as a whole


= Relevant Links =
** 2023-04-24: [https://discussion.fedoraproject.org/t/roll-call-rebuilding-a-commops-team-in-2023/81527 Roll call! Rebuilding a Community Ops team in 2023?]


= What should Community Ops NOT be? =
== Wiki & Gitlab Links ==


If Community Ops could stop or not do three things, what should those things be?
== HackMD Docs ==


* '''Community Blog (CommBlog)''': The CommBlog editors should be an independent team from Community Ops. Looking back, I think our team’s purpose was washed out by the success of the CommBlog. People only knew Community Ops as the team of people who reviewed CommBlog posts. The blog grew and others took ownership of it, but Community Ops was still tied to it. Instead of Community Ops owning the CommBlog, Community Ops would help build a small team to help out with editing.
= History =
* '''App development''': This is a better fit for the Websites & Apps Team. Community Ops should avoid any app development and limit coding/software development only to explorational data science work. This ensures the Websites & App Team remains the best place in the project to go for working on websites and apps in Fedora, and Community Ops keeps “tech” contributions narrowed to data science work only.
* '''Fedora Ambassador “owner”''': Community Ops should not be the team responsible for Fedora Ambassadors. Community Ops may have a role to play in the administration of the Ambassadors program, but decision-making authority should rest with the Mindshare Committee. Since the 2020 Ambassador revamp, Community Ops is the supervisory team for the Fedora Ambassador and Advocate programs.


 
* '''2024-01-11''': Wiki page updated. Largely imported from Google Docs.
= Why now? =
 
Community Ops is special to me because I helped launch the team in 2015 with then-FCA Remy DeCausemaker and several others. When the team began, it had a specific vision on helping us work more effectively as a community and make sure that important areas of the contributor experience did not go unaddressed. In many ways, Community Ops was a working group for community issues in Fedora. However, people came and went and processes were forgotten. Over time, Community Ops began to mean something different to different people.
 
Community Ops was important and unique in its beginnings, because it was a team where both the Fedora Community Architect did many essential tasks and responsibilities in the public, but also together with a team. It was a unique team because anyone could help and contribute on community issues and make high-profile contributions in Fedora. (Heck, that is something I attribute to why I am in the role I am now.) I want a new Community Ops team because Fedora needs it now more than ever. We need to help each other collaborate and work together effectively and efficiently as a community of communities. This ties to our Four Foundations, which were the backbones of Community Ops from the beginning: Freedom, Friends, Features, First.
 
So, I have been in my role for just over six months. A lot of my time was spent listening, watching, and observing (in addition to hidden admin work required in the job). Now, I feel confident that we need a new Community Ops more than ever. But the question I have is, how do we do it? What does the community already know about Community Ops? Are there common needs across the community that a new Community Ops could serve? The first step in this process is to have this public conversation.
 
— [[User:Jflory7|Jflory7]] ([[User talk:Jflory7|talk]]) 16:48, 11 May 2023 (UTC)
 
 
= References & external URLs =
 
* '''Fedora Discussion topics''':
** 2023-04-24: [https://discussion.fedoraproject.org/t/roll-call-rebuilding-a-commops-team-in-2023/81527 Roll call! Rebuilding a Community Ops team in 2023?]

Latest revision as of 02:22, 13 January 2024

"CommOps 2.0" is an emerging, potential Community Initiative focused on rebooting the Community Operations (CommOps) team.

Community Ops was born in Fedora in 2015. A lot changed in Fedora since then, and so has Community Ops. The goal of this effort is to rebuild the team with a focus on rising to the challenges that Fedora faces now in the 2020s.

Purpose

Vision

The Fedora Community Operations Team enables a highly-collaborative Fedora community ecosystem, where contributors thrive in achieving objectives of the Fedora 2028 strategy and friction in the contribution process can be identified and addressed for Fedora contributors.

Mission

The Fedora Community Operations Team achieves a highly-collaborative Fedora community ecosystem through two key areas: process improvement, to partner with others in making the contribution process more open and transparent, and community social analysis, to better understand contribution pathways without prescribing a specific journey.

Objective Leads

Time-frame

Targeted completion within one month after Flock 2024 (i.e. September 2024).

The success of this Initiative may or may not spur on a new follow-on Initiative after the completion of this Initiative.

Logic Model

A logic model of the Community Ops 2024 Reboot Community Initiative. There are five columns: Inputs, Activities, Outputs, Outcomes, Impact.
Last updated on 12 January 2024

Expanded (full text)

Inputs

  • Past and current Community Operations members
  • Fedora Join SIG members
  • Fedora Marketing Team
  • Fedora Infrastructure
  • Ambassadors and Advocates, both historical and aspirational
  • Matthew Miller (via velociraptorizer and brontosaurusifier)

Activities

  • Process Improvement:
    • Write a new SOP about how to run virtual Fedora events.
    • Review existing, documented best practices about contributing to Fedora. Propose improvements, where applicable. Unify existing content into a single resource to be used consistently across teams.
    • Write 2-3 case study Community Blog posts about how a team collaborates in Fedora (e.g. Fedora Design workflow in GitLab, DEI Team workflow for meetings, etc.).
    • Kickstart surveys as a function/capability of Community Ops.
    • Execute the data governance framework created by the Community Social Analysis team, with a focus on asking questions that do not collect personally identifiable information.
    • Documenting the process involved in creating a community-wide survey.
    • Plan, execute, and promote the 2024 annual contributor survey.
    • Run a newcomer onboarding clinic as a dedicated day and time where new contributors can come and ask for help on getting started in Fedora.
    • Run planning calls for the Fedora Linux 40 and 41 Release Parties, starting two months before each event.
    • Organize volunteer teams for the Release Party:
      • Graphic design & visual art
      • Event programming (e.g. content and scheduling)
      • Event infrastructure (e.g. Hopin, possibly Matrix/Jitsi)
      • Marketing & outreach
      • Media partner management
      • Project management (e.g. writing meeting agendas, sending reminders, doing follow-up tasks and emails, opening tickets, etc.)
      • Event support staff (e.g. moderators, Q&A wranglers, hype people)
    • Create a LimeSurvey survey and interview a small group of contributors who both went through the Join SIG process or support as mentors. Collect feedback on strengths and weaknesses of existing processes.
    • Invite five or more experienced Fedora contributors to help out in the Join SIG channel (either for fixed or indefinite terms).
    • Implement and test 2-3 improvements to the Join SIG process, based on feedback surfaced from interviews.
    • Create a template for Community Blog monthly reports on this month’s new contributors from the Join SIG. Include a place to identify active mentors.
    • Publish new contributor reports for at least three months.
    • Create a Fedora Badge for a mentor who is mentioned as an active mentor in the monthly reports.
  • Community Social Analysis:
    • Kickstart surveys as a function/capability of Community Ops.
    • Provide guidance and define requirements for data governance of Fedora LimeSurvey surveys.
    • Analyze and review survey responses. Publish a summarized report, raw data, or both on request of the survey requestor.
    • Identify trends and questions that help to better understand community health.
    • Create methods/scripts in Python to visualize subsets of data related to team needs / community health.
    • Write Community Blog article(s) about findings to a specific question or group of questions (i.e. not a full report).
    • Run a data contribution workshop that introduces Fedora tools for data, our data sets, and how to work with them.
    • Kickstart analytics as a function/capability of Community Ops.
  • All:
    • Provide periodic updates on Initiative progress to the Fedora Council (e.g. monthly posts or video meeting updates).
    • At the end of the Initiative, conduct an Initiative report that shares successes, failures, and recommendations for the next steps.

Outputs

  • Process Improvement:
    • Documentation: Existing documentation about newcomer onboarding is enhanced. New documentation is created about running a virtual Release Party, organizing community-wide surveys, user stories about team workflow, and a template for team onboarding health reports.
    • Documentation: Create best practices for launching a new Fedora SIG or Working Group, maintained by the Community Operations team.
    • Merge/Pull Requests: Improving READMEs, documentation, and other first contact points for new contributors in the Join SIG.
    • Fedora Linux 40 and 41 Release Parties: A team of volunteers works together in executing the next two virtual Release Parties for a Fedora release.
    • 5+ active contributors from three time zone regions in Join SIG: Five or more contributors across three major time zone regions participate in Fedora Join SIG channels. Monitored channels include Fedora Discussion and Fedora Chat.
    • Contributor recognition: A Community Blog series with a corresponding Fedora Badges series that recognizes contributors who participate in onboarding newcomers.
  • Community Social Analysis:
    • A data dictionary for Fedora.
    • A hub for published datasets, visualizations, and data tools (e.g. Fedora People to start, something else later).
    • A managed data infrastructure that can be supported long-term by Fedora Infra using tools and FOSS software (e.g. Python, Fedora Linux, containers).
    • Select and implement a dashboard solution that extends the managed data infrastructure.
    • Create a community health report to be shared by the Fedora Project Leader in the State of Fedora keynote at Flock 2024.

Outcomes

  • Process Improvement (phase 1 — onboarding):
    • Anyone can discover accepted best practices for creating a new team effort in Fedora.
    • Fedora Release Parties are celebrated virtual events that are organized by the community, for the community.
    • The Fedora Join SIG is enhanced with improved documentation, new mentors, and an improved onboarding process based on real feedback from Fedora community members.
    • Contributors who are mentors receive greater recognition and appreciation for their mentoring efforts.
  • Community Social Analysis:
    • There is a standard approach for working on data work in the Fedora community.
    • More data-driven indications are available to indicate whether Fedora is on track to meet the 2028 Strategy.
    • Community members have a forum to share ideas and requests for data analysis on a team or a component of Fedora.
    • An exhaustive data source for contributors to start from.
    • Gather data based on an agreed-upon standard of privacy that fits between the rights of users and the needs of the Fedora Project.
    • Both Community Operations sub-teams are integrated (i.e. process improvement and community social analysis are linked).

Impact

  • Fedora 2028 Strategy objectives:
    • We have insight into community health and trends through meaningful metrics.
    • More (active) SIGs, fewer images. (or, SIGs have useful, real work)


Stakeholders

(todo)

Relevant Links

Wiki & Gitlab Links

HackMD Docs

History

  • 2024-01-11: Wiki page updated. Largely imported from Google Docs.
Retrieved from "https://fedoraproject.org/w/index.php?title=Initiatives/Community_Ops_2024_Reboot&oldid=698512"