History of the handbook

The handbook started two years after the CHAOSS project was established. We knew that undocumented processes and implicit knowledge were hindering new members from contributing and caused for unnecessary coordination. The handbook was created to capture the roles, responsibilities, and processes within the CHAOSS project and to make this knowledge available to everyone.

Advantages

At CHAOSS our handbook is new and keeping it relevant is an important part of everyone's job. It is a vital part of who we are and how we communicate. We established these processes because we saw these benefits:

1. Reading is much faster than listening.

2. Reading is async, you don't have to interrupt someone or wait for them to become available.

3. Recruiting is easier if people can see what we stand for and how we operate.

4. Retention is better if people know what they are getting into before they join.

5. On-boarding is easier if you can find all relevant information spelled out.

6. Teamwork is easier if you can read how other parts of the community work.

7. Discussing changes is easier if you can read what the current process is.

8. Communicating change is easier if you can just point to the diff.

9. Everyone can contribute to it by proposing a change via a pull request.

Flow structure

1. A (process) problem comes up, frequently in an issue or chat.

2. A proposal is made in a pull request to the handbook.

3. Once merged, the change is announced by linking to the diff in the pull request or commit. Major ones are put in the agenda of the monthly call. Medium ones are posted on the mailing list for visibility, with a one line summary of the change. If there was an issue, close it out with a link to the diff.

Why handbook first

Documenting in the handbook before taking an action may require more time initially because you have to think about where to make the change, integrate it with the existing content, and then possibly add to or refactor the handbook to have a proper foundation. But, it saves time in the long run, and this communication is essential to our ability to continue scaling and adapting our organization.

This process is not unlike writing tests for your software. Only communicate a (proposed) change via a change to the handbook; don't use a presentation, email, chat message, or another medium to communicate the components of the change. These other forms of communication might be more convenient for the presenter, but they make it harder for the audience to understand the context and the implications for other potentially affected processes.

Having a "handbook first" mentality ensures there is no duplication; the handbook is always up to date, and others are better able to contribute.

Handbook guidelines

Please follow these guidelines and remind others of them.

How we use the guide every day

1. Most guidelines in this handbook are meant to help, and unless otherwise stated, are meant to help more than being absolute rules. Don't be afraid to do something because you don't know the entire handbook, nobody does. Be gentle when reminding people about these guidelines. For example say, "It is not a problem, but next time please consider the following guideline from the handbook."

2. If you ask a question and someone answers with a link to the handbook, they do this because they want to help by providing more information. They may also be proud that we have the answer documented. It doesn't mean that you should have read the entire handbook, nobody knows the entire handbook.

3. If you need to ask a community member for help, please realize that there is a good chance the majority of the community also doesn't know the answer. Be sure to document the answer to radiate this information to the whole community. After the question is answered, discuss where it should be documented and who will do it. You can remind other people of this request by asking "Who will document this?"

4. When you discuss something in chat always try to link to a URL where relevant. For example, the documentation you have a question about or the page that answered your question. You can remind other people of this by asking "Can you please link?"

5. Remember, the handbook is not what we hope to do, what we should formally do, or what we did months ago. It is what we do right now. Make sure you change the handbook in order to truly change a process. To propose a change to a process, make a pull request to change the handbook. Don't use another channel to propose a handbook change (e.g., email, Google Doc, or weekly call).

6. The handbook is the process. Any sections with names like 'process', 'policies', 'best practices', or 'standard operating procedures' are an indication of a deeper problem. This may indicate a duplication between a prose description of a process and a numbered list description of the same process that should be combined in one description of the process.

7. When communicating something always include a link to the relevant (and up-to-date) part of the handbook instead of including the text in the email/chat/etc. You can remind other people of this by asking "Can you please link to the relevant part of the handbook?"

How to change or define a process

1. To change a guideline or process, suggest an edit in the form of a pull request. After it is merged you can talk about it during the weekly call if applicable. You can remind other people of this by asking "Can you please send a pull request for the handbook?"

2. Communicate process changes by linking to the merged diff (a commit that shows the changes before and after). If you are communicating a change for the purpose of discussion and feedback, it is ok to link to an unmerged diff. Do not change the process first, and then view the documentation as a lower priority task. Planning to do the documentation later inevitably leads to duplicate work communicating the change and it leads to outdated documentation. You can remind other people of this by asking "Can you please update the handbook first?"

3. Like everything else, our processes are always in flux. Everything is always in draft, and the initial version should be in the handbook, too. If you are proposing a change to the handbook, whenever possible, skip the issue and submit a pull request. (Proposing a change via a pull request is preferred over an issue description). Mention the people that are affected by the change in the pull request. In many cases, pull requests are easier to collaborate on since you can see the proposed changes.

4. If something is a limited test to a group of users, add it to the handbook and note as such. Then remove the note once the test is over and every case should use the new process.

5. If someone inside or outside CHAOSS makes a good suggestion invite them to add it to the handbook. Send the person the url of the relevant page and section and offer to do it for them if they can't. Having them make and send the suggestion will make the change and will reflect their knowledge.

6. When you submit a pull request, make sure that it gets merged quickly. Making single, small changes quickly will ensure your branch doesn't fall far behind master, creating merge conflicts. Aim to make and merge your update on the same day. Mention people in the pull request. If you get a suggestion for a large improvement on top of the existing one consider doing that separately. Create an issue, get the exiting pull request merged, then create a new pull request.

7. If you have to move content have a pull request that moves it and does nothing else. If you want to clean it up, summarize it, or expand on it do that after the moving pull request is merged. This is much easier to review.

8. Try to add the why of a handbook process, what is the goal, what is the inspiration for this section. Adding the why makes processes easier to change in the future since you can evaluate if the why changed.

Style guide and information architecture

1. Single Source of Truth Think about the information architecture to eliminate repetition and have a Single Source of Truth (SSoT). Instead of repeating content cross-link it (each text has a hyperlink to the other piece). If you copy content please remove it at the origin place and replace it with a link to the new content. Duplicate content leads to having to update it in multiple changes, which is a lot of work and very easy to forget. If you forget one of the pieces of content is out of date.

2. Make sure to always cross-link items if there are related items (elsewhere in the handbook, in docs, or in issues).

3. The handbook is organized by function and result to ensure every item in it has a location and owner to keep it up to date. It's essential that we adhere to this hierarchy and that we not maintain separate structures for training materials, videos, or other documentation.

   • At times, a change of perspective may be desired. In those cases, link to relevant sections of the handbook liberally.

   • Avoid unstructured content based on formats like FAQs, lists of links, resource pages, glossaries, courses, videos, tests, or how-to's. These are very hard to keep up-to-date and are not compatible with organization per function and result.

   • Instead, put the answer, link, definition, course, video, or test in the most relevant place. Use descriptive headers so that people can easily search for content.

   • That said, please mix formats where and when appropriate in the handbook, even within a single page. Utilizing multiple formats can be valuable, and different people may prefer certain formats over others.

   • Worry only about the organization per function and result, not about how the page will look if you embed varying types and formats of content.

4. Use headers liberally. If a page includes more than two headers (especially if it's larger than a single "screen"), add a Table of Contents (ToC).

   • Headers should have normal capitalization: don't use ALL CAPS or TitleCase).

   • Before a header, leave two blank lines; after a header, leave one blank line; this is not required in the standard, but it is our convention.

5. KISS principle Keep your handbook pages short and succinct. Eliminate fluff and get right to the point with the shortest possible wording.

Scope of this handbook

• All documentation that also applies to code contributions from the wider community should be in the GitLab CE project (for example in CONTRIBUTING or the code review guidelines), not the Handbook, which is only for team members. Read more in the Documentation section of the Handbook.

• The handbook is for things concerning current and future GitLab team members only. If something concerns users of GitLab, it should be documented in the GitLab documentation, the GitLab Development Kit (GDK), the CONTRIBUTING file or the PROCESS file.

Attribution to GitLab's Handbook

The idea of the handbook originated from GitLab's Handbook. In the spirit of open source, we have copied some passages from GitLab's Handbook.

Just like the rest of our work, we continually adjust our values and strive to make them better. The CHAOSS values are a living document. In many instances, they have been documented, refined, and revised based on lessons learned in the course of working effectively and efficiently.

So this section is our core which reflects how we organize ourselves, community guidelines, community ethics, all the way down to how we invest in ourselves!

Everyone is welcome to suggest improvements.

CHAOSS community is a value-driven organization and here is what we believed in:

🌱 Community Health

Our goal is focused on creating software and metrics to help define community health. We are also interested in having a “healthy” CHAOSS community where people have an interest in keeping the project going, helping others to participate, responding to community challenges, developing new innovations, and so forth. We can’t achieve these things without the help of everyone, creating sustainability for our metrics, software, and people in the working groups.

👐 Openness

Openness is the key to any open source project. Work in the CHAOSS community is primarily organized around software and metrics. Additionally, user groups provide ways to consider how software and practices can support the deployment of CHAOSS metrics. Following through the definition of the openness, The CHAOSS community is dedicated to fostering an open and welcoming environment for all people. Anyone can join the mailing list, participate in Zoom meetings, or contribute to any of our projects on GitHub at any time! We strive to be open!

👁 Transparency

Being transparent about as many things as possible is an aim for the open source ecosystem. By making information public, we reduce the threshold to contribution and make collaboration easier. We appreciate the use of public issue trackers, projects, and repositories on GitHub when possible.

We make information public by default because transparency is one of our values. As such, a large category of CHAOSS information is public unless there is a reason for it not to be. We have CHAOSS community calls and working group meetings every week and we welcome everyone, who is not only within the core team but also who has keen interests to participate and support our structure.

When information is not public, it may also be treated as limited access, only shared with certain CHAOSS community members.

🌐 Diversity, Inclusion & Belonging

Diversity, inclusion, and belonging are fundamental to the success of the CHAOSS community. We aim to make a significant impact on our efforts to foster an environment where everyone can thrive. We take a positive approach to ensure that the CHAOSS community is a place where all people can belong and contribute. We actively reflect on a culture that is inclusive and supports everyone equally in the process of achieving their goals. We continually work to welcome and support everyone in our community.

We are consistent, over time, with metric and software development. This consistency helps us to maintain the momentum of the project and the improvements within that. Consistency requires the following things:

• Commitment. We are dependable, reliable, and responsible for our decisions and actions. We’re committed to long-term success and we prefer not taking shortcuts.

• Empowerment. We encourage building skills and spaces that help us focus on our goals.

• Mindfulness. We prefer momentum while remembering our mission. We encourage regular feedback and happily learn from our mistakes.

We maintain community health by providing ways for others to contribute to and use CHAOSS metrics and software. With support from a wide variety of people, we are a diverse, inclusive, and growing community where all people have equal opportunities to contribute.

Earning trust in our open source community is essential. Building trust takes time, concerted effort, and an environment where everyone can contribute. We work to stabilize the development of strong community bonds, the safety and privacy of all, and an environment where people contribute to our project at a personal level.

Work in the CHAOSS community is organized around software and metrics. Stemming from these, CHAOSS programs and user groups provide ways to consider how CHAOSS metrics and software can support the ways that we understand open source community health. As organizations and communities have been utilizing the CHAOSS work to measure the health of their respective communities, our metrics and software are demonstrating utility in ways that help in improving the open source community health for all.

The CHAOSS Community Handbook is a central repository for how we run the project. As part of our value of being transparent, the handbook is open to the world and we welcome feedback. Please make pull requests to suggest improvements or add clarifications. Please use issues to ask questions.

The published version of the Community Handbook can be found at https://handbook.chaoss.community/.

ABOUT

COMMUNITY

CONTRIBUTING

MENTORSHIPS

Evolution of CHAOSS at Open Source Sumit North America

There was a meeting at the Linux Foundation Leadership Summit which is now known as the member summit. It started from the whiteboard in the room where some groups of people planned to talk about community health. There were many interests from the people and there were folks from the Open Source program Office and different foundations. Concluding through the community health discussions, it leads to the evolution of CHAOSS at Open Source Summit North America 2017

Bitergia extends its hands to help CHAOSS during their origin

Bitergia was formed in 2012 by a group of folks who were researching around community metric system and health. So Bitergia came forward to support the CHAOSS by providing various insights and metrics including a project(GrimoireLab) which they thought about donating or moving under the Linux Foundation. So after making fair research around metrics and the toolsets which could support the vision, it was decided to get these together and build the academics to study this phenomenal and formalize it whereas Bitergia on the other hand has the tools, providing professional services around The Linux Foundation. So all got together to participate in this project and worked several weeks and months on establishing it. Later the Grimoirlab became part of the CHAOSS community.

Linux Foundation involvement during the CHAOSS evolution

Some folks present at Open Source Summit North America from the Linux Foundation were keen to measure the community health issues and they started with the discussions of needing the metric mechanism, talking with various folks. It was not expected that someone would join the other people to discuss this topic but there were huge interests and folks after collaborating started with the CHAOSS as a Linux Foundation project.

Formation of Diversity & Inclusion Working Group

Diversity and Inclusion are known to challenge unchecked assumptions and lead to more open and fair collaboration practices. Since diversity and inclusion are central to the health of open source communities so the CHAOSS Diversity & Inclusion (D&I) Working Group was formed, aiming at bringing experiences to measure diversity and inclusion consistently across open source projects, supported by software where possible.

Formation of Evolution Working Group

An OSS community goes through stages of Evolution. The state that a community is in may prove important when evaluating both across and within community concerns So evolution working group was formed to focus on the lifecycle of open source projects.

Formation of Risk Working Group

The Risk working group was formed to focus on metrics for issues pertaining to risk in open source. The Risk metric informs how much risk an OSS community might carry or pose.

Formation of value Working Group

Value group was formed to develop the metrics that, when measured, help make the impact of community work more transparent. Developers and organizations capture value from engaging in OSS communities. This set of metrics can inform what this value is.

Start of CHAOSScon conference

CHAOSScon evolved from the Grimoirecon which Bitergia had been organizing before it became a part of CHAOSS in 2017, and the time when the Bitergia joined the CHAOSS, there were discussions to have the CHAOSS conference altogether. 1 year later when the Grimoirelab conference was organized it was initially called as CHAOSScon + Grimoirecon after the discussion but later it was just called as CHAOSScon because comunity thought that it was important for the individual projects to have its conference where they could Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work.

Open Source Community Health

The potential that an open-source software community continues developing quality software.

Code Review

It is a software quality assurance activity under the CHAOSS that consciously and systematically convenes with one’s fellow programmers to check each other’s code for mistakes, and shows acceleration and streamlines towards the process of software development by following best practices.

Open Source Software Metric

Without data, you're just a person with an opinion

-- , Statistician

The open-source software metric within the CHAOSS project is a documented way of measuring and tracking the success of any open-source software/community.

Metric Release

The release of CHAOSS metrics represents the published work being done by CHAOSS Metrics Working Groups. The metrics are officially released biannually following a 30 day comment period. .

Focus Area

The focus area is a set of goals around which any open source software metric is defined. Inside CHAOSS, there are different Working Groups who have defined their own focus area around specific metrics.

CHAOSScon

Working Groups around Metric

Common Metric

The group that focuses on defining the metrics that are used by both working groups or are important for community health, but that does not cleanly fit into one of the other existing working groups.

Diversity & Inclusion

The group that aims to bring together experiences measuring diversity and inclusion in open source projects.

Evolution

The group which focusses on refining the metrics that inform evolution and to work with software implementations.

Risk

The group which focuses on compliance and risk metrics.

Value

The working group that focuses on industry-standard metrics for economic value in open source.

Working Groups around Software

GrimoireLab

This working group connects the GrimoireLab software development with metrics work in other CHAOSS working groups.

Augur

This working group connects the Augur software development with metrics work in other CHAOSS working groups.

Cregit

This working group connects the Cregit software development with metrics work in other CHAOSS working groups.

Working Groups around User Groups

Application Ecosystem

This working group applies CHAOSS metrics in the context of an open-source app ecosystem. The mission of this working group is to build a base set of metrics that is focused on the needs of open source communities that are part of the FOSS app ecosystem.

Diversity & Inclusion Badging

The working group that encourages projects and events to obtain D&I badges for reasons of pride, leadership, self-reflection, and self-improvement on issues critical to building the Internet as a social good.

CHAOSS Project

A Linux Foundation open source project that advances our understanding of and tools for open source community health. Check out the

Contributor

Any person who participates in and contributes to the CHAOSS community.

Organization

An organization represents a company or legal entity in the world engaging with the CHAOSS project.

Community

A community is the people who share a common interest. The CHAOSS community consists of various diverse people who work on different interests related to open source community health.

Community Members

A self-selected group of people who associate with the CHAOSS Community, no contribution required.

Core Contributors

The people who are major contributors to CHAOSS through long-term participation in any working group.

Maintainer

A contributor who has the ability to commit directly to a project’s repository and are responsive to contributions or changes from other Contributors. Maintainers are listed in the README of each repository.

Working Groups

A group of people working together to achieve a specific goal. Within the CHAOSS community, these are established and maintained by project contributors to advance project work. Working Groups focus on a specific metric, methodological, ethical, and technical issues associated with open source community health.

Governance Board

The Governance Board is responsible for the overall oversight of the CHAOSS Project and coordination of the efforts of any Technical Committees and Working Groups inside the CHAOSS community.

Event Attendee

People who register to attend a CHAOSS Project event.

CHAOSScon Organizing Committee Member

A person who is a part of the organizing team of the CHAOSS conference - CHAOSScon.

CHAOSS Metric Release Collaborator

The people who work for the successful release of metrics by coordinating with working groups and releasing it under the CHAOSS website.

Mailing List Moderator

A person within the community that takes care of the moderation mail list requests.

CoC Enforcement Team Member

A person who responds to the CoC incident reports made on the mailing list.

Twitter Manager

Repository Maintainer

• Send a reminder about meetings

• Prepare meetings

• Lead meetings

• Make sure meeting minutes are kept

• Facilitate the creation and advancement of metrics/software

• Answer questions about the history of the working group and metrics/software

• Coordinate with other working groups on metrics/software

• Report on weekly community call progress in the working group

• Submit working group related topics to conferences

• Review issues on the repository

• Review and merge pull requests

• Regularly check the repository for stale content

• Coordinate metrics release for the working group

• monitor issue tracker and pull requests

• steer the architecture of the metrics/software

• Regularly review the status of planning progress

• Secure venue for the event

• Secure catering for the event

• Set up CFP for event

• Promote CFP for event

• Review CFP submissions and select talks

• Build an agenda for the event

• Coordinate with speakers that they are coming

• Collect and upload slides from speakers

• Make sure we have signage at the event

• Secure funding from sponsors

• Create and update conference website

• Edit recordings from CHAOSScon sessions and upload them to YouTube

• Consider the high-level strategy for the CHAOSS project

• Participate in board meetings (~4 meetings per year) and vote on proposals.

• Participate in email votes if called (outside of board meetings).

• Represent concerns of community members at board meetings.

• Attend monthly meetings to stay up to date with what is happening

• Spread the word about CHAOSS, e.g., present at conferences.

• Be a representative of the CHAOSS project.

• Invite to board meetings

• Prepare board meetings

• Attend and participate in board meetings

• Advance and execute community strategy

• Maintain communication with Linux Foundation

• Regularly review and update governance documents

• Provide guidance to community members and working groups

• Review metrics release spreadsheet

• Coordinate with working groups to confirm the status of metrics

• Double-check formatting on metrics

• Create release notes

• Tag release in working group repositories

• Create release pages on the website

• Create a PDF of released metrics

• Collect themes from a week in the CHAOSS community - attend several meetings, especially community call

• Write a summary of what is happening in the CHAOSS community

• Update the dates of upcoming meetings

• Send CHAOSSweekly to the mailing list

• When a moderation request comes in, react to it

• Like and re-tweet tweets about @CHAOSSproj that are relevant

• Share status updates from @CHAOSSproj

• Promote CHAOSS events

(luckily we have had no reports yet)

• monitor mailing list to which reports can be made

• respond to reports

Mentor (e.g., GSoC or Outreachy)

• Submit project ideas

• Respond to interested students

• Regularly meet with accepted mentees

• Help mentees get started with the CHAOSS project and technologies

• Report to the CHAOSS community how things are going with the mentees

Contributor

• post ideas for new features as issues

• create pull requests for code changes

• respond to reviews from maintainers on pull requests

New Member

• Attend community and workgroup meetings

• Register for mailing lists

• Try to find ways to help

• Catch up on GitHub and other tools used by CHAOSS

• See how you can align what you do elsewhere with what goes on in CHAOSS

• Ask questions about CHAOSS and what is being worked on

Organization Administrator

The members of the CHAOSS community who manage CHAOSS's participation in various programs like , , and .

Mentors

Mentors are people from the CHAOSS community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student contributors integrate into their project’s community. CHAOSS community has mentors helping in , , and .

Mentee/Student

Mentees are the aspirants who participate under the CHAOSS community through open-source programs like , , and .

CHAOSS Mentorship Alumni

CHAOSS Mentorship Alumni is a directory as a specific page on the CHAOSS website which hosts the records of all the mentees who have worked with CHAOSS in any of the open-source programs in the past. ****

This roadmap is our strategic plan that defines our goal or desired outcome and includes the major milestones that are needed to reach it.

Metrics

The CHAOSS Metrics Committee defines implementation-agnostic metrics for assessing open source communities' health and sustainability. The CHAOSS Metrics Committee's goals are to establish implementation-agnostic metrics for measuring community activity, contributions, and health; and optionally produce standardized metric exchange formats, detailed use cases, models, or recommendations to analyze specific issues in the industry/OSS world.

Metric Releases

The Working Groups within the CHAOSS are focused on releasing new metrics where metrics are identified and defined using a continuous contribution process. The metrics are officially released biannually following a 30 day comment period.

Software Releases

The software committee within the CHAOS community is focused on producing integrated open source software for analyzing software community development across the metric mechanism.

Working Groups

The working group aims to bring together experiences measuring common metrics, diversity and inclusion, evolution, risk, and value in open source projects. Its main goal focuses on understanding from a qualitative and quantitative point of view how different things can be measured within the community.

Things you should take into Consideration

Be welcoming and open-minded - Other collaborators may not have the same experience level or background as you, but that doesn't mean they don't have good ideas to contribute. We encourage you to be welcoming to new collaborators and those just getting started. We value, encourage all types of contributions. We don’t assume you can contribute for free, we respect and thank you.

Be honest - Being honest helps you to move to better consensus building. So Be honest about who you are, what you do, and how you want to do it. Dishonesty is not only damaging to you but to all other community members and their valuable contributions. Don’t be the one bringing mistrust into this community.

Be respectful - We don't tolerate being disrespectful. Being a jerk will not get you a place in this community, it will turn people away so we don’t want noise in the system. Be civil and professional, and don’t post anything that a reasonable person would consider offensive, abusive, or hate speech. Don’t harass or grief anyone. Treat each other with dignity and consideration in all interactions.

Be collaborative - Collaboration reduces redundancy and improves the quality of our work. Internally and externally, we celebrate good collaboration. Wherever possible, we work closely with upstream projects and others in the free software community to coordinate our efforts. We prefer to work transparently and involve interested parties as early as possible.

Be mindful and stay on topic - People use the CHAOSS project for creating analytics and metrics to help define the community health. So off-topic comments are sometimes unproductive while collaborating. Staying on topic helps produce positive and productive discussions. Additionally, communicating with strangers on the Internet can be difficult. It's hard to convey or read tone, and sarcasm is frequently misunderstood. Try to use clear language, and think about how it will be received by the other person.

Be inclusive - Everyone within the community has the right to speak to any decision taken. You should have the freedom to participate in different decisions and actions taken within the community publically and put forward your perspective. Adding your perspective will result in a more broad outcome towards that decision. Whoever you are, you have a unique perspective and unique skills that you can contribute to a collective.

Be focused - We value community people's time and perspective so If you need to decide or propose something as a team or individual, make a concrete proposal with directing the focused area more clearly instead of calling a meeting to get everyone's input. Having a proposal will be a much more effective use of everyone's time.

Share the love - We should be appreciable for any decision/idea proposed within the community and should share some love by appreciating it. If someone achieves something within the community then share it on your social handles with your friends, let the world know, and receive some love in return.

What is not Allowed?

• Threats of violence - You may not threaten violence towards others or use the site to organize, promote, or incite acts of real-world violence or terrorism. Think carefully about the words you use, the images you post, and even the software you write, and how they may be interpreted by others.

• Sexually obscene content - The use of sexualized language or imagery and unwelcome sexual attention or advances

• Bullying - Trolling, insulting/derogatory comments, and personal or political attacks

• Harassment - Public or private harassment

• Invasion of privacy - Publishing others' private information, such as a physical or electronic address, without explicit permission

• Misinformation - Other conduct which could reasonably be considered inappropriate in a professional setting

What happens if someone breaks the rule?

We have developed some terminology to describe the interaction and roles within the CHAOSS community. Please understand and use these terms to overcome any conflicts

What does leadership mean to the CHAOSS community?

A leaderis someone who has specific decision-making power over some part of a group and thus additional accountability and can help with prioritizing and planning activities in the project.

I think that a leader in the CHAOSS community is someone who helps advance the project by contributing directly and coordinating work with others. Leaders should regularly attend the weekly community meetings to report on the work of their respective working group.

-- , Director of Sales at Bitergia; Cofounder of CHAOSS

Leadership sets the tone for the culture, values, and communication style for everyone else. I think a CHAOSS leader (whether it be informal or formal) should embody and foster empathy, compassion, and respect for everyone else working on the project, no matter in what capacity. I think that being an excellent communicator and having a passion for helping open source projects prioritize and measure their community's health is also helpful.

-- , Community manager at CHAOSS

Why is leadership important to us?

We are a volunteer-drivenorganization which means the work within the CHAOSS community is focused around the creation of metrics and software which depend upon the contributions made by external individuals and communities. We need people to direct the vision of creation, planning, and architecture of new initiatives within the community in order to drive through the better objectives.

How to become a leader?

Technical Leadership

Leadership that focuses on building amazing projects and good engineering teams across the community

Checklistbefore becoming a Maintainer

• Makes consistent contributions within the CHAOSS community

• Has the ability to commit directly to a project repository

• Holds knowledge of working groups, metrics, and software

• Attends community meetings

• Holds good knowledge in helping others achieve their goals

• Has knowledge of Git and GitHub

• Understands the workflow of the Issues and Pull Requests

• Ability to troubleshoot website issues

• Strong attention to detail with an analytical mind and outstanding problem-solving skills

• Excellent content creation and writing skills.

• Proficient in GitHub, Markdown, HTML, CSS design, cross-browser and cross-platform compatibility, and JavaScript

• Excellent written and communication skills in English

• Ability to translate highly technical information into easily understandable information for other community members and end-users

• Keeping the content across the repositories and other platforms updated

• Critical thinker and problem-solver

Governance Leadership

Leadership involved in the process of decision making within the community

• Long term and consistent contributor within the CHAOSS project

• Involved with the software or metric working groups

• Experience in a managerial/directorial position

• Holds knowledge and interest in the CHAOSS project

• Holds critical thinking and problem-solving abilities and can provide thoughtful input to the project

• Excellent Knowledge of performance evaluation techniques and key metrics

Operation Leadership

Leadership that addresses every aspect of the community model

• Prior technical community management experience

• Self-motivated with the ability to manage multiple competing priorities

• A growth mindset and an approach to new information and knowledge with curiosity

• A challenge seeker who desires and readily takes on new challenges and works towards solutions

• An understanding of how contemporary open source projects function

For clear and consistent communication, it’s important to always use the correct terminology. Remember:

• If you’re unsure which term to use, look for existing terminology

• Never create a new term when an existing one is available to you.

• Be extremely cautious when using jargon words They can confuse new users and cause problems with internationalization.

Capitalization

The below terms are used as a proper noun (name) for a specific role or entity. Please capitalize on the following terms in the documentation and in the app

Example: GrimoireLab is a CHAOSS toolset for software development analytics.

• Augur

• Cregit

• CHAOSS

• CHAOSScon

• CHAOSScast

• CHAOSSweekly

• CHAOSSblog

• CHAOSStube

• Google Summer of Code

• Google Season of Docs

• GrimoireLab

• Outreachy

The below words are used a lot in common language and don't need to be capitalized all the time, but when referring specifically within the documentation it is like a proper name, so it can be capitalized to better communicate what you mean.

Example: CHAOSS metrics are sorted into Focus Areas.

• Code of Conduct

• Common Metric

• Contributor

• Diversity & Inclusion

• Evolution

• Focus Area

• Governance Board

• Mentors

• Mentee

• Metric

• Metric Release

• Open Source Community Health

• Organization Administrators

• Risk

• Value

• Working Groups

Abbreviations

You may find the words written within the documentation, website, or Github repositories in the abbreviated form. Below are the words with their full forms:

• CHAOSS - Community Health Analytics Open Source Software

• WG - Working Group

• D&I - Diversity and Inclusion

• GB - Governance Board

• CoC - Code of Conduct

• GSoC - Google Summer of Code

• GSoD - Google Season of Docs

• LF - The Linux Foundation

👥 CHAOSS Metrics Committee

The CHAOSS Metrics Committee defines implementation-agnostic metrics for assessing open source communities' health and sustainability. The CHAOSS Metrics Committee's goals are to establish implementation-agnostic metrics for measuring community activity, contributions, and health; and optionally produce standardized metric exchange formats, detailed use cases, models, or recommendations to analyze specific issues in the industry/OSS world.

✍ Process of getting metric approved to be visible on the website

• We already have many metrics listed under various working groups but you can also propose your own metric if you don't find listed in the existing metrics. Here is the list of all the existing metrics within CHAOSS

• There are different working groups that foster around their focus areas. So once you have a valid plan for your metric, we find a working group that is best aligned and has an interest in the metric.

• We add the metric to our Metrics Tracking Sheet

• Someone writes a draft for the metric using our Template for Metric using google docs. The person proposing the metric could do this.

• The working group discusses the metric and makes the required changes.

• A markdown version of the metric is added to the working group repository.

• The metric is ready for the Continuous Metric Contribution and Regular Release

When should a previously released metric be returned to community review?

• Whenever there is a language or terminology change that would affect other metric references.

• Changing the name of a metric (in any way)

• Any changes that go beyond grammar or spelling fixes in the sections:

  • Question

  • Definition

  • Objectives

  • Implementation

• Does not require review:

  • Grammar or spelling fixes (not including metric name)

  • Updates to sections References and Contributors

🧐 Some Metric Useful Resources

• Metrics Definitions

• Metric Release History

• Metric Repository

• Metric Template

• Metrics Tracking Sheet

• Continuous Metric Contribution and Regular Release

What is CHAOSS?

CHAOSS is a Linux Foundation project focused on creating analytics and metrics to help define community health. Read more about CHAOSS

What does CHAOSS stand for?

CHAOSS stands for Community Health Analytics Open Source Software.

What is the metric?

A metric is a documented way to measure open source community health. CHAOSS community has its own predefined template for proposing any new metric. It is quite possible to bring together different metrics in a system of measurement that is meaningful for a particular context.

Why does Community Health matter?

In order to understand why Community Health matters then please refer to the "Why Create CHAOSS?" section on the About page

What does Community Health mean?

Community health is a specialty that focuses on the well-being of the people in a specific community. This important subsection of community health includes initiatives to help community members maintain and improve their health, helping them to know where they should place their efforts and know that they are making an impact.

How do I get involved?

We have various ways to get involved in the Community. You can check our Participation page. If you want to contribute directly, we have specified the different ways by which you can engage with the community in design, development, documentation, and outreach.

How do I use your software?

In order to use CHAOSS software, you can follow the guidelines here

Is my open source community healthy?

We have the initiative of generating the CHAOSS Community Report for your project. So, if you want to measure, whether your community is healthy or not, you can follow the instructions to generate your community reports

Who is behind the CHAOSS project?

CHAOSS project is a volunteer-driven project where there are folks from different organizations and communities effectively working to build creative solutions under CHAOSS. In order to know more refer "Who are we?" section on the About page

Do you have internships?

We don't have specific internships instead we participate in various open source mentorship programs like GSoC, Outreachy, etc.

How can I assess the health of my community?

You can assess the health of your community by submitting the details under "Submit Your Community Health Report Request"

Where can I find the relevant metric I am looking for?

All the metrics can be found under the "Metric Definition" on the CHAOSS website

What is D&I badging?

The Diversity and Inclusion Badging program use a peer-review system to encourage projects and events to obtain badges. It aims to increase understanding of the open-source project and event practices that encourage greater diversity and wider inclusion of people from different backgrounds.

The program is affiliated with the CHAOSS project and a proud initiative of CHAOSS. Most of the work of the Badging Program is closely associated with the CHAOSS D&I working group. You can read more about it here

Does CHAOSS provide any tools to measure the open source project or community health?

Yes, the CHAOSS has three projects with assigned toolset named Augur, GrimoireLab, and Cregit

Who are the maintainers of the CHAOSS?

Every repository under the CHAOSS GitHub has the "Repo Maintainers" section which contains all the names of the maintainers for the respective repositories.

Whom should I contact if I have any questions?

We encourage transparency, openness, and healthiness so all the questions should be directed to the public community mailing list at chaoss@lists.linuxfoundation.org

Does CHAOSS record their meeting?

Yes, CHAOSS records all the meetings and for that, we follow general guidelines for recording the meetings. Also, all the recorded meetings can be found on CHAOSS Youtube Channel

Where can I find CHAOSS community discussion?

All the discussions can be found within the CHAOSS mailing list or CHAOSS GitHub

The goal of this document is to describe a uniform structure that CHAOSS Working Groups are currently using for developing metrics. The outcome of this standardizing Working Group repository structure is less overhead for community members moving between WGs and a consistent expectation for new members.

Naming Convention

Below mentioned is the standard naming covention followed by all Working Group repositories -

Base Files

• /README.md - describes WG, informs about getting engaged, shows off work, meeting information

• /LICENSE.md - default always MIT in accordance with Charter

• /CONTRIBUTING.md - describes the technicalities of engaging with the WG through GitHub; explain the DCO sign-off

• /code-of-comnduct.md - copy of CHAOSS’s Code of Conduct

• /.gitignore - for system files like .DS_Store

• /.github/FUNDING.yml - information for where to donate to CHAOSS

• Other files may exist in the base of WG repositories

Focus areas

• /focus-areas/ - directory for all metrics work

• /focus-areas/README.md - a table of focus areas and their goals, linking to the next level

• /focus-areas/<focus-area-name>/ - directory for metrics in a focus area

• /focus-areas/<focus-area-name>/README.md - table of metrics in this focus area with questions the metrics answer; linking to specific metrics

Metrics

• /focus-areas/<focus-area-name>/<metric-name>.md - metric detail page, must conform to the standard template

• /focus-areas/<focus-area-name>/images/<metric-name>_<image-name>.png - images included in a metric; file-ending can be png/jpg/gif/svg

General conventions

• DO NOT use spaces in names

• Use hyphens “-” instead of spaces within names

• Use underscore to separate different names (e.g., between metric-name and image-name)

• Use lower case for all file and folder names, except README, LICENSE, CONTRIBUTING, FUNDING which are standard across open source always capitalized

• Images are always in a sub-directory “images” under the markdown file that references the image

• The WG repos should have only released and under-review metrics

• In cases where the metric name is also a descriptor, please use this convention:

  "specific thing being measured"-"further description if needed"

  EX: pull-requests-open.md EX: issues-first-response.md

What is the Working Group?

Dictionary says, "Working Group is a group of experts working together to achieve specified goals" and this is what CHAOSS Working Groups signifies - The groups that are primarily organized around metrics and software.

Types of CHAOSS Working Groups

In order to learn more about these groups, you should refer to their GitHub repositories.

Working Groups around Metric

• Common Metric

• Diversity & Inclusion

• Evolution

• Risk

• Value

Working Groups around Software

• GrimoireLab

• Augur

• Cregit

Working Groups around User Groups

• Application Ecosystem

• Diversity & Inclusion Badging

Who all can participate?

The CHAOSS community is dedicated to fostering an open and welcoming environment for all contributors.

Criteria for participating as a normal contributor

The CHAOSS community welcomes and encourages participation from anyone. We believe that our culture is focused on diversity and inclusion which is the key driver of our creativity, innovation, and invention.

We welcome contributions from everyone as long as they interact constructively with our community by participating in working groups meeting calls and providing feedback, and suggestions on metrics and software.

Checklist to become a core contributor within any Working Group:

• participating at least once per month over a period of 3 months

• providing feedback in the weekly working group meetings

• providing feedback on docs of metrics

• making any other contributions on GitHub (commits issues)

How to define any new focus area of metrics inside any working group?

• Understand the background of each working group - Understand the background of each of "Common Metric", "Diversity & Inclusion", "Evolution", "Value", and Risk thoroughly.

• But if you are unable to relate, open up the issue within the relevant repository of the working group and explain the focus area along with its goal

• Once you submit, it will be reviewed by maintainers and will be discussed in the respective working group meeting call.

What is the workflow and culture inside the working groups?

Most of the work within the working group is done in the following ways:

• Issues for keeping track of metrics we are working on with the links to google docs

• We use general google docs for collaborating and discussing on a specific metrics

• We use markdown files in the working group for a more permanent place for metric

• We continue the discussion in the pull request until we decide to merge it

• We have a review period for all new and changed metrics (see release process)

• Working groups work through calls and asynchronously through documents to move towards the decision

What criteria do the Working groups follow for refining or accepting any metric under the relevant group?

We love hearing about new metrics that provide insights into the relevant working group. For refining any new metric working groups follow this:

• Metrics should be defined sufficiently and appropriately

• Metrics should follow the template which can be found at metrics-template.md file on Github

The CHAOSS Community Report is a free service that the CHAOSS community provides to open source communities.

Goals

• Create awareness for the CHAOSS project

• Showcase the CHAOSS metrics and software

• Get more communities interested in CHAOSS metrics and software

• Grow the CHAOSS community

Roles

The Community Report processes have the following roles:

• Requester -- Someone asking for a Community Report

• Coordinator -- The CHAOSS contact person coordinating the creation and distribution of Community Reports

• Software Operator -- A person who works with CHAOSS software to generate visualizations

Requesting a Community Report

Anyone can fill out a form on the CHAOSS.community website. The form submits to a Linux Foundation system and the form is forwarded to essential CHAOSS community members for processing.

Generating a Community Report

When the CHAOSS community receives a request for a report, the following steps will be taken:

1. Someone makes a request

2. Salesforce kicks off the ticket to our emails

3. Vinod, build a new folder for the community request like what I have in the drive now.

4. Vinod, place the SF ticket in the folder

5. Sean and Georg, generate the graphs for the requested URL and place them into the appropriate folder. Ping Vinod when you're done

6. Vinod, assemble the Community Report by placing the graphs into the .ai document. This will require a bit of sizing but I have the approximate sizes marked in the template. Make sure to maintain ratios. This will also require a little cropping of Augur images at the top to remove some icons that come with the graphs.

7. Vinod, email the report (in PDF form) and the SF ticket to Elizabeth (cc me)

8. Elizabeth, send the report and SF ticket back to the requestor.

9. If the requestor said it's okay to post it online, I'll get it into the GH folder

Adding translations in a new language

• New metrics that need to be translated may be identified through translation repository issues, working group repository issues, and on the CHAOSS website release page.

• Before adding translations in a new language, it is strongly recommended to have an active community of native speakers of that language.

• To begin with translations into a new language, create a new directory in the . Name the directory as the language in which the metrics are to be translated.

• Create subdirectories for each working group within the language directory. Note that the name of the sub-directories must match with the repository names of the working groups. (e.g., wg-common, wg-value, etc.)

• The structure of the subdirectory for each working group must be the same as specified for the working group repositories on this . Note:- The base files can be ignored except for the README.

• Follow the templates of other files analogous to as specified in the

• The metrics themselves also follow a . Further, it is recommended to create a translated version of this template to ensure headings are consistent across all translated metrics.

• All directories and files must be named in English only.

• When the directory structure for translations in a new language is ready, the translated metrics can now be added to their respective working group and the focus area.

• The above steps should be completed by the translating community before starting with the translation of the metrics.

• Many of the above requirements are necessary for the process.

Note: Optionally, an English - translated language comparison table or glossary can be created to ensure consistent naming of keywords in the translated language.

Updating translations

The working groups keep revising the focus areas and the metrics regularly. Therefore, it is necessary for the translations to be updated as per the current version of the release. The following steps help ensure this:

• The translations should be updated whenever a change takes place in the original metrics including when:

  • A metric is added, updated, renamed, or removed

  • A focus area is added, updated, renamed, or removed

• New metrics that need to be translated may be identified through translation repository issues, working group repository issues, and on the CHAOSS website release page.

• An issue should be created for each metric that needs translation attention (this may be created by the working group) The issue should be labeled with the languages it affects.

• The translation community should then investigate the issue and try to accommodate the changes in the translated metrics.

• Optionally, the translation team may compare different versions of the metric. The relevant commit hashes can be used to easily identify the changes via the `git diff` command. Git history may be used to see changes to the metric markdown file and identify the relevant commit hashes.

• The issue label for a specific language after it has been applied to metrics/focus areas in that particular language.

• The issue may be closed when the change is implemented in all languages in which the metrics are maintained.

Release of translated metrics

• It is preferable for the translated metrics to get released biannually similar to their English counterparts in the form of a PDF report.

• All metrics undergo a 1-month community review period before the official release. This period should be utilized by the translations team to translate the metrics and share them for review.

• The translations team should update the YAML file in the MARS project when the metrics are ready for release. This serves as the signal to the Release Engineer to generate the release PDF.

• The translations release should ideally happen within two weeks of English metrics release, however, the target for some translation teams may be a simultaneous release.

• The version of the report should be the same as the version of the English report it is based on.

• The version number for the report should be in the format: YYYY-MM_language-code

• When the translation team signals to the metrics release team that translated metrics for a specific language are aligned with the English release, the release manager will use the MARS tool to create the release PDF for that language. The release PDF will be available on the CHAOSS website and an official announcement will be made on CHAOSS communication platforms

• The translation team for each language should update and maintain a contributors list that can be added to the Release document

Timeline for release of translated metrics

The translation teams and release team should ensure that the processes outlined below are executed in a timely manner.

• 1 month before the release.

  • Translate new metrics and update existing ones (identified during the continuous release process) with the most recent changes

  • The release team will announce on the mailing list that the review period is open

  • Request reviews on Twitter, newsletter, or any other social media platform

  • Translate or Draft any other required documents such as cover page and release notes.

• 1 week before the release

  • The release team will announce that the review period is closed.

  • Prepare the English PDF release

  • Buffer period (as long as is needed - translation team for each language will signal when ready)

  • Prepare the Translated PDF release

• Day of release

  • Announce on all social platforms about the release

  • Celebrate! 🎉

Other information

• The English version of the metrics is original and must be used as the only source during the translation process.

When are CHAOSS Metrics Released in English?

• Metrics are continuously released (this includes edits to existing metrics) in English. During that time period, any metric may be edited (they are not static).

• The English version of the metrics is officially released in April and October (approximately 6 months apart). The official release is preceded by a 30 day review period. When the metrics release candidates go into the 30 day review period, they are frozen and no edits are made. Following the review period, they may be edited prior to release to address comments from the review. The released metrics are a snapshot in time.

• Following the official metrics release, all metrics can be edited for the next release as part of the continuous release process. Changes to the metrics are kept track of in working group release notes issues and the individual metrics release candidate issues.

How should the English metrics release team signal a metric needs to be translated?

• The working groups need to make sure that the Metric Release Notes issue in the working groups’ repository is continuously updated with the latest changes in metrics. This will give an overview of all the changes that are occurring during a release cycle.

• Working groups need to create an issue for each metric that has been created or edited - labeled as Metrics Candidate Release. This can signal that a metric needs to be translated.

• Working groups or the release team need to create a corresponding issue in the translation repo that links to the individual Metrics Release Candidate issue. This issue is not targeted towards a specific language community but can be used by the individual language communities to coordinate work. The issue should be labeled with all applicable language tags.

• The release manager will add the under review label to the English Metrics Release Candidates on the CHAOSS website. This also signals that a metric needs to be translated.

How do the translation teams know what metrics need to be translated?

• The first place the translation team should look is in the translation repository issues (all metrics that have been edited should have an issue created by the working group that created or edited a metric). Metrics that need attention should have a language label attached.

• Additionally, the translations team could refer to the working groups’ Metric Release Notes issue. Example: - ) and the Metrics Candidate Release labels in the working group repositories for guidance on which metrics may need to be translated during a release cycle.

• The translations team could also look for the metrics with the label ‘under review’ on the website, which indicates that the metric was added/updated after the previous release.

• Note: The metrics are prone to changes during the continuous release process and following the review period.

What is the lifecycle of the translation release process in comparison to English release?

• The release for translated metrics should happen within 2 weeks of the English metrics release. A simultaneous release is ideal.

• All metrics undergo a 30-day community review period before the official release. This period should be utilized by the translations team to translate the metrics and share them for review.

• The translated metrics should be released only when the translation team signals that the metrics are ready.

• The review period for the translated metrics should follow the same timeline as the English review period.

How do the translation teams signal that the translations are ready for release?

• Translation teams should remove the language tag from the translation repository issue when translation work has been completed for that language.

• The translation team should inform the release team that they are ready for the release (by email, chat, or in Zoom Meetings)

How are CHAOSS metrics releases versioned?

• The versioning of the PDFs should be done in the format - YYYY-MM_language-code. Example - `2021-09_EN, 2022-03_CN

• The release version for the translations PDF should be the same as the English metrics PDF used as the basis for translations.

Form organizing committee

CHAOSScon is a community organized event. We do not have dedicated event staff and rely on volunteers.

A combination of methods can be used to ask for volunteers:

• CHAOSS general mailing list

• CHAOSS events mailing list

• Weekly meetings

• Reach out directly to individuals

A good organizing committee has volunteers with different skills and interests. The following sections detail what needs to be done to organize CHAOSScon. An organizing committee of about 7-10 volunteers has been effective in executing all tasks.

Secure venue

What venue we use depends on when and where we plan CHAOSScon.

CHAOSScon North America (NA) should be co-located with the Linux Foundation’s Open Source Summit North America (OSSNA). CHAOSScon can share the same venue. To secure the venue, we need to file a request on the OSSNA website or contact someone from the LF events team.

CHAOSScon Europe should be co-located with FOSDEM in Brussels Belgium. Bitergia has secured a venue in the past.

The organizing committee can determine how many rooms they want to use. A second room can be used for socializing and workshops.

Time for CHAOSScon

It is easier to end the event earlier than run late.

Consider other events that are happening on the same day.

The Call for Participation (CfP) invites speakers to submit topics for talks, workshops, or tutorials.

Share sponsor prospectus:

• Mailing list

• Twitter

• Specific people the organizing committee knows

Work with sponsors to fulfill promises to sponsors.

When the CFP closes, we use a spreadsheet for evaluating submissions. Each submission gets a row in a table and each organizing committee member gets a column to insert +1, 0, or -1 to vote on submissions. The sum of votes is the basis for discussion.

During a committee meeting, the spreadsheet with submissions and votes is reviewed. Topics and speakers are selected. Based on the selection, a schedule is assembled.

A person selects the action item to inform speakers and confirm their participation.

Keynotes get more time than regular sessions.

Keynote speakers should have a message that we as a community want to elevate. We either invite keynote speakers or we ask if a CFP submitter would be willing to extend their talk to a keynote.

For CHAOSScon North America, we like to partner with the Linux Foundation to have CHAOSScon be an option for registrations to Open Source Summit North America. The Linux Foundation can also provide a stand-alone registration for CHAOSScon only. The latter is the form we link to from the CHAOSScon website.

For CHAOSScon Europe, we used Eventbrite.

The CFP has a date for releasing the conference schedule. On that date, the schedule contains all speakers that confirmed. Speakers who have not confirmed yet will be added later or left off the schedule.

To advertise the schedule:

• Send a message to CHAOSS mailing list, ask everyone to spread the news

• Post regular messages on Twitter

• Reach out to individuals who expressed interest in CHAOSScon

We typically have coffee, tea, and snacks at CHAOSScon for breaks.

Make sure to have name tags at CHAOSScon.

When co-locating with Linux Foundation events and using their registration system, the LF will provide name tags (i.e., lanyards).

The Master of Ceremony (MC) is responsible for:

• welcoming atendees

• announcing schedule

• work with speakers to make sure they get set up with their laptops

• keep everyone on schedule

• adjourn the meeting

In the week before CHAOSScon, email all presenters to ask them for their slides. Ideally, all slides are uploaded to the conference page before the event starts. Some presenters prefer to work on slides last minute and provide them on the morning of the event. We need someone at the event who can accept USB sticks and will upload the slides to the website.

On the conference website, links to slides are added in a column of the schedule. The slides are uploaded, ideally as PDFs, to GitHub. The chaoss/website repo is setup to produce a URL that can be linked to.

In preparation for CHAOSScon, work with venue to:

• Print the schedule to post it at the venue

• Print signs with the hashtag for the event

• Print arrow signs, in case we need to direct attendees to the right room

On the day of the event (check with venue what is allowed):

• Hang up schedule and hashtag signs

• Set up a table to give out name tags

• Provide a place for sponsors to put swag

• Set up video recording

We like to record presentations and upload them to the CHAOSS YouTube channel. This increases the range for presenters and creates an archive to reference talks.

The University of Nebraska at Omaha has in the past brought a camcorder, processed the videos, and uploaded them.

Follow-up

After the event, thank speakers, share links to videos, ...

Feedback and suggestions from CHAOSScon NA 2021

Takeaways/Suggestions:

• More communication before event: in-person/virtual formats, use of Slack, schedule updates, coffee/lunch breaks, after conference activities, social media hashtag

• Increase promotion of the virtual live stream. Sign-ups for email reminders and additional information like slack channel and schedule.

• Make easier to find the Slack channel. Maybe show the slack channel on a screen so everyone can see what's happening there without having to open it on personal device.

• Have the schedule printed and posted in the room.

• More breaks: Add 2 minutes between sessions in schedule for changing speakers

• Shorten virtual talks: Keep virtual talks to 5-7 minutes only. The energy in the room dropped with each virtual talk. It's a great way to include more speakers who can't travel, but it's hard to do.

• More interactive sessions: Have more interactive, workshop-style, sessions for getting into the weeds on CHAOSS work. Maybe do 1/2 day talks and 1/2 day hands-on sessions.

• Roles - Have a dedicated social media person who shares pictures and tidbits throughout the conference and engages with others who are posting about the conference.

• Roles - Slack manager: Similarly, have someone dedicated to watching the Slack channel, compiling questions for the QA session, and seeding conversations there.

This is CHAOSScast, the CHAOSS Community Podcast where we share use cases and experiences with measuring open source community health. Elevating conversations about metrics, analytics, and software from the Community Health Analytics Open Source Software or short CHAOSS project to where ever you like to listen.

👥 Key roles and people

This is a CHAOSS Community project and should never rely on one person only.

Roles

Each role is occupied by different people each episode.

Organizers

The organizer is responsible for the invitation, scheduling, preparation, coordination, moderation, and monitoring the podcast email. Each episode has exactly one (1) organizer. An organizer is also a panelist.

1. Georg Link

2. Samantha Venia Logan

3. Dylan Marcy

4. Sean Goggins

5. ... (you?)

Panelists

A panelist is responsible for research, asking questions, and adding to the conversation on the podcast. These panelists have agreed to be invited to every new episode. Not everyone should be on every episode. Organizers are also panelists.

• Matt Broberg

• Matt Germonprez

• Dawn Foster

• Kevin Lumbard

• Brian Proffitt

• Don Marti

• Nicole Huesman

• Daniel Izquierdo

• Andrea Gallo

• Kate Stewart

• Armstrong Foundjem

• Sophia Vargas

• ... you?

Guest

A guest is requested to discuss up-front what they want to talk about and provide references.

We have a Planning Guests document to keep track of who we want to invite.

Coordinator

A coordinator assists with the finer details of confirming podcast dates/times and acts as a central point of communication for all other roles. This role also sends out post-podcast thank you gifts. This is currently assigned to the CHAOSS Community Manager.

• Elizabeth Barron

Important links

• Google Drive Maintained by Paul Bahr, our sound editor

• Google Drive Maintained by CHAOSScast Organizers

• CHAOSScast Calendar for recording dates and epsiode release schedule

• Email address for podcast, forwarded to Organizers: podcast@chaoss.community

✍ Strategy

Name: CHAOSScast

The CHAOSS community discussed names on the mailing list. Aastha Bist's suggestion CHAOSScast was an instant favorite. We considered longer names that were more descriptive but decided to go with the short CHAOSScast and leave SEO to the description

Subtitle

The CHAOSS Community podcast elevates conversations about metrics, analytics, and software for measuring open source community health.

Description

This podcast fills the gap with open source community metric definitions and software on one side and their use in different contexts on the other side. We invite guests to this podcast to talk about how they use open source community health metrics and software in their own open source communities, companies, or foundations. The panelists are CHAOSS Community members who spent considerable time and effort to understand open source community health and how we can measure it through metrics, analytics and software.

Goal

This podcast fills a gap in the CHAOSS community by sharing specific use cases for metrics and exploring how metrics are used in different contexts.

Audience

Anyone interested in open source community and project metrics, including OSPO managers, Community Managers, open source Maintainers, Linux Foundation Employees, Community Members, DevRel managers

Scope

• [Include] Interviews with people who do metrics for their community, project, foundation, or company

• [Include] Use cases, metrics that matter in specific industries (e.g., high regulated environments as banks)

• [Include] coverage of metrics platforms not considered for future integration into CHAOSS

• [Include] non-OSS markets such as marketing brand communities and corporate social circles

• [Include] active calls for experiments and/or data sets for ongoing case studies?

• [Exclude] quantitative data metrics not related to communities but having much to do with general measurement including ROASS and Paid ad traffic

• [Exclude] developing situations and case studies that are more recent than one month or still ongoing

Style

A panel of 2-3 CHAOSS members interviews guest(s) who have done or used OSS metrics in their specific context. The interview is about the specific use case of the guest.

Format

Each recording is scheduled for 1.5h and a released episode targeting 30-40 minutes. The following is the ideal structure:

• Intro music and intro to CHAOSScast

• Intro of panelists

• Intro of guest(s)

• Interview with guest

• Value adds or picks

• Thank You's and outro with music

Sample interview questions

• Tell us about yourself and your background.

• Tell us about the open source community and project metrics you use.

• How were these metrics decided on to be important?

• What decisions do you make based on these metrics?

• What tools do you use for the metrics?

• Who else sees these metrics and how are the metrics integrated in your workflows?

• "what amazing thing did you do?", "what was the community like before it happened?" "When did you realize something needed to change?" "how did you go about getting the thing done?" "what was the end result?" “why dos what you did matter to the listener’s communities?” “what advice do you have to make doing the same thing easier?”

• What are your hopes for CHAOSS in the future?

🕙 Automation

Documenting any automation configured to date.

Georg Link has an IFTT recipe to:

• If new item in this RSS feed https://feeds.fireside.fm/chaosscast/rss

• Then tweet it from @CHAOSSproj

  • Example tweet: https://twitter.com/CHAOSSproj/status/1256137855606444032

📖 Procedures

These procedures are for the organizer and coordinator of each episode:

Scheduling an episode

• always

  • Think of who would make a good guest for the podcast and ask them tentatively if you may invite them

• Step 1: Determine a guest (Anyone)

  • Action: Recruit interview guest and decide topic and content of the podcast together

• Step 2: Coordinate Episode (Coordinator)

  • Action: Send invitation email (content TBD) to guest to find a few potential suitable dates and times (60-90 minutes.)

  • Action: Notify organizer of guest's date and time possibilities, and confirm one.

  • Action: Prepare the planning document (copy the Episode Planning Document template and start filling in information.)

  • Action: send out an invitation email for panelists to RSVP yes or no (list of email addresses)

    • Prioritize those who said they were interested in the topic

    • If needed, invite new panelists

  • Action: Confirm with 1-2 panelists that replied "yes" and notify others who replied yes that the panel is already complete.

  • Action: Reserve the session on the Rebase.fm Calendly for recording purposes.

  • Action: Send calendar invitation with confirmed date of the podcast (only the guest, organizer, and panelists that will be in the episode

    • The event has to be created in the CHAOSScast calendar

      • All organizers should have full access to the calendar (i.e., Make changes and manage sharing)

    • Name calendar event:🎙 CHAOSScast {with guest}

      • Start with the microphone emoticon (🎙) to signal recording meeting

  • Action: Send out a confirmation email that includes the “how we podcast” document to guests and panelists

  • Action: Update the episode planning document with recording time and zoom link

  • Action: Update the episode overview table

  • Action: If the episode is more than two weeks out, schedule a reminder email for 1 week before the episode recording

  • Action: Schedule a reminder email for 24-hours before the episode recording

• Step 3: Finalize Content (Organizer)

  • Action: Update the episode planning document with the main topics and questions

• Step 4: Post-Episode Thank You Notes (Coordinator)

  • Action: When the episode is scheduled for release that week, notify guest and get their mailing address

  • Action: Sign thank you note and assemble with swag

  • Action: Mail out thank you note with swag

  • Action: Add date of shipment on episode overview table to confirm it was sent

Recording an episode

• On day of podcast (Organizer and Panelists):

  • Action: Review the CHAOSScast Recording Procedures before the session starts

    • Feel good about yourself and get excited!

• When podcast session starts (Organizer and Panelists):

  • Join the Zoom room on time (records automatically)

  • Be yourself

  • Enjoy

Publishing an episode (~30-40 min)

• Justin will send a notification (email or on Slack) After podcast is edited

  • Review the planning document for any notes of interest

  • Download the shownotes and MP3 file from Dropbox

  • Download the cover art from Dropbox

  • Upload the shownotes to google drive and use Convert to Markdown to get markdown format

  • In Fireside, create missing panelists and guests

  • Slug is firstname-lastname (e.g., georg-link)

  • Status: public

  • The other information should be in the Episode Planning Document

  • In Fireside, create a new episode

    • Permalink: # (only the number of episode)

    • Visibility: Public

    • Publish on: a Friday at 3 AM US Central Time

    • Title: Title from the Episode Planning Document

    • Title Format: Episode 123: My Great Title (default)

    • Content: Clean (unless we used swear words)

    • Summary: First paragraph from the Show Notes are a good starting point

    • Description: Insert the show notes in Markdown format.

      • Hint: convert show notes to Google Doc and export as Markdown

    • Keywords: (use sparingly to avoid keyword cannibilization)

    • Tags: (empty) -- we can use tags later for having sub-podcasts

    • Hosts and Guests: activate everyone who was on the show. Regular panelists are all hosts, even when they are guest on an episode.

    • Social Media Destinations: (ignore)

    • Apple Podcasts Settings: (ignore)

    • MP3 File: upload MP3 file provided by CPN through Dropbox

    • Cover Art: upload cover art from Dropbox with the correct episode number

    • Header Image: (ignore, will use default)

    • Transcript: (ignore)

  • PUBLISH

    • Update the template CHAOSScast Calendar event (🎧 (TBD) Release CHAOSScast episode) for the release date (i.e., remove (TBD) and add epsiode number and title)

    • Schedule an email to the CHAOSS mailing list for the release day and time (template)

    • Include in upcoming CHAOSS Weekly newsletter

    • ITTT automated (RSS feed publishing):

      • Schedule a tweet through Tweetdeck

    • Advertise outside of CHAOSS

      • SustainOSS Forum (?)

💰 CHAOSScast sponsorship and revenue

SustainOSS sponsors CHAOSScast and covers the cost of hosting, editing, and show notes. CHAOSScast currently doesn't generate revenue. An idea for the future is to include CHAOSScast as an option along other sponsorship opportunities like CHAOSScon.

😎 Acknowledgments

Georg Link was the key person behind the idea to launch a CHAOSS Community Podcast and the first organizer.

Matt Broberg was the second organizer to join the team and helped establish the podcast.

Justin Dorfman worked with Georg and Matt B to onboard CHAOSScast to the CodeFund Podcast Network and define the procedures required for scheduling, recording, and publishing episodes.

Matt Germonprez and Dawn Foster were the first panelists. (Listen to Epsiode 1)

Paul Bahr from Peachtree Sound is the editor who makes us all sound awesome.

CHAOSS works a lot in meetings -- synchronous video calls

Procedure Before Meeting

1. We have a meeting in Zoom and record in Zoom

2. We announce at the beginning of each meeting that we're recording the meeting

3. Recordings are automatically uploaded to YouTube as private

Procedure After Meeting

After our meetings, someone needs to publish the recordings on YouTube

1. Update video name

2. Add a description that includes a link to the minutes' document and archive in the Governance repo

3. Configure thumbnail image to show on YouTube for video (Export PNG from this slide deck)

4. Add video to appropriate YouTube playlist

5. Publish video

6. Update meeting minutes by pasting the link to the video there

💾 Tech Stack

• GrimoireLab: Python, Vue.js, JavaScript/TypeScript, MySQL, Django, GraphQL.

• Augur: Python, Flask Vue.js, JavaScript/TypeScript, Jupyter.

✏ Technical Requirements

You'll need to have some basic programming experience with the technologies and tools we use.

Tools

Git & GitHub

Clone, commit and open a PR using Git and GitHub. Check out the following tutorials:

• Introduction to git

• Introduction to GitHub

• Popular git commands and how to use them

• Git commands in-depth

• Mastering Markdown

• Markdown Tutorial

• How to Write a Git Commit Message

Languages and Frameworks

Python

• Python's official tutorial

• Python's official style guide

• Python's best practices

• The Zen of Python

Flask

• Quickstart — Flask Documentation (2.0.x)

• Flask - Full Stack Python

Django

• Getting started with Django | Django

• Django Girls Tutorial

• Django - Full Stack Python

Vue.js

• Introduction — Vue.js

🏗 Project Structure

The CHAOSS community's projects have been divided in the following ways:

GrimoireLab

• chaoss / grimoirelab: The main repository for the GrimoireLab project, contains the information and details of all the tools.

• chaoss/grimoirelab-tutorial: Tutorial and guides for GrimoireLab.

• Data retrieval related components:

  • chaoss / grimoirelab-perceval: Retrieval of data from data sources.

  • chaoss / grimoirelab-graal: Source data analysis with external tools.

  • chaoss / grimoirelab-kingarthur: Batch processing for massive retrieval.

• Data enrichment related components:

  • chaoss / grimoirelab-elk: Storage and enrichment of data.

  • chaoss / grimoirelab-cereslib: Generic data processor.

  • chaoss / grimoirelab-sortinghat: Identity management.

• Data consumption related components:

  • chaoss / grimoirelab-kibiter: Dashboard, downstream version of Kibana.

  • chaoss / grimoirelab-sigils: Visualizations and dashboards.

  • chaoss / grimoirelab-kidash: Visualizations and dashboards manager.

  • chaoss / grimoirelab-manuscripts: Reporting.

• Platform management, orchestration, and common utils:

  • chaoss / grimoirelab-mordred: Orchestration.

  • chaoss / grimoirelab-toolkit: Common utilities.

  • chaoss / grimoirelab-bestiary: Web-based user interface to manage repositories and projects for Mordred.

Augur

• chaoss / augur: Augur is a tool for collecting and measuring structured data about free and open source (FOSS) communities.

• chaoss / augur-spdx: Augur's Open Source License coverage tool. Provides license identification by file, identification of non-OSI compliant licenses, and percentage of a project with license declarations.

• chaoss / augur-auggie: Auggie implementation utilizing Amazon Lex to classify messages.

• chaoss / augur-community-reports: A set of Jupyter Lab Notebooks and Other Implementations of Community Reports in Standard Form.

Cregit

• cregit / cregit: Cregit is a framework of tools that facilitates the analysis and visualization of the evolution of source code stored in git repositories.

🤔 Contribution Approach

We love pull requests from everyone! We follow the standard Git workflow of fork 👉 change 👉 pull request 👉 merge 👉 update fork 👉change ... (repeat forever). If you are new to open source, we recommend GitHub's excellent guide on "How to Contribute to Open Source". In addition, please feel free to reach out to any of the maintainers or other community members if you are struggling; we are here to help you learn!

Before getting started, please make sure you've read the README of the respective project repository to get a primer on our project.

💡 Opening an Issue

If you're experiencing an issue with any project or have a question you'd like help answering, please feel free to open an issue in the respective repository of the project. To help us prevent duplicates, we kindly ask that you briefly search for your problem or question in our issues before opening a new one.

Please note that if you open a bug report and your issue does not follow our template, we cannot help you until you have provided us all the relevant information in that format. Respectfully, we do not have the time to try and recreate an error given with minimal or no context, so by providing this information you are helping us help you! You will see this template when you open an issue; click on "Bug Report" and it will be populated with descriptions of what to put in each section. Replace the descriptions with your comments to the best of your ability, and please include screenshots and error logs if applicable.

💻 Contributing to Source Code

Forking

You are required to fork the repository on your Github. Follow the guidelines by GitHub in order to understand the steps to fork any repository

Cloning

You should clone your fork. This step is needed only once. Using augur as an example below;

$ git clone github.com:your-username/augur.git
$ cd augur/

Making Commits

This is the step where you make desired changes to the codebase inside the respective repository.

Writing a well-crafted Git commit message is the best way to communicate context about a change to fellow developers. Seven rules of a great Git commit message are mentioned in How to Write a Git Commit Message.

Sending Pull Request

After you have made the desired changes into your fork version of the repository, you are required to send the pull request with the description explaining your changes. Checkout Github guide to creating the Pull Request****

At this point, you're waiting on us. We like to at least comment on pull requests within three business days (and, typically, one business day). Once one of our maintainers has had a chance to review your PR, we will either mark it as "needs review" and provide specific feedback on your changes, or we will go ahead and complete the pull request.

We require all commits to be signed off with a Developer Certificate of Origin in accordance with the CHAOSS charter. This can be easily done by using the -s flag when using git commit. For example: git commit -s -m "Update README.md". This can be automated by using a browser plugin like DCO GitHub UI.

NOTE: Any pull requests containing commits that are not signed off will not be eligible for merge until the commits have been signed off.

The version number is YYYY-MM of the release date. Continuous Metric Contributions do not get a separate version number.

Continuous Contribution Process

The goal is to have short cycles of feedback and to get metrics out sooner.

1. Coordinate release of metric through release tracking spreadsheet

2. Decide in a working group that a metric is ready for release.

3. Create a release notes issue within the working group repository and update information for each new metric released. This issue will be used to create the regular release cadence release notes.

4. Create an issue for collecting feedback on that metric before release.

5. Include a message in the metric mark down file that the metric will be part of the next regular release. The message should be at the top metric markdown file using the following format:

   ###This metric is a release candidate To comment on this metric please see Issue #xx Following a comment period, this metric will be included in the next regular release.

6. Add metric to metric page with a "under review" tag and link to the feedback issue.

7. Add an item on the Release History page in the Continuous Metric Contributions Since Last Release section stating that the metric was added.

8. Announce the new metric on the mailing list and point to the issue and the markdown page for feedback. Update community on weekly zoom call.

9. Address feedback in issue and through edits to the markdown page.

10. The metric stays under review until after the next regular release

Regular Release

The regular release is when we update the version number, update the full release notes, and make a big announcement. These releases occur one to two times a year and may correspond with the dates for CHAOSScon North America and Europe.

Timeline:

• 2 months before release

  • Decide on a release date, coordinate with working groups

• 1 month +1 week before release

  • Finalize which metrics to include in the release

  • All metrics should be prepared as CMC process described above

  • Add information on the /metric page about the review period and planned release deadline

  • Announce Review Period on mailing list

  • Working Groups review and respond to comments as the come in

  • Request reviews in newsletter, Twitter, all community calls during review period

  • Working groups draft release notes

• 1 week before release

  • Announce on mailing list that review period is closed

  • Prepare the final release (see below)

    • Update /metrics page

    • Update release notes

    • Prepare the PDF release

• Day of release

  • All the work was done before

  • Announce on mailinglist and Twitter and all other channels

  • Celebrate!

Prepare the final release

• Determine release version number (<year>-<month>) because it will be used for several steps

• Extend list of contributors to include those who contributed to the new and previous releases

• Update list of governing board members at time of release

• Working Groups respond to all comments in the issues and close them

• Working Groups merge or close all pull requests related to the release

• Working Groups remove the request for review from the top of all metrics

• Release Engineer creates a release tag in all working groups to freeze metrics for release

  • Tag name: release-<year>-<month>

  • Description: Release notes for that working group, include full list of metrics released

• Release Engineer updates metric pages to pull from release tag (always pull from master, snapshot exists in repo as a tagged commit and PDF)

• Release Engineer cleans up /metrics by removing everything not needed in final release

• Release Engineer cleans up the release notes page

• Release Engineer creates a PDF of the release (see section below)

• Release Engineer links the PDF on the /metrics and release notes page

Prepare the PDF release

• The PDF is created from the website.

  • Make sure to not print menu, footer, "to-top" or any other elements that we don't want in the PDF

  • Here is a Tampermonkey user script that does most of it: CHAOSS Metric print clean (Tampermonkey).user.js

• The Metrics are saved as PDFs from the browser (Chrome, print).

  • Name the files in order #) Metric Name.pdf (the user script will help with naming the pages like this, need to add the number manually after saving)

• The CHAOSS Metrics by Working Groups and Focus Areas pages are the /metrics page saved as PDF

  • Remove the list of contributors and copyright notice from the bottom, they will be in the front-matter

  • Name the file CHAOSS Metrics by Working Groups and Focus Areas.pdf

• Create the front-matter using the Word Document

  • update all of the information

  • save as PDF with any name

• Create the License information using the Word Document, update the year for the copyright

  • Name the file The MIT License.pdf

Above steps should create the following files:

• The front-matter PDF

• CHAOSS Metrics by Working Groups and Focus Areas.pdf

• #) Metric Name.pdf for each metric

• Release History.pdf

• The MIT License.pdf

Merge the files (except the front-matter) in the order listed above

• Use the open source PDFsam Basic

• Merge settings

  • YES: Add a footer

  • Bookmarks handling: Create one entry for each merged document

  • Table of contents: Generate from file names

After creating the merged document, add the front-matter

• If you use PDFsam again, make sure to change the settings:

  • NO: Add a footer

  • Bookmarks handling: Retain bookmarks

  • Table of contents: Don't generate

Revising Existing Metrics:

1. As our process for developing metrics evolves, we will implement a process to go back to old metrics and review every two years. Specifically, after 4 release cycles, we should review metrics and see whether they are still aligned with

   • Our current metric structure,

   • Our current metric style, and

   • The original intention of the metric, and if so, whether the metric's language and/or intention requires updating.

2. What Types of Changes are suitable for continuous release?

   • Whenever there is a language or terminology change that would affect other metric references.

   • Changing the name of a metric (in any way)

   • Any changes that go beyond grammar or spelling fixes in the sections:

   • Question

   • Definition

   • Objectives

   • Implementation

3. Types of metric changes that do not require review:

   • Grammar or spelling fixes (not including metric name)

   • Updates to sections References and Contributors

   • Ultimately, we need a gardener who ensures consistency and flags metrics that need to be “updated”.

In order to keep our documentation consistent across various spaces, we ask that you respect the following conventions and best practices when contributing documentation to the CHAOSS community.

Try to keep your writing clear and concise. Your explanations should be comprehensive, but easy to follow. The more precise your writing is, the easier others will find it to follow.

Here are some general guidelines and reminders for tone and style:

• Write accessibly in clear, simple sentences intended for a global audience.

• Avoid colloquial language, humor, cultural references, and personal opinion. Keep your writing technical.

• Write from a second-person point of view. Use "you" and "your", not "my", "our", or "their".

• Avoid jargon and acronyms, if you can. Spell out acronyms at least once per page.

• Remember to link to glossary terms when first introducing them in a paragraph.

• Be consistent. Use the same consistently-formatted word or phrase for a concept throughout the documentation.

• Don't qualify or prejudge actions. Don't write that something is "easy" or "quick" as this is a deterrent if the user is not able to complete the action.

• Don't reference future development or features that don't yet exist.

• Remember to use sentence case for page titles and section headings.

• Use numbered lists for actions that happen in sequence.

• Use bulleted lists for most other lists.

Unfortunately, good code won't speak for itself. Even the most elegantly designed and well-written codebase that solves the most pressing problem in the world won't just get adopted on its own. You, the open-source creator, need to speak for your code and breathe life into your creation. That's where technical writing and documentation come in. (Source credit: Kevin Xu's article on from opensource.com)

We encourage documentation contribution from everyone and generally, that contribution is divided into two categories:

• General improvements: typo corrections, fixing broken refs or links, correcting inaccurate or out-of-date information, and offering better explanations through clearer writing and additional examples.

• New features or new pages: Adding a page of documentation that we haven't yet covered in our ongoing attempt for completeness, or documenting a new feature that has been added to CHAOSS projects since the last release.

Getting Started

We don't have any specific space for documentation. Most of the documentation you will find inside the CHAOSS GitHub repositories and on the website.

Approach to Contribute

• Addressing issues related to documentation: Look for the documentation labeled issues within the CHAOSS Github repositories.

• Checking if a page needs to be updated: Surf around the CHAOSS community, look for the pages that need to be updated, and suggest changes through an issue or pull request.

• Propose new pages for the documentation: While working on CHAOSS initiatives and software you might come across documentation needs; Open an issue to remember for later and ask for help or create a pull request to add the documentation yourself.

Once you have figured the approach below is the flow you need to follow:

• Open the CHAOSS GitHub and find the repository on which you want to contribute. (Assume the governance repository here; using the GitHub.com user interface.)

• Click on the file you want to edit. For instance, I have taken the README.md file. Click on the pencil option to edit the page.

• Make any edits you need, remembering to always format them using Markdown. To understand Markdown better, check out the GitHub reference or GibtBook reference guides.

• When you are done making changes, scroll down, and write a short description of your changes. Select the option Create a new branch for this commit and start a pull request and click on Propose file change. This will direct you to the Pull request page.

• On the Pull Request page, write the description of your changes and create a pull request by clicking on create pull request button

Our Process

We follow a 4-query procedure to solve the design issues. Each question is a step toward the completion of the product.

• What do we want? We need to initiate the requirement goals that define - what are we trying to achieve? How will it impact the CHAOSS community?

• What do we have? We need to take into consideration the information we have - Do we have any set of design guidelines or information for the specific new goal that we are trying to achieve?

• How do we get what we want? We need solid ideation in order to achieve any goal - Does the community agree to follow the new goal? Do we have any plans or processes to achieve the new design goal?

• What will happen when we do? We need to understand the future impact for any specific design goal - Is the problem solved? Is this what you were looking forward to having? Will it create a better impact on the CHAOSS community?

Ways of Achieving

****💡 Plan - You should be good to commence your design with planning as design inquires into the nature of a problem to conceive a framework for solving that problem. In general, planning is problem-solving, while the design is putting problems into actions.

****🧐 Research - Make generative research together with the CHAOSS community members the requirements and assets that are needed. Check what impedes their productivity.

****✍ Document - Documentation stands out as one of the most important parts of any implementation design goal. After making fair research you should write down all the requirements you need with the available resources.

****🖌 Design - High time! Once all the objectives and requirements are defined, draft your thoughts into the canvas that will help in solving the critical design problem that you are trying to achieve.

****🧪 Test - Testing is the stage in the design process that enables you to evaluate your design problem or service with real users and enables you to create more community-oriented design solutions.

What is CHAOSS Visual Identity?

It is the visible elements of a brand, such as color, design, logo, typography, and the symbol that identify and distinguish the brand in consumers' minds.

Why it is needed?

It is important to portray the identity of CHAOSS across all platforms in a consistent manner.

Who can use it?

It can be used by developers, documentarians, marketers or anyone who want to showcase the identity of the CHAOSS community

Visual Guidelines

• CHAOSS logo in color

• CHAOSS logo in black

• CHAOSS logo in White

Color Palette

Color Used:

Font

Font used in the CHAOSS logo is PORT

About Google Summer of Code

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open-source organization on a 3-month programming project during their break from school.

Google awards stipends to students who successfully complete a free and open-source software coding project during the summer. The program is open to university students aged 18 or over. The amount of the stipend depends on the of the country where the student's university is located. Project ideas are listed by host organizations involved in open-source software development, though students can also propose their own project ideas.

Official Website -

Things you need to follow

Welcome! We’re glad you’re interested in contributing to the CHAOSS Community designs. Before contributing, please review the following values:

Be Ambitious - We appreciate to test new boundaries and take advantage of new design solutions. You should prefer to work with a genuine sense of continuously improving and striving to be the best that can be.

Be Minimalist - We make sure that our designs are simple and straight forward which gives a better meaning to the design problem.

Be Inclusive - You should keep the user first in mind. Thinking inclusively is about considering diverse groups of people, how they will interact with your design problem, and their environments.

Be Respectful - We value the designer's efforts. So you should be respectful towards the community or the user you are interacting with in order to have proper feedback on your design solution.

Be Consistent - The consistency helps us to maintain the momentum of the project and the improvements within the community designs.

Different Design Contributions

Graphic Design

This includes corporate design (logos and branding), Illustrations, marketing design (posters, banners), advertisements, communication design, and signage.

Tools: , , ,

UI/UX Design

UI communicates with UX! It includes designing the User-Interface screens for any web or mobile applications by putting different components like buttons, reads, clicks, animation, etc. User experience is determined by how easy or difficult it is to interact with the user interface elements that the UI designers have created.

Platform: or any other UI/UX designing platform

UX Documentation

It's design documentation that includes feedback from users, general researches about design, and any design workflow and process for the specific design problem. It also includes all the information regarding the particular design.

Platform: GitHub

Getting Started

We don't have a particular platform for listing all the design problems but we follow this general process in order to accomplish any design goal:

• Come up with the design idea and discuss it on the CHAOSS mailing list

• Another way of contributing is to open an issue on the project repository and tell maintainers about your idea.

• Discuss your designing strategies and documentation

• Design on your canvas tool (Figma, Adobe Photoshop. etc)

• Discuss your design submission on the mailing list and on the GitHub issues. Don't forget to mention an appropriate label (design label)

The CHAOSS project was officially announced at the Open Source Summit North America 2017 in Los Angeles. Here is a picture of the workshop participants at OSSNA2017 -- the first to help us spread CHAOSS! If you are interested in helping spread CHAOSS now, check out the following ways to get involved with the CHAOSS community.

Spreading the word about what is going on in the CHAOSS community is a vital part of CHAOSS engagement, and below are the following ways with which you can get involved in growing the CHAOSS community

• Writing Blogs - Blog posts help with reaching a larger audience and catching their interest. We value the time and efforts of our readers, so keep your blog posts focused and straight forward around your goals which you want to deliver. The CHAOSS website has section where all the blog posts written for the CHAOSS community are published but we don't want to limit you to the CHAOSS website. You can use any platform for writing your blogs.

• Social Media - You can help us spread the word by sharing CHAOSS on social media. On Twitter, tag CHAOSS using . Also interesting: and videos on .

• Merchandise - If you are good at designing then you can help us in designing and processing the t-shirts, stickers, posters, badges, and similar. You can checkout to understand the design better.

• Organize Conferences and Meetups - We generally have CHAOSScon twice per year. So if you are good at organizing events then check out the of the CHAOSScon organizing members and get involved. We always appreciate organizers of local meetups and events.

How and where to communicate for respective engagements?

What is CHAOSS design?

As the community gathers around the topic of Open Source Community Health, all members participate in the choices about what action to undertake in designing and providing better user experience. It is useful to coordinate those choices and decisions by laying out some guidelines. Designers use such guidelines to judge how to adopt principles such as intuitiveness, learnability, efficiency, and consistency so they can create compelling designs and meet and exceed user needs.

Hence, CHAOSS design is a place where we solve design principle issues and improve the design structure of the community projects

We are trying to:

• Improve user experience.

• Provide high-quality design solutions.

• Bring the community together to contribute to design-related issues.

• Bridge the gap between the designers and developers to follow the smooth process for the design solutions.

• User Interface Design (UI)

• User Experience Design (UX)

• Graphic Design and Visual Identity

• User Design Research and Documentation

Connect

You can connect to us with the following methods:

• Join us in the Slack channel

• Discuss on the CHAOSS D&I mailing list

• Or open an issue under the badging/diversity-and-inclusion repository.

Please don’t hesitate to contact us by any of the means listed above when your thoughts about this project come up. Your suggestions are tremendously valuable to us.

Thank You

Thank you so much for your interest in D&I badging program and wishing to make contributions. All kinds of contributions are appreciated.

This guide provides several angles for you to get started. We hope one of them will work for you!

Participate as a reviewer

If you want to be part of the review team, please see “Apply to review”.

Sign up as a reviewer and you can get in touch with different events and projects, measure how Diversity and Inclusion they are. When doing the reviewing job, please make sure you have read the reviewer’s guidance and understand our D&I badging conflict of policy.

Contribute to the workflow

For now, most of the workflows happen under the Event D&I badging repository. If you think there is unreasonableness about the process, or you have suggestions to improve the workflow, don't hesitate to open an issue to discuss your suggestion. For bug fixing and word spelling correction, we warmly welcome you to open a Pull Request.

Improve the Submission Form and Review Checklist

The Submission Form and Review Checklist are two core components that compose the application and review process, the content is mostly based on CHAOSS D&I metrics.

To make improvements to our documentation on GitHub, you can:

• Open an issue on GitHub

• Open a pull request on GitHub

We suggest adding text with the pull request explaining why the change should be made.

Contribute to this documentation

To optimize this documentation, there is a synchronized community handbook documentation repository on GitHub. Please open a pull request there to make revisions. Documentation revisions are also precious contributions for us.

The D&I badging application is submitted through a web form to provide information and measurements on how an event achieves diversity and inclusion practices. All initial judgments from reviewers are made according to the form, so please do your best with it, make sure to fill out all the fields.

💡 This page will help you fill out the form and provide perspectives on improving your event referring to the submission form.

In-Person Event Badge Submission Form

Basic Information

• Event Name: Use the most commonly mentioned and well-known name of the event.

• Link to the Event Website: The link should be valid, publicly available on a website, and it should show the event information. We recommend providing the home-page link.

• Provide verification that you are an event organizer: Only the organizer is eligible to apply the badge on behalf of event participants. Please provide substantial proof showing you are the organizer of the event you are applying for. A link with your name displayed as an organizer on the event website is ideal.

Initial Checks

Event status-related requirements

• The event must be about Open Source technologies and practices.

• You should be an organizer of the Event you are applying for.

Metric related requirements

• The information about the event must be publicly available on a website.

• Metrics information must be available for potential attendees and speakers.

• The event must host a Code of Conduct on the website.

Metric-related Information

The In-Person Event D&I metrics are:

• Speaker Demographics

• Attendee Demographics

• Code of Conduct at Event

• Diversity Access Tickets

• Family Friendliness

If your event commits to one of the following metrics, please tick the checkbox, then fill the subsequent boxes under each question. We also provide criteria under each metric in the form for you as references of what the reviewer will be considering when reviewing the submission.

If your event meets some of the criteria, please provide related details and proofs. If not, those are the perspectives where your event can improve. 😉

Speaker Demographics

• Measuring Demographics: Does your event measure speaker demographics?

• Displaying demographics: Does the speaker demographics publicly displayed on your event website?

Attendee Demographics

How diverse and inclusive are the attendees?

• Measuring Demographics: Does your event measure attendee demographics?

• Displaying demographics: Does the attendee demographics publicly displayed on your event website?

• Attendee Inclusivity: You can request feedback from attendees about how they feel about the inclusiveness of this event, then take measures to encourage more attendees which are from different backgrounds.

Code of Conduct at Event

How does the Code of Conduct for events support diversity and inclusion?

• Findability: The Code of Conduct should least be discoverable on the website, and better to post at the event venue where speakers and attendees will have an easy time to find.

• Enforcement: You can require participants to accept the Code of Conduct before completing registration.

In the Code of Conduct:

• Clarity: Does the Event Code of Conduct provide a definition of expected behaviour?

• Reporting venue: Does it have a clear avenue for reporting violations at the event?

• Support at Event: Does it describe information about possible ways to provide support to victims of inappropriate behavior, eventually links to external bodies?

Diversity Access Tickets

How are Diversity Access Tickets used to support diversity and inclusion for an event?

• Availability: How many types of diversity access tickets are available?

• Ticket allocation: How are those diversity access tickets allocated?

• Findability: Does the information about diversity access tickets posted on your event website or some other public venues?

Family Friendliness

How does enabling families to attend together support diversity and inclusion of the event?

• Availability: Services or facilities can be provided for participants who bring families to the event, especially to those who have children to take care of. For examples, you can:

  • Provide a mother’s room,

  • Offer child care during the event,

  • Have special sessions for children.

  It's also wonderful if your event has other ideas that are suitable and effective to promote family friendliness of the event.

• Findability: Is the information about the family-friendly services easily found on your website?

About

D&I Badging program aims to increase understanding of the open-source project and event practices that encourage greater diversity and wider inclusion of people from different backgrounds. It uses an open peer-review system to encourage projects and events to obtain badges and improve their processes and documentation to be more inclusive using the feedback they gain from the reviewers.

The program is affiliated with the CHAOSS project and a proud initiative of CHAOSS. The work of the Badging Program is closely associated with the CHAOSS D&I working group.

CHAOSS is a Linux Foundation project. For more information about CHAOSS, please visit the website at chaoss.community

Goal

The goal of the Diversity & Inclusion Badging Program is to encourage projects and events to obtain D&I badges for reasons of leadership, self-reflection, and self-improvement on issues critical to building the Internet as a social good.

The Badging Workflow

Events applying for a CHAOSS badge should fill in the submission form to open an issue under the corresponding GitHub repository, waiting for reviewers to give feedback.

Reviewers will be randomly assigned according to the reviewer list. All assigned reviewers should work with the review checklist.

The Diversity and Inclusion measurements that occur during the applying and reviewing process are according to D&I metrics defined by CHAOSS.

The workflow will be elaborated in the "Applying for a badge" and the "Reviewing for CHAOSS" sections, you can also have a quick view below.

Applying for Badges

Event Badging

The Event Badging section of CHAOSS Badging is about measuring the inclusivity of different technical events through human reviews.

In order to submit an application for a project, review the following documents:

• Applicant role - This document describes the GitHub permissions and the responsibilities of a CHAOSS Badging Applicant.

• Event submission requirements - Describes the minimum requirements for an Event to be eligible for participation in the CHAOSS Badging process.

• Event submission guidelines - Guidelines and steps on how an Event can acquire a badge under the CHAOSS Badging program.

Badge Levels

CHAOSS Badges are assigned according to how the Reviewers mark out the review checklist according to the information initially filled in by the Applicant.

The badge percentages are calculated from the average of checklists of at least two reviewers. This percentage excludes the initial checks.

Metrics For Event Badging

The metrics used in the Badging submission process are defined by CHAOSS D&I Working Group. Metrics used for event badge come from the Event Diversity focusing area.

These are the five metrics that belong to Event Diversity:

Project Badging

Project badging is planned for the second release. We are looking forward to it!

Reviewing Badging submissions

Reviewers are an essential component of CHAOSS Badging. Their feedback and interaction with an applicant determine the success of the Badging Program.

In order to get familiar with what is expected of reviewers, review the following documents:

• Reviewer Role - This document describes the GitHub permissions and the responsibilities of a CHAOSS Badging Reviewer.

• Reviewer Guide - the Guide is small as of now, but it provides some additional guidelines

We are currently recruiting reviewers for event submissions!

To become a reviewer, please fill out the Reviewer Application Google Form and tell us a little bit about yourself! Please send an email to Matt at msnell@unomaha.edu When you are finished.

Work to Date

The CHAOSS Badging Project is now in the first release. We are continuously recruiting reviewers and applicants.

Contributors

Maintainers

• Matt Snell

• Saleh Abdel Motaal

Core Contributors

• Xiaoya Xia

• Ore-Aruwaji Oloruntola

• Aastha Bist

About Google Season of Docs

The goal of Season of Docs is to provide a framework for technical writers and open source projects to work together towards the common goal of improving an open-source project's documentation.

During the program, technical writers spend a few months working closely with an open source community. They bring their technical writing expertise to the project's documentation, and at the same time learn about the open-source project and new technologies.

The open-source projects work with the technical writers to improve the project's documentation and processes. Together they may choose to build a new documentation set, or redesign the existing docs, or improve and document the open-source community's contribution procedures and onboarding experience.

Official Website -

We make one distinction between virtual events and in-person events. The Virtual Event does not support the metric because this is not currently a concern for virtual events.

💡 This page will help you with how to fill out the form, and provide perspectives on improving your event referring to the submission form.

Virtual Event Badge Submission Form

Basic Information

• Event Name: Use the most commonly mentioned and well-known name of the event.

• Link to the Event Website: The link should be valid, publicly available on a website, and it should show the event information. We recommend providing the home-page link.

• Provide verification that you are an event organizer: Only the organizer is eligible to apply the badge on behalf of event participants. Please provide substantial proof to show you are the organizer of the event you are applying for. A link with your name displayed as an organizer on the event website is ideal.

Initial Checks

Event status-related requirements

• The event must be about Open Source technologies and practices.

• You should be an organizer of the Event you are applying for.

Metric related requirements

• The information about the event must be publicly available on a website.

• Metrics information must be available for potential attendees and speakers.

• The event must host a Code of Conduct on the website.

Metric-related Information

The Virtual Event D&I metrics are:

• Speaker Demographics

• Attendee Demographics

• Code of Conduct at Event

• Diversity Access Tickets

If your event commits to one of the following metrics, please tick the checkbox, then fill the subsequent boxes under each question. We also provide criteria under each metric in the form for you as references of what the reviewer will be considering when reviewing the submission.

Speaker Demographics

• Measuring Demographics: Does your event measure speaker demographics?

• Displaying demographics: Does the speaker demographics publicly displayed on your event website?

Attendee Demographics

How diverse and inclusive are the attendees?

• Measuring Demographics: Does your event measure attendee demographics?

• Displaying demographics: Does the attendee demographics publicly displayed on your event website?

• Attendee Inclusivity: You can request feedback from attendees about how they feel about the inclusiveness of this event, then take measures to encourage more attendees which are from different backgrounds.

Code of Conduct at Event

How does the Code of Conduct for events support diversity and inclusion?

• Findability: The Code of Conduct should be discoverable on the website.

• Enforcement: You can require participants to accept the Code of Conduct before completing registration.

In the Code of Conduct:

• Clarity: Does the Event Code of Conduct provide a definition of expected behaviour?

• Reporting venue: Does it have a clear avenue for reporting violations at the event?

• Support at Event: Does it describe information about possible ways to provide support to victims of inappropriate behavior, eventually links to external bodies?

Diversity Access Tickets

How are Diversity Access Tickets used to support diversity and inclusion for an event?

• Availability: How many different types of diversity access tickets are available?

• Ticket allocation: How are diversity access tickets allocated?

• Findability: Does the information about diversity access tickets posted on your event website?

About Outreachy

Outreachy is a paid, remote internship program. Outreachy's goal is to support people from groups underrepresented in tech. They help newcomers to free software and open-source make their first contributions.

Outreachy provides internships to work open source. People apply from all around the world. Interns work remotely and are not required to move. Interns are paid a stipend of $5,500 USD for the three-month internship. Interns have a $500 USD travel stipend to attend conferences or events.

Interns work with experienced mentors from open source communities. Outreachy internship projects may include programming, user experience, documentation, illustration, graphical design, or data science. Interns often find employment after their internship with Outreachy sponsors or in jobs that use the skills they learned during their internship.

Outreachy expressly invites applicants who are women (both cis and trans), trans men, non-binary people, and genderqueer people to apply.

They also expressly invite applications who are residents and nationals of the United States of America of any gender who are Black/African American, Hispanic/Latin, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.

Outreachy Eligibility Rules

These eligibility rules apply to December 2020 to March 2021 Outreachy internships round. Dates may change for future rounds.

Outreachy is open to applicants around the world. You will need to meet the following requirements:

• You are or will be 18 years of age or older by Dec. 1, 2020

• You are available for a full-time, 40 hours a week internship from Dec. 1, 2020, to March 2, 2021.

• You were not an intern with Outreachy, the Outreach Program for Women, or Google Summer of Code. People who were a Google Summer of Code intern are not eligible for Outreachy. All Google Summer of Code interns are ineligible for Outreachy, including people who did not successfully finish their GSoC internship. If you apply to Outreachy and you are not accepted as an intern, you may apply again.

• Applicants who have part-time or contracting jobs are welcome to apply. People who are willing to quit their full-time job are welcome to apply. If you cannot quit your full-time job, you are not eligible for Outreachy. People who are taking a leave of absence from a full-time job are not eligible for Outreachy.

• Outreachy is open to both university students and people who are not university students. University students must have 42 consecutive days free from school and exams during the internship period. Students must apply to the correct internship round (see rules below).