ABOUT

COMMUNITY

CONTRIBUTING

MENTORSHIPS

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

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

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.

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.

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.

What does leadership mean to the CHAOSS community?

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.

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.

Why is leadership important to us?

How to become a leader?

Technical Leadership

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

• 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

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

Attribution to GitLab's Handbook

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

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.

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

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.

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.

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

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>/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

Things you should take into Consideration

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?

• 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

What is the Working Group?

Types of CHAOSS Working Groups

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

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?

• 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

• 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

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.

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:
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
• 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

• • update all of the information

  • save as PDF with any name

• • 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

• 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”.

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

CHAOSS Project

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

Organization Administrator

Mentors

Mentee/Student

CHAOSS Mentorship Alumni

What is CHAOSS?

What does CHAOSS stand for?

CHAOSS stands for Community Health Analytics Open Source Software.

What is the metric?

Why does Community Health matter?

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?

How do I use your software?

Is my open source community healthy?

Who is behind the CHAOSS project?

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?

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

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.

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

Who are the maintainers of the CHAOSS?

Whom should I contact if I have any questions?

Does CHAOSS record their meeting?

Where can I find CHAOSS community discussion?

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

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.

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.

Important links

✍ Strategy

Name: CHAOSScast

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:

• Then tweet it from @CHAOSSproj

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

  • • Prioritize those who said they were interested in the topic
  • Action: Confirm with 1-2 panelists that replied "yes" and notify others who replied yes that the panel is already complete.

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

    • • 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: Update the episode planning document with recording time and zoom link
• 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

Recording an episode

• On day of podcast (Organizer and Panelists):

  • • 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

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

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

  • Status: public

  • The other information should be in the Episode Planning Document

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

    • Header Image: (ignore, will use default)

    • Transcript: (ignore)

  • PUBLISH

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

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

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

• 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

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

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.

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

👥 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

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

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

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

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

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.

• 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.)

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

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.

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

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.

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.

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.

File: [https://github.com/chaoss/website/blob/master/CHAOSScon/2019EU/slides/GMD-tutorial.pdf](https://github.com/chaoss/website/blob/master/CHAOSScon/2019EU/slides/GMD-tutorial.pdf)


URL for website: [https://chaoss.github.io/website/CHAOSScon/2019EU/slides/GMD-tutorial.pdf](https://chaoss.github.io/website/CHAOSScon/2019EU/slides/GMD-tutorial.pdf) 

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.

🤔 Contribution Approach

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

Cloning

Making Commits

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

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

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

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

4. Add video to appropriate YouTube playlist

5. Publish video

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

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:

• 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

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.

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

💾 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:

Languages and Frameworks

Python

Flask

Django

Vue.js

🏗 Project Structure

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

GrimoireLab

• Data retrieval related components:
• Data enrichment related components:
• Data consumption related components:
• Platform management, orchestration, and common utils:

Augur

Cregit

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

How and where to communicate for respective engagements?

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.

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.