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

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.

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.

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?"

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

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 or the ), not the Handbook, which is only for team members. Read more in the 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 , the , the or the .

Attribution to GitLab's Handbook

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

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.

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 -

🙍‍♂️ Repository Maintainer

• Send a reminder about meetings

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.

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:

The CHAOSS Community Handbook is a central 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 to suggest improvements or add clarifications. Please use to ask questions.

The published version of the Community Handbook can be found at .

ABOUT

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.

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

What happens if someone breaks the rule?

There are a variety of actions that we may take when a user reports inappropriate behavior or content. Please follow the "Enforcement" within the that denotes the appropriate outcome of the inappropriate behavior.

Organization Administrator

The members of the CHAOSS community who manage CHAOSS's participation in various programs like Google Summer of Code, Google Season of Docs, and Outreachy.

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. ****

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 ()

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.

What is CHAOSS?

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

CHAOSS Project

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

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.

Introduction

Thank you so much for showing interest in D&I Badging Project and the review system. We are delighted to have you here! This page tells you a bit about the participation as a reviewer and helps with some detailed principles you would need to know while reviewing.

Responsibilities

The reviewer role would belong to people who would be responsible for reviewing the details submitted by an applicant. Reviewers will have access to the review checklist. The review checklist is a reviewing guide, which is a list written in Markdown, detailing the criteria a submission has to be measured against.

GitHub Permissions

Reviewers will be able to:

• Edit their own comments.

• Edit the Review Checklist.

Reviewers will explicitly not be able to:

• Edit an applicant's comment.

FAQ

Q What kind of commitment is reviewing for Event Badging? A We see a lot of variables affecting this time commitment, including our number of reviewers and the number of applicants. We expect, at the highest load, for the project to require about 20 minutes every few days from each reviewer. At lowest, we'd expect 20 minutes or so every few weeks.

Q We are looking forward to answering more questions!

What does leadership mean to the CHAOSS community?

A leader🏅is 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-driven👥organization 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

Checklist✅before 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

Checklist✅before becoming a Website Maintainer

• Ability to troubleshoot website issues

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

• Excellent content creation and writing skills.

Checklist✅before becoming a Documentation Maintainer

• 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

Governance Leadership

Leadership involved in the process of decision making within the community

Checklist✅for becoming a Board Member and Decisions Maker

• Long term and consistent contributor within the CHAOSS project

• Involved with the software or metric working groups

• Experience in a managerial/directorial position

Operation Leadership

Leadership that addresses every aspect of the community model

Checklist✅for becoming the Community Manager

• 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

👥 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.

• 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

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:

🧐 Some Metric Useful Resources

🔎 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

CHAOSScon is a conference organized by CHAOSS Community annually which fosters around the topics - open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. It also shares insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, Value, and Common Metrics. .

🎙️ CHAOSScast

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

📙 CHAOSSblog

CHAOSSbog is the CHAOSS community blog hub hosted on the website for which anyone can contribute to getting published on the CHAOSS website.

CHAOSStube

It is the central directory - Youtube, where you can find all the recorded community meeting calls that are held within the CHAOSS Community.

📰 CHAOSSweekly

It is the directory where all the weekly newsletters are hosted.

✍️ Charter

The Charter sets forth the responsibilities and procedures for technical contribution to and oversight of, the CHAOSS – Community Health Analytics Open Source Software Project (the “Project”) within The Linux Foundation. Contributors to the Project must comply with the terms of the Charter as well as any applicable policies of The Linux Foundation.

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 -

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

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

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

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

CHAOSS D&I Badging Conflict of Interest Policy

A conflict of interest in peer review arises when a situation where you, the reviewer, are unable to make a fair judgment. The CHAOSS D&I Badging Project aims to promote a transparent and impartial environment to evaluate Diversity and Inclusion, as well as consciously avoiding situations where conflicts of interest may appear.

As a reviewer, Conflicts of Interest for event submission reviews are your present or previous associations with any event organizers and the event committee of a submission. The following situations are considered conflicts and should be avoided:

• Organizing for the submitted event.

• Having a personal relationship (e.g.family, close friend) with the event organizer(s).

• Receiving personal benefit resulting from the review.

If you have a conflict of interest with a submission, you should disclose the specific reason to the moderator team. After the discussion within the moderator team, you may not be eligible to review the submission. Declaring actual, perceived, and potential conflicts of interest are required under professional ethics. If in doubt, ask the moderators.

Statement

The D&I Conflict of Interest Policy is derived from and takes references from

​

​

​

​

​

​

​

Responsibilities

This will be a role that will belong to participants who would help in closing a Badging Application and declaring the final badge for an application.

GitHub Permissions

A moderator will be expected to:

• Ensure all the Initial Checks are marked positive in both checklists.

• Confirm the Review Checklists are adequately marked by the reviewers.

• When the review ends, comment /end to mark the application as closed. This will generate the badges which the Applicant can use.

Moderator guide

Moderators are responsible for ensuring that reviewers and applicants understand the Badging workflow. This is done through issue comments, pull request comments, and other Badging discussions. The Moderators in the Badging organization are required to have a strong understanding of D&I practices within an open-source organization.

Roles of the Moderator

• Generate a badge when the reviewers have filled out the checklist and the applicants have implemented all feedback.

• Provide advice and understanding where applicants and reviewers are having trouble.

FAQ

Q What kind of commitment is moderating for Event Badging? A We see a lot of variables affecting this time commitment, including our number of moderators and the number of applicants. We expect, at the highest load, for the project to require about 20 minutes every couple of days for each moderator. As we get more moderators into the project, that commitment will shrink.

Q What happens if a reviewer is not responding or providing a review? A In this case, we use a week in real-time as our metric. If the reviewer has been assigned for a week and has not provided their review or responded to requests, you can unassign them. At this point, you must also assign a new reviewer. You can use your judgement to request a reviewer that you haven't seen on any events recently, or someone that you know will be reliable.

Q We are looking forward to answering more questions!

References

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.

Responsibilities

The responsibility of a maintainer would be to ensure that the whole project is under control, and completing the processing of a Badging application. A maintainer will also maintain the reviewer team and responsible for the training of new reviewers.

Responsibilities

Applicants would be the primary stakeholders for any CHAOSS Badging review. They will be responsible for:

• Applying for a CHAOSS D&I Badge.

• Improving their application according to reviewer feedback.

• Provide a point of contact between their own community and CHAOSS.

GitHub Permissions

Applicants will be able to:

• Submit an application for a Badging review.

• Edit details and make improvements in their application.

Applicants will explicitly not be able to:

• Edit the Review Checklist.

FAQ

Q What kind of commitment is the application process for an Event Badge? A The initial form will likely take about 15 minutes to fill out. After submitting your application, you are required to communicate, at least a few times, to ensure that the information is accurate and confusion is resolved. You must also confirm that the badge your event receives is clear.

Q We are looking forward to answering more questions!

🤔 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 "". 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 in order to understand the steps to fork any repository

Cloning

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

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 .

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. ****

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 in accordance with the . 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 .

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

Command & Functionality

We integrate a GitHub app, the @badging-bot, to help us coordinate the workflow. The main function of the badging-bot is improving the efficiency of the reviewing process with some automated integration.

Some more functions of the badging-bot include:

• Guiding applicants/reviewers

• Assigning reviewers for a submission

• Opening checklists for reviewers according to the type of event

• Checking current badge status

• Generating the final badge link

• Closing an application issue when an application is finalized

Instances when the bot is triggered

Here is a mock submission illustrating the review process:

This is what happened where the@badging-bot is triggered:

• A new submission is created. Once the issue of a new submission is successfully initiated, @badging-bot will do three things:

  • greet the applicant and provide guiding information ()

Commands

You can also interact with @badging-botusing a few commands.

1. /result (Anyone)

• Type this command and only this command in an issue anytime during the review when you wish to check the current badge status.

• All roles are allowed to use this command.

2. /end (Moderators)

• Type this command and only this command in an issue when the review is at an end.

• Only moderators are allowed to use this command.

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.

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

• Open the 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 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 or 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

Congratulations! 🎉 you made the pull request and it will be reviewed by the repository admins

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 -

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.

Event Definition

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

Involving as a Student 👨‍🎓

Before Being Accepted

Connect

You can connect to us with the following methods:

• Join us in the

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

🎯 Goals

• Create awareness for the CHAOSS project

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

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📖

Working Groups around Software🖥️

Working Groups around User Groups 👥

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.

Check out our for participating within the different working groups. Don't forget to experience it! 😉

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

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

Here are the steps to define any new Focus Area🎯of metric inside any working group:

• Understand the background of each working group - Understand the background of each of "", "", "", "", and thoroughly.

• Ask yourself - Under what category my focus area lies? Try to relate your focus area with already existing focus areas. If you are able to relate it with the existing focus area and background that means its all set. 👍

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

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: