chaoss / community

This is the main CHAOSS community repository. Feel free to open an issue to discuss a topic of community interest! This repository also holds governance, mentorship, and other community-related documentation

CHAOSS Community Repository

👋 Welcome to the CHAOSS Community! 👋

Repository Content

This repository contains the following:

• Content for much of the community documentation included in the CHAOSS main website
• Other documentation that applies to the entire CHAOSS community
• Operational and process documentation not published to the website

DEI Project Badge

The CHAOSS DEI Project Badge represents our commitment to centering diversity, equity, and inclusion in our community as found in our DEI.md file. If you have questions or comments about our DEI.md file, please reach out to the community on Slack or Elizabeth Barron (@ElizabethN).

Use of Issues

We use issues in this repository for the following:

• To coordinate CHAOSScasts
• To log community discussions and projects
• For questions about the CHAOSS community
• For suggestions on improving documentation or community processes

How to contribute to this repository

This is a living repository, meaning we are very open to changes and improvements. We follow the GitHub pull-request workflow. More details on specifically what that means can be found in the CONTRIBUTING.md file. If you would like to contribute but you aren't sure how to go about doing so, please reach out to the community on Slack or Elizabeth Barron (@ElizabethN). We are happy to help!

Maintainers of this repository

• Georg Link
• Elizabeth Barron, CHAOSS Community Manager
• Ruth Ikegah, Community Lead, CHAOSS Africa

community's Issues

Ideas for Handbook Pages

What processes do we have in CHAOSS that could each constitute a single page?
Here are four ideas

1. Mentoring (e.g., GSoC, Outreachy, CommunityBridge)
   • Organisation administrators
   • Finding Mentors
   • Selecting Mentees
   • Integrating Mentees
   • Coordinating between Mentors and Mentees
2. Working Group
   • Starting a working group
   • meeting on regular calls
   • using mailing list
   • engaging people asynchronously
3. Releasing metrics
   • Process
   • Infrastructure
4. Website
   • Adding new page
   • updating a page
   • removing a page

[ GSoC ] Project report and Meeting Log

Addressing the community with the report and progress of the GSoC Project: Support of Source Code Related Metrics

• We will be discussing the progress of this project at the #grimoirelab channel on FREENODE IRC. The transcripts of the meetings (conversation log) will be made available in the repository that I'll be creating in due time. For now the transcript will be added to this thread and then be merged to the new repository.

• I'll close this issue once I have a repository setup, which will contain the IRC conversation log of meetings that are conducted in the process and the project progress.

Project Mentors: @valeriocos @jgbarah @aswanipranjal

---

Meeting Log:

• Community Bonding Meeting 1 on 13-05-19: gsoc-inishchith-19-05-13.txt

[Notes] The release version number are different between this time and before

In the CHAOSS project homepage , URL : https://chaoss.community/release-history/

we rule the releasr version number is "YYYY-MM" in chaoss project ,like this:

but I found the releasr version number before this time is like this:
.

Outreachy Application-Period Enagement: Conversion Rate

1. An overview of the project can be found at #310
2. Install Grimoirelab (https://github.com/chaoss/grimoirelab)
3. Create a screen shot of your installed Grimoirelab instance and paste it as a comment in this issue.
4. Post an issue (not a PR) in the Metrics Model Working Group Repository (https://github.com/chaoss/wg-metrics-models)
5. The issue should include 1) Your Name, 2) A description of how you think you would deploy the metrics model in GrimoireLab. Be descriptive in your explanation - including such things as data sources, data aggregation, and visualizations.
6. Post your achievements back to the Outreachy application

The tutorial document link doesn't work

https://oss-augur.readthedocs.io/en/master/getting-started/toc.html mentioned below leads to a 404 page
[](url

)

require DCO for all new commits

This issue is to activate protobot/dco (or similar bot) to check that all commits have a sign-off. The CHAOSS Project Charter requires that all contributions are signed-off.

For users of the git command line interface, a sign-off is accomplished with the -s as part of the commit command: git commit -s -m 'This is a commit message'

For users of the GitHub interface, a sign-off is accomplished by writing Signed-off-by: Your Name <[email protected]> into the commit comment field. This can be automated by using a browser plugin like scottrigby/dco-gh-ui

[GSoC] IRC Meeting and Communication Modes

Regarding the GSoC project Implementing CHAOSS metrics with Perceval, the common modes of communication would be the following:

• Bi-weekly meetings with mentors on the channel #grimoirelab on freenode
• Emails on the mailing lists with links to my latest weekly blog posts.

The posts will live on my website, but will be linked here as comments to this issue.

The logs of the IRC meetings will be contained in my GSoC repository here

GSoC Idea: Implement Conversion Rate Metric in CHAOSS Software

Conversion Rate

Question: What are the rates at which new contributors become more sustained contributors?

Microtasks

For becoming familiar with Augur, you can start by reading some documentation. You can find useful information at in the links, below. Grimoirelab also has a set of installation instructions and documentation here: https://chaoss.github.io/grimoirelab-tutorial/

GSoC Students (Primarily, though contributions welcome from Outreachy):

Once you're familiar with Augur, you can have a look at the following microtasks.

Microtask 0:
Download and configure Augur, creating a dev environment using the general cautions noted here:
Augur
https://oss-augur.readthedocs.io/en/dev/getting-started/installation.html and the full documentation here:
https://oss-augur.readthedocs.io/en/dev/development-guide/toc.html
Grimoirelab
https://chaoss.github.io/grimoirelab-tutorial/

Microstask 1:
Work on any Augur or Grimoirelab Issue that's Open

Microtask 2:
Identify new issues you encounter during installation.

Microstask 3:
Explore data presently captured, develop an experimental visualization using tools of your choice. If Jupyter Notebooks against an Augur database/API endpoint collection, use https://github.com/chaoss/augur-community-reports for development.

Microtask 4:
Anything you want to show us. Even if you find bugs in our documentation and want to issue a PR for those!

Outreachy Candidates:

The Conversion Rate Metric is not yet defined, and would be defined here: https://github.com/chaoss/wg-metrics-models .

It would be implemented under this working group, so you can follow a pattern of implementation description, using language from the issue itself. https://github.com/chaoss/wg-metrics-models/tree/main/focus-areas/community-engagement

An example of a current metrics model definition is here: https://github.com/chaoss/wg-metrics-models/blob/main/focus-areas/development/metric-model-issue-handling.md

An example of a current metrics model implementation is here, using Jupyter Notebooks, and may also be an inspiration: https://github.com/chaoss/wg-metrics-models/tree/main/implementations/community-welcomingness

Description

The conversion rate metric is primarily aimed at identifying how new community members become more sustained contributors over time. However, the conversion rate metric can also help understand the changing roles of contributors, how a community is growing or declining, and paths to maintainership within an open source community.

Objectives (why)

• Observe if new members are becoming more involved with an open source project
• Observe if new members are taking on leadership roles within an open source project
• Observe if outreach efforts are generating new contributors to an open source project
• Observe if outreach efforts are impacting roles of existing community members
• Observe if community conflict results in changing roles within an open source community
• Identify casual, regular, and core contributors

Implementation

This project could be implemented using either the CHAOSS/Augur, or CHAOSS/Grimoirelab (including stack components noted in references) technology stacks.

The aims of the project are as follows:

• Implement the Conversion Rate Metric in CHAOSS Software
  • After discussion, consider which CHAOSS Software Stack you wish to work with
  • In collaboration with mentors, define the technology framework, and initial path to a "hello world" version of the metric
  • Iterative development of the metric
• Assist in the deployment of this metric for a pre-determined collection of repositories in a publicly viewable website linked to the CHAOSS project.
• Advance the work of the chaoss metrics models working group.

• Difficulty: Medium
• Requirements: Knowledge of Python is desired. Some knowledge of Javascript or twitter/bootstrap is also desired. Key requirement is a keenness to dig into this challenge!
• Recommended: Python experience.
• Mentors: Sean Goggins, Daniel Izquerdo

Filters (optional)

• Commits
• Issue creation
• Issue comments
• Change request creation
• Change request comments
• Merged change requests
• Code Reviews
• Code Review Comments
• Reactions (emoji)
• Chat platform messages
• Maillist messages
• Meetup attendance

Visualizations

Source: https://chaoss.github.io/grimoirelab-sigils/assets/images/screenshots/sigils/overall-community-structure.png

Source: https://opensource.com/sites/default/files/uploads/2021-09-15-developer-level-02.png

Tools Providing the Metric

• GrimoireLab
• Augur
• openEuler Infra

Data Collection Strategies

The following is an example from the openEuler community:

• A group of people who attended an offline event A held by the community, can be identified as Group A. Demographic information of Group A could be fetched from an on-line survey when people register for the event. To identify the conversation rate of these participants:
• Some people from Group A started watching and forking the repos, indicating they have shown some interest in this community. We marked them as subgroup D0 (Developer Level 0) as a subset of Group A.
• Conversion rate from the total number of people in Group A to the number of people in subgroup D0 is: D0/Group A
• Some people from subgroup D0 make more contributions beyond just watching or forking, including creating issues, making comments on an issue, or performed a code review. We marked them as subgroup D1 (Developer Level 1) as a subset of D0.
• Conversion rate from the total number of people in Subgroup D0 to the number of people in subgroup D1 is: D1/D0.
• Some people from subgroup D1 continue to make more contributions, like code contributions, to the project. This could include creating merge requests and merging new project code. We marked them as subgroup D2 (Developer Level 2) as a subset of D1.
• Conversion rate from the total number of people in subgroup D1 to the number of people in subgroup D2 is: D2/D1.

Definition:

• Developer Level 0 (D0) example: Contributors who have given the project a star, or are watching or have forked the repository
• Developer Level 1 (D1): Contributors who have created issues, made comments on an issue, or performed a code review
• Developer Level 2 (D2): Contributors who have created a merge request and successfully merged code
• Conversion Rate (Group A -> D0): CR (Group A -> D2) = D0/Group A
• Conversion Rate (D0 -> D1): CR (D0 -> D1) = D1/D0
• Conversion Rate (D1 -> D2): CR (D1 -> D2) = D2/D1

References

• https://opensource.com/article/21/11/data-open-source-contributors
• https://github.com/chaoss/augur
• https://gitee.com/openeuler/website-v2/blob/master/web-ui/docs/en/blog/zhongjun/2021-09-15-developer-level.md
• https://chaoss.github.io/grimoirelab-sigils/common/onion_analysis/
• https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/

Contributors

• Yehui Wang
• Clement Li
• zhongjun
• Xiaoya Xia
• Matt Germonprez
• Sean Goggins
• King Gao

Outreachy Application-Period Engagement: Documentation Inclusivity

1. An overview of the project can be found at #328
2. Install Augur (https://github.com/chaoss/augur)
3. Show us a screen shot in this issue that you got it installed (include the screen shot as a comment on this issue)
4. Review the existing documentation at: https://oss-augur.readthedocs.io/en/main/
5. Open an issue or PR to improve Augur documentation. You can edit Augur documentation here: https://github.com/chaoss/augur/tree/main/docs
6. Post your achievements back to the Outreachy application

Add Community Culture page to handbook?

Moving @jaskiratsingh2000's suggestion from chaoss/community-handbook#25 (comment)

Hi @ElizabethN @GeorgLink This issue caught my eye and I really liked the concept of informing to community and I highly appreciate the @ElizabethN for initiating this but I am not fully convinced that writing this much on the existing page would be enough

If you plan to be away from the CHAOSS project for a period of time, it's helpful to communicate that to other community members by changing your Slack Status or mentioning it in a Working Group meeting.

So I just have an idea that why don't we create a specific page with the name something like "Community Culture" and within this we elaborate upon the above mentioned sentence with all the details like adding screenshots, My understanding says that this page is not only for writing about informing the community instead the Community Culture would contain all the details relevant to what community has been doing bit internally/externally. I once remembered that @GeorgLink you mentioned about CHAOSS people mentoring for career guidance or higher studies to students or interns they have worked with and who are willing to seek such guidance. Correct me if I am wrong? So taking this thing into consideration I belive that it would be good to have a page for the community culture where we could define all such types of the activities in detail.

Let me know @ElizabethN @GeorgLink @germonprez What do you think about this above idea?

Providing Guidance to Working Groups Around Privacy

During multiple discussions in our weekly Community Call and at CHAOSScon, the idea was surfaced that we should be providing guidance to our Working Groups around the consideration of privacy and ethics while developing metrics. For instance, sometimes our metrics include PII (Personally Identifiable Information) and we feel it's important to flag this for anyone who is using this metric in practice.

This "guidance" will consist of 3 things:

• A central document describing the levels of PII, proper handling of data, and other considerations for those using metrics in practice
• An addition to the Metrics Template that prompts the Working Group to have a thoughtful discussion around whether or not there could be data privacy issues in the collection of data in the metric, and a recommended statement under "Implementation". This statement will point to that central document and will be optional.
• A line item in our Metrics Quality Checklist, for reviewers to double-check that data privacy was considered.

We will also include a data privacy review of previously released metrics when doing our Metrics Audit for next release.

(For context, we have a similar framework for thinking about how a metric might impact DEI).

Thanks to @lucasgonze for championing this!

Does my email address need to be updated on the GSOC-interest lis

Hello @GeorgLink,

I was just noticing now but I mistakenly put down [email protected] as my email address in the GSOC-interest file, instead of putting down the correct form which is [email protected]. I guess it was the last day rush that caused that silliness on my part 😣

I understand that the deadline for sending in PRs has passed but could it be updated? Especially if it will be important later on.
If it is not relevant, we could just leave it, I guess. The correct form of my email address was put down in all other neccessary places.

Thank you.

CHAOSS Brand Kit

As CHAOSS grows and the visibility of our work continues to increase, it's important to keep our brand intact and consistent and have a polished look. I'm opening this issue to allow for async discussion about this, as I know not everyone is at the community meetings all the time.

Feel free to drop your thoughts here!

cc @uoduckswtd1

Minimum System Requirements and Tutorials for Outreachy

Hi everyone,

As part of getting the projects available for Outreachy, I need a few more things from you. On the following page, I think I have most information:

https://github.com/chaoss/governance/blob/master/Outreachy-ideas.md

But a few things that I need you to spell out for me. You can just include answers in this Issue.

1. Minimum System Requirements. Please remember that for Outreachy, participants often have old computers. For example,
   Internet access
   Single Core 1.0 Ghz
   64Mb Graphics Card
   1Gb of Ram
   40Gb Hard drive,
   Lightweight Linux Operating System (Windows and Mac are fine too)

2. Links to getting started tutorials or documentation, how applicants can find contribution tasks on your project website or issue tracker, who they should ask for tasks, and everything they need to know to get started.

@sgoggins @GeorgLink @Polaris000 @sduenas @valeriocos @zhquan @alpgarcia @dlumbrer @samanthavenialogan

Metrics Release 2022-03 Ideas

During our latest weekly Community Call, we had an idea around our next Metrics Release in 2022. That idea is to do a Metrics Audit. We should make it a practice to periodically go back and review all "old" metrics for updates and improvements, and to make sure the language is clear and that the metrics are still relevant in the context of open source as it currently stands.

We're using this issue as kind of placeholder for this task, and any other ideas we have for improving our metrics release. Please feel free to drop any comments or ideas here. 🙌

Merge all GSoC proposals

@GeorgLink can we merge all the GSoC PRs in one consolidated merge?

Templates for focus-areas READMEs in WGs

Hi everyone,

Right now, the focus-areas READMEs in each WG have a different structure. For eg -

• wg-value/focus-areas
• wg-diversity-inclusion/focus-areas
• wg-common/focus-areas

Also, each focus-area have different structure for READMEs too. For eg -

• wg-common/focus-areas/what
• wg-risk/focus-areas/licensing
• wg-evolution/focus-areas/code-development-activity

As discussed, I prepared 2 templates -

1. Template for Focus-areas READMEs
2. Template for README in each focus area

The templates can be found in this document

All suggestions and improvements are welcome.

Request that GSoC students make their submission repos private

@GeorgLink what do you think about having the students submit private repos for their GSoC microtasks? They could make the repos available to organizers and mentors. This came up today in the Community Call

Metrics Template Discussion & Edit

Provide Guidance on:

• 1 - 2 page metrics page limits
• Links to metrics should point to an external website
• Image size limitations
• Image accessibility naming

Move mentorship related files into a folder

It is good to see CHAOSS is participating in many mentorship programs like the Summer of Code, Season of Docs, Outreachy, etc. We usually create program-ideas.md and program-interest.md pages for each program as our community follows a particular structure. I was thinking if it would be good if we can create a mentorship folder and move out all the files from the root of the repository to the mentorship folder to avoid cluttering the repo. What do you all think?

Also, I would like to add a point that we don't do it right since we are actively participating in around 3 programs at the very moment and it would cause a lot of confusion because of the broken links which we shared in Slack or in many other places. We usually have a calm period right before GSoC starts, I think it is the best time to do such change if everyone agrees on this.

I would leave this issue open for now and you can assign me this if you want. I can open the PR after a few months after the application storm has passed. 🌪️

Confusion regarding GSoD proposal

Hey, I went through the season of docs technical writer guide and found that the applicant has to submit the description and title in the form. But as per the GSoD-interest.md, the applicants need to submit the proposal link. As there is no specific format for the GSoD proposal. So, how do I need to proceed further?

@vchrombie @GeorgLink Can you please look in to this.

Talk to the mentors

I want to talk to the mentors of idea #3 prototype new CHAOSS Metrics.
Kindly provide their email or some other things where I can chat regarding the implementation of the project.

Removing requirement for reviews on prs

I have 4 pull requests open that are minor and that I want to get merged. Since I'm the only listed maintainer on the repository, there is no one official to ping for reviewing my own pull requests. Therefore, I'm removing the review requirement, thus enabling myself to merge my own pull requests.

If anyone has a problem with this, please let me know.

talk with mentors

sir i did not fill the form for this GSOC so i was removed, next year also i want to work for your organisation.
you have asked me to attend the weekly calls, so sir what is the procedure ?

Closed-Captioning for Meetings?

I don't know if this is something that has been discussed in the past, but I've been wondering if there is an option (or desire?) to caption the meetings that we record and post.

I believe Zoom has this capability but I don't know if it is available within the university's current link we use from @germonprez.

I think it would be helpful for anyone in the meeting who is hearing impaired, having difficulty connecting to audio, or for our non-native English speakers, as well as anyone watching the recording later who doesn't have access to the google doc of agenda and meeting minutes. It would also lower the barrier to someone who may have been hesitant to join without this capability, and signify that we are aware of the challenges these folks face with virtual meetings.

Is this something we are interested in implementing or trying out?

Feedback regarding GSoC

Hey @jgbarah @valeriocos thanks for helping me, to get through the process of writing a GSoC proposal. Unfortunately, my project did not get selected. This was my first time in GSoC and I would like to know any shortcomings in my proposal that you might have come across, so that I can apply to GSoC in a better way.

proposal link

I forget to add link of my proposal.
Should i add??

Adding Information to DCO

On the Common call, it was brought up to include a reference to https://github.com/coderanger/dco

This is a DCO tool and I'm not 100% sure how it would fit with our current design.

Summer 2021 - How do we collaborate on the program ideas?

We submitted an application for CHAOSS to participate Summer 2021:
https://summer.iscas.ac.cn/help/en/community/

It's pretty much like GSoC in China, although the project ideas are not limited to code contributions.

CHAOSS is now a qualified participating organization in Summer 2021, we need to hash out the project ideas as soon as possible, how do we collaborate on that?

As a starting point, it could be based on the ideas from GSoC:

• Idea: Advancing Risk Prediction With Machine Learning in Augur
• Idea: Build an expert system to provide recommendations to users in a user interface
• Idea: Automatically identify Contributor Aliases (emails, platform user accounts) to Increase Parsimony of Statistics and Metrics With Privacy Enhancement
• Idea: Develop a Shared Data Resource Focused on Dependencies, Risk and Vulnerabilities in Open Source Software
• Idea: Extend data model and user interface to capture better information about contributors
• Idea: Implement user roles/permissions and OpenID
• Idea: Build Prototype Metric Display Options on CHAOSS Website
• Idea: Automate Metrics Release and Process Improvement

@germonprez @GeorgLink @king-gao @WillemJiang @sgoggins @ElizabethN

[GSoC] Project Updates (287)

Opening this issue to provide information about the updates on the project idea Creating Quality models using GrimoireLab and CHAOSS metrics (chaoss/grimoirelab#287).

I have created a project tracker repository for storing the progress, weekly summaries, and meeting logs. The link to the repository is https://github.com/vchrombie/gsoc.

The communication would be as follows:

• Weekly meetings with mentors on the channel #grimoirelab on Freenode IRC. The meeting logs will be stored in the meetings folder of the project tracker, right after the meeting. I will share the meeting log here as well.
• Weekly blog posts on my blog, will be sharing the links here as well.
• The weekly work summary will be shared with the GrimoireLab mailing list. They are also stored in the work folder of the project tracker.
• The weekly blog posts are sent to the CHAOSS mailing list too.*

Thanks to the mentors, @inishchith @Polaris000 @dlumbrer @valeriocos, for the help.
Please let me know if you have any suggestions. 😃

Test - tagging @chaoss/content-group

Does everyone on the @chaoss/content-group get notified?

Project-wide statement on data, consent, and GDPR?

I've been reviewing metrics and thought about this concern. Do we have a project-wide statement on data and consent?

I'm thinking whether we consider people should "get started" with CHAOSS, we add a note about it with further reading. I don't believe it's our responsibility to inform everyone about GDPR and how to manage data, but I do think it's right to point out the best practice of only share data your community would feel comfortable seeing publicly.

Wdyt?

How do we indicate when we are on vacation/unavailable?

During the Community Call, the question was brought up about how we indicate to our fellow community members that we're unavailable or on vacation. This is especially for those core community members/Working Group leads/Maintainers that may have people waiting on them for action items.

The ideas that were brought forth were:

• Changing status on Slack
• Changing status on GitHub

Are there other ideas? Can we add this to the Community Handbook?

Metrics without contributor lists

I noticed that older metrics have contributor lists, while some newer metrics do. That is OK until we need to add a contributor to an older metric.

Check out this PR: chaoss/wg-dei#373

I could not add a contributor to the project-and-community/code-of-conduct metric because there is no list for it.

How should we handle this? I'm sure there are many different methods but I want to open it up.

Update "Sponsor" links on all GitHub repos

CHAOSS is switching to Open Collective for receiving and managing funds.

The new link is: https://opencollective.com/chaoss

All GitHub repos have a /.github/FUNDING.yml file that currently points to Community Bridge (now: LFx Crowd Funding) and that files needs to be updated to instead point to Open Collective.

Ideas for Projects for She Code Africa

CHAOSS is very interested in participating in the April-May cohort of She Code Africa's Contributhon, but before we can complete our application to be a mentor organization, we need to define what project they will be working on. I think this is a little bit different than our usual GSOC projects because of the shorter timing, and the fact that we have a CHAOSS member who is a past participant in this special project. We will hopefully be able to participate as a mentorship organization, but it depends on if the project gets sufficiently funded from sponsorship orgs.

Our current idea is to create a slackbot that would help point newcomers to some resources upon joining our Slack community.

@Ruth-ikegah were you interested in being a mentor for this? It has been a really long time since I wrote a slackbot 😆 but I could try to help out on the technical side if needed.

If we think this is a project we want to submit, we will have to draw up a list of subtasks and technical requirements (operating systems, etc).

The application (along with the project and subtasks) is due February 28, so we are kind of tight on time.

Would appreciate any other insights and comments @germonprez and @sgoggins.

Potential Outreachy Project: Implement the Conversion Rate Metric Model and Document the Metrics Model Process

This issue simply describes what one potential Outreachy project would be. There is nothing to do in this issue with respect to the application period.

Conversion Rate

Question: What are the rates at which new contributors become more sustained contributors?

Description

The conversion rate metric is primarily aimed at identifying how new community members become more sustained contributors over time. However, the conversion rate metric can also help understand the changing roles of contributors, how a community is growing or declining, and paths to maintainership within an open source community.

Objectives (why)

• Observe if new members are becoming more involved with an open source project
• Observe if new members are taking on leadership roles within an open source project
• Observe if outreach efforts are generating new contributors to an open source project
• Observe if outreach efforts are impacting roles of existing community members
• Observe if community conflict results in changing roles within an open source community
• Identify casual, regular, and core contributors

Implementation

This project could be implemented using either the CHAOSS/Augur, or CHAOSS/Grimoirelab (including stack components noted in references) technology stacks.

The aims of the project are as follows:

• Implement the Conversion Rate Metric in CHAOSS Software
  • After discussion, consider which CHAOSS Software Stack you wish to work with
  • In collaboration with mentors, define the technology framework, and initial path to a "hello world" version of the metric
  • Iterative development of the metric
• Assist in the deployment of this metric for a pre-determined collection of repositories in a publicly viewable website linked to the CHAOSS project.
• Advance the work of the chaoss metrics models working group.

• Difficulty: Medium
• Requirements: Knowledge of Python is desired. Some knowledge of Javascript or twitter/bootstrap is also desired. Key requirement is a keenness to dig into this challenge!
• Recommended: Python experience.
• Mentors: Sean Goggins, Daniel Izquerdo

Filters (optional)

• Commits
• Issue creation
• Issue comments
• Change request creation
• Change request comments
• Merged change requests
• Code Reviews
• Code Review Comments
• Reactions (emoji)
• Chat platform messages
• Maillist messages
• Meetup attendance

Visualizations

Source: https://chaoss.github.io/grimoirelab-sigils/assets/images/screenshots/sigils/overall-community-structure.png

Source: https://opensource.com/sites/default/files/uploads/2021-09-15-developer-level-02.png

Tools Providing the Metric

• GrimoireLab
• Augur
• openEuler Infra

Data Collection Strategies

The following is an example from the openEuler community:

• A group of people who attended an offline event A held by the community, can be identified as Group A. Demographic information of Group A could be fetched from an on-line survey when people register for the event. To identify the conversation rate of these participants:
• Some people from Group A started watching and forking the repos, indicating they have shown some interest in this community. We marked them as subgroup D0 (Developer Level 0) as a subset of Group A.
• Conversion rate from the total number of people in Group A to the number of people in subgroup D0 is: D0/Group A
• Some people from subgroup D0 make more contributions beyond just watching or forking, including creating issues, making comments on an issue, or performed a code review. We marked them as subgroup D1 (Developer Level 1) as a subset of D0.
• Conversion rate from the total number of people in Subgroup D0 to the number of people in subgroup D1 is: D1/D0.
• Some people from subgroup D1 continue to make more contributions, like code contributions, to the project. This could include creating merge requests and merging new project code. We marked them as subgroup D2 (Developer Level 2) as a subset of D1.
• Conversion rate from the total number of people in subgroup D1 to the number of people in subgroup D2 is: D2/D1.

Definition:

• Developer Level 0 (D0) example: Contributors who have given the project a star, or are watching or have forked the repository
• Developer Level 1 (D1): Contributors who have created issues, made comments on an issue, or performed a code review
• Developer Level 2 (D2): Contributors who have created a merge request and successfully merged code
• Conversion Rate (Group A -> D0): CR (Group A -> D2) = D0/Group A
• Conversion Rate (D0 -> D1): CR (D0 -> D1) = D1/D0
• Conversion Rate (D1 -> D2): CR (D1 -> D2) = D2/D1

References

• https://opensource.com/article/21/11/data-open-source-contributors
• https://github.com/chaoss/augur
• https://gitee.com/openeuler/website-v2/blob/master/web-ui/docs/en/blog/zhongjun/2021-09-15-developer-level.md
• https://chaoss.github.io/grimoirelab-sigils/common/onion_analysis/
• https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/

Contributors

• Yehui Wang
• Clement Li
• zhongjun
• Xiaoya Xia
• Matt Germonprez
• Sean Goggins
• King Gao

Newcomer opportunity: Chair a CHAOSS Working Group meeting

Summary

Create more opportunities for someone to chair a meeting by requesting coaching or mentorship in advance.

Background

I like that the Fedora Project gives a virtual badge to a contributor for chairing a team meeting. Acknowledging it with a small token of appreciation incentivizes participation and empowers new contributors to gradually become more engaged in the community.

I thought it could be helpful to give long-time WG meeting conveners a break, and a chance for them to become mentors by helping others chair working group meetings.

Details

I could see a couple of ways of this working:

1. Create a weekly/fortnightly "meeting chair coaching" session, as an alternative to office hours.
2. Create an asynchronous form for someone to declare interest in chairing a meeting, but request guidance and coaching on how best to go about it.
3. Mix of the above.

I think this could tie in nicely with the ongoing efforts to improve the newcomer experience. It would also likely require coordination with each working group. Could meeting chair mentorship be generalized for any working group?

Outcome

Lower barrier for new volunteers for chairing a working group meeting.

talk to mentors

Standardization of files in each WG repo

Hi everyone,

Now that we're almost through with restructuring the working group repositories. We're also looking to create a standardized version for the set of files that are present in each WG repo. This will help increase uniformity in the way information is presented in these repos.

The following set of files have been proposed for standardization:

• README.md

  • The main README.md files in each WG repo are currently following different structures.
  • Proposed structure - https://docs.google.com/document/d/1pfipIiaemdtdiDQpvY7jOKhKzsv_3lXLLsbJiByl5GU/edit?usp=sharing
  • Issues can be found in each WG repo discussing this in detail (e.g.- wg-common/issues/116)

• focus-areas/README.md & focus-areas/<focus-area-name>/README.md

  • These README files also follow different structures.
  • Similar to the main README.md we're looking to create a common structure for these files also.
  • #276 discusses this in greater detail.

• CONTRIBUTING.md

  • The common content of this file will be moved to the community handbook to create a master contributing guide.
  • This file would be redesigned so it points to the guide in the handbook.
  • This is being done to follow the SSOT practice and ease maintenance.

• code-of-conduct.md

  • This file would also be redesigned so it points to governance/code-of-conduct.md
  • Reasons are the same as for CONTRIBUTING.md.

talk to mentors

sir now i know the problem, i did not filled the GSOC applying application ,i thought GSOC proposal is the application,so i just completed the micro task and made a proposal. I think mine chance is gone for this time. Sir how many times can i try now ? I want to work with CHAOSS only.

DCO - Github interface sign off fails

DCO check fails for Github interface users.

Is this a bug that can be fixed?

Should we just set it to pass if we see the sign-off message?

See chaoss/website#515

Reviewing our use DCO for usability, personal safety, validity

I appreciate that we want a contributor license agreement in our process. It's a valuable part of a growing organization to take it up. I want to go over some reasons I think DCO isn't helping us with that, hopefully concisely:

• We are having issues with contributors knowing about the DCO, using the DCO, and patching mistakes with DCO. We have some really good examples in DEI. I've also personally had issues when I use the GitHub UI.
  • I've experienced issues where I have to completely remake a PR because my DCO commit locks up and I don't know enough Git to resolve it. This could be bad for new contributors.
• Using DCO introduces ethics issues around real names. For the validity of the DCO, you must use your real name. Neither pseudonyms nor anonymization will work. I think this is a really big ask.
  • Some good questions around this topic of DCO & naming are well described in this issue.
• I've seen a few spots where good arguments are made that DCO is not a valid CLA. Here is one argument for that case.
  • The validity becomes a bigger problem if we ask the submitter during the review of their PR.
  • I've also seen maintainers "just set it to pass" for other maintainers, including me, because of the difficulty.

With these arguments in mind, I propose we, as an organization:

• Remove our integration of the DCO in CHAOSS repositories
• Search for an alternative that provides an explicit opportunity for agreement

Document prefixes for emails that we will use on the mailing list

We talked about merging all mailing lists into one. The idea is to use prefixes to denote what topic an email falls into. We should create a list of prefixes and thus document them. With that in place, we can use filters in our own mail clients.

Define 'Path to Maintainership' and 'List Maintainers'

Per proposal in #5 :

The README.md of the repository contains a list of who is maintainer. Each CHAOSS repositry brings together different people and they document in the repository specific CONTRIBUTING.md how somone becomes a maintainer on their repository.

TODO:

• Specify 'path to maintainership' for this repo in CONTRIBUTING.md file
• List current maintainers in README.md file

Collecting Feedback for CHAOSScon 2022

We have successfully shipped CHAOSScon 2021, and we need a place to collect thoughts and feedback for next time. This issue will serve that purpose ✨ .

For our reference, the feedback survey is here: https://docs.google.com/forms/d/e/1FAIpQLSd6kzyyafJRTSa1D_xEH_T4tICbSJ-24j0dqsOVvlmOsLZwcw/viewform?usp=sf_link.

Other feedback is welcome in the form of comments on this issue. Thanks!

merge micro task

i have pull requested the proposed micro task , kindly see to it

Need to Update README

Just pointing out the obvious :)

Update GCoC Pages

@GeorgLink -- I think that we should clear out the two GSoC pages. I think that we can leave a lot of the content, just remove the text that is associated with last summer. What do you think?

connect with organisation

Sir, i have previously worked and completed a microtask with your organisation. Sir i want to know how i can attend your calls and want to know about the conference dated 28 august.