Google Season of Docs - Microtasks

[Nebrethar]

Google Season of Docs - Microtasks

Project overview

The CHAOSS Diversity and Inclusion Badging Program began as a way to ensure that D&I metrics can have a significant impact on the ways that communities function. The aim of the CHAOSS D&I Badging program is to bring D&I metrics into use for propelling good D&I practices in different open source systems.

This project will focus on framing documentation for the D&I Badging program and aligning it in such a way that it makes sense after translation. This work would focus on more community-facing docs related to Badging and also on existing Markdown files.

Submitting microtasks

All microtasks must be submitted as a response to this issue.

Once you submit your first microtask, your responses will be recorded in a document on [hackmd.io](). These documents will be regularly updated, and some formats may be changed to unify the documents. Your submission's hackmd document may be found at the bottom of this post.

After a period of about a week, our project mentors (@Nebrethar @bistaastha) will comment on the document with advice and direction.

Microtask 0:

Q 0 Review JOSS documentation on submission and review and see how it is related to the current workflow.

The Journal of Open Source Software is one of the primary references used for building out the CHAOSS Badging process. The goal is to compare how the current process works in comparison to the review process of JOSS.

Reference:

• Joss Documentation

Q 1 Review the Core Infrastructure Initiative self-report badging system on projects and events and report schematic differences.

Projects and events are very different, but how different are they in our program? List one thing you would change about either, or both.

Reference:

• CII home page
• Sample CII badge and criteria

Microtask 1:

Q 0 Submit a non-existent project to understand the workflow.

Create a draft PR after adding a mock event in either the Project Badging or Event Badging repository. Record your observations as a part of the microtask.

Reference:

• Project Badging
• Event Badging

Q 1 Review a mock event created by someone else.

If available, take the time to review an event that someone else has posted. If no fake events have been posted yet for this session, use one of the mock events from this year's Google Summer of Code application session:

• https://github.com/badging/event-diversity-and-inclusion/pull/1
• https://github.com/badging/diversity-and-inclusion/pull/2

These are great mock events, but we recommend using a fake event submitted for GSoD, if available.

Microtask 2:

Q 0 Provide a brief summary of the submission and review process.

After reviewing the workflow process and all of the moving parts that create it, provide your idea of how this workflow can be best explained. This task is is focused to the submission and review workflow of the Badging Program.

Concise answers are appreciated, but provide as much detail as you want!

Current Submissions

tharun143 JackieBinya xiaoya-Esther

[JackieBinya]

Hello @Nebrethar I have a few questions with regards to these GSOD 2020-Microstasks listed above. I will admit I am quite a noob when it comes to this process of creating content for a technical writeup.

From what I have gathered the goal is clearly defined, Create documentation for the D&I Badging project. The microtasks then breakdown the monolithic task of creating the documentation at one go to well-defined microtasks which can be completed individually. My guess is these microtasks will be recomposed later to make the actual documentation.

Now as a contributor I appreciate the benefit of the microtasks already although I don't fully grasp the concept and process, by just going through the microtasks it has given me perspective and insight on the executable goals of the project.

Now my questions are:

• You mention that All microtasks must be submitted as a response to this issue. Do I make a submission via a PR?
• Do I complete all microtasks or I choose one or two which may appeal to me?
• Microtask 0 Q0 requires that we Review JOSS documentation on submission and review and see how it is related to the current workflow May I please have a link to a resource with the CHAOSS D&I Badging's current workflow.

Thanks in advance 😊

[Nebrethar]

Hi @JackieBinya and welcome to our microtasks! I am glad you are interested in our project. Here are my answers:

1. I admit this is a rather vague statement 😅 I will fix now. Basically just submit your answers to the microtasks as a comment on this issue, like you just did to ask questions.
2. You complete all microtasks, but don't consider it like you would a test! It's mostly so that you can become familiar with our project and the ideas it came from.
3. All the current workflow spans all of the @badging organization, but the submission and review (the most important parts) are in project and event repositories for diversity and inclusion.

I appreciate that you have asked questions! Let me know if you have any more 😁

[JackieBinya]

Awesome @Nebrethar. I totally get it now 🙂.

[tharun143]

@Nebrethar @bistaastha I hope you are doing well. 😃 I completed the Q0 of Microtask 0 and I am submitting the solution as a response to this issue. I made a tabular form of comparisons and also I listed some suggestions for enhancing the D&I badging program. (suggestions are just my thoughts). 😃 Please feel free to tell me if something is not right 😅.

CHAOSS D&I Badging workflow v/s workflow of JOSS.

The below table shows the comparison between the current CHAOSS D&I badging workflow and workflow of JOSS

	CHAOSS (D&I Badging)	JOSS
Working	CHAOSS D&I badging program works on giving badges for the projects and events.	JOSS works on publishing articles about research software.
Goal	The project aims to increase understanding of the open-source project and event practices that encourage greater diversity and wider inclusion of people from different backgrounds.	JOSS focused on publishing academic journals about research software.
How to submit	Through a pull request	Through a pull request
Request workflow	Firstly, an entry of the readme file will be appended to the respective repository whether it is an event or project. Secondly, a pull request should provide the details of the project or event in the given respective template.	Make your software available in an open repository (GitHub, Bitbucket, etc.) and include an OSI approved open source license. Make sure that the software complies with the JOSS review criteria. Should follow the correct format. (Optional) Create a metadata file describing your software and include it in your repository. We provide a script that automates the generation of this metadata.
Review process	Peer review process	Peer review process and checklist driven by the reviewer.
Grades for submissions	Pending 0-2 Passing 3 Silver 4 Gold 5	Accept Minor Revisions Major Revisions
Hosting	on GitHub open repository	on GitHub open repository
Supports	D&I supports new events and projects	JOSS supports your stand-alone software or contribute to an existing package.
Approved license	Nothing as of now particular (Mostly MIT)	OSI is the approved license
Issue tracker	How well a project issue tracker setup to invite new contributors, skilled contributors, non-technical contributors.	Have an issue tracker that is readable without registration. and permits individuals to create issues/file tickets against your repository.
Documentation	Should includes README/CONTRIBUTING	There should be sufficient documentation for your software.
Externals tools and services	Using exsisting standards of IMS global. Using JOSS as reference.	Uses pandoc for converting md files to pdf. JOSS paper review service can test that your paper is properly strucutured.
Acceptance	The project or event will get a badge as per the requirements met.	The journal will be accepted only if all the requirements are met.
Affiliate	A proud affiliation of CHAOSS.	A proud affiliate of the Open Source Initiative(OSI).
Meta data file (Suggestion)	No metadata file regarding project or event(Suggestion to implement it.)	Create a metadata file describing your software and include it in your repository. We provide a script that automates the generation of this metadata.
Automatic Tweet (Suggestion)	No automatic tweet when a project or event earned a gold/silver badge. (It would be good if we implement it.)	An automatic tweet from @JOSS_TheOJ will announce it!

---

[tharun143]

@Nebrethar Regarding the Q1 in Microtask 1

Review the CII self-report system on projects and events and report schematic differences.

Can I get the resource for CII self-report system?

Thanks in Advance.

Stay Safe and stay healthy 😄

[Nebrethar]

@tharun143

Can I get the resource for CII self-report system?

Thanks for noticing this! It somehow didnt make it into this issue. I have added references for Core Infrastructure Initiative's badging program.

[tharun143]

@Nebrethar

It somehow didn't make it into this issue.

So, Is Q1 part of this issue or not?

[Nebrethar]

@tharun143

So, Is Q1 part of this issue or not?

Q1 of Microtask 0 is the area that I updated in response to your questions 😁 It contains the relevant CII links and a little more information now.

[JackieBinya]

Microtask 0

Q 0 Review JOSS documentation on submission and review and see how it is related to the current workflow.

Overview The Journal of Open Source Software is mature in comparison to the D&I Badging process. By drawing parallels between the two workflows, we hopefully are then able to make improvements to the current D&I workflow.

Listed below is a summary of findings I made from going through JOSS’ documentation:

• The definition, intentions, scope and outcome of JOSS review processes are clearly and well-articulated at the very beginning of the documentation.

  • Definition:

    The Journal of Open Source Software (JOSS) is a developer-friendly journal for research software packages.

  • Description of the review process:

    Formal peer review

  • Intentions :

    Improve the quality of software submitted

  • Outcome of a successful application:

    We mint a CrossRef DOI for your paper and we list it on the JOSS website.

  • Scope:

    Research software packages in the form of research papers

• The guide is split up into sections for different participants as defined the roles they play in the workflow i.e reviewer and author guides, editorial guides etc. There is also provision for search in the documentation.

• The environment where all processes will be carried out is well outlined: All review and submission processes carried out in the open on the Github issue tracker.

• The docs offer information on guiding principles and ethics that regulate the submission and review workflow.

• It's interesting to mention JOSS editors manage review workflow with the help of a GitHub at whedon. The bot automates mundane tasks like fetching data ie editors, review checking the status of reviews etc

Reviewer and author guides These are further divided into different sub-sections arranged in the natural order of the workflow. Find listed below a brief description of each sub-section.

• Outline of submission requirements:
  • In list form potential authors are informed of the minimum submission requirements they have to ensure their work meets in-order to ensure a successful review these include information on licensing etc
  • An example of a paper that meets the outlined requirements is then provided
• Description of the review process
• Outline the requirements for reviewing for JOSS: this section provides information for reviewers
• Review checklist: this section provides a checklist for potential authors.

Editorial guides This section offers guidelines for the editors. These participants are responsible for the smooth flow of the whole submission and review process.

Conclusion The D&I Badging current flow is outlined in this link.The most noticeable differences are:

• The targeted audience in the D&I documentation seems to be project owners or event planners only. There is little or no detail about other participants in the submission and review process.
• In addition to that there is no information provided about the minimum requirements for making a submission nor is an example of a successful project or event provided i.e one that meets minimum requirements.
• Furthermore no bots are integrated into the workflow suggesting that the current workflow is mainly manual.
• One other point I noticed is that the docs are written as one big blob there is no navigation nor provision for search.
• Finally JOSS's docs well articulate that the whole process will be carried out in an open and transparent manner. I think it would well benefit the D&I Badging docs to define the ethics and principles behind the whole submission and review process.

[bistaastha]

@JackieBinya @tharun143 Your microtask solutions look awesome!

@Nebrethar and I will be available for discussing your work and answering other questions about CHAOSS Badging during GSoD office hours(#26).

[xiaoya-yaya]

Hi, @Nebrethar I hope you are doing well. I'm working on my Microtask 1

Q 0 Submit a non-existent project to understand the workflow.

I have opened a draft pr, it's for the first step wrote in the document -- to append an entry in the table, and when I prepared to merge the pr, I found a conversation template to answer the detailed questions in step 2 was already created for me, so I finished it and the process looks like to provide detailed D&I information in the pr description.

So, does this basically the whole procedure or do I need to open another pr and work on the PR template md file?

[JackieBinya]

Microtask 0

Q 1 Review the Core Infrastructure Initiative self-report badging system on projects and events and report schematic differences.

A brief overview of Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices Badge Program workflow

• It provides a way for Free/Libre and Open Source (FLOSS) projects to show that they follow a set of best practices found in this link
  • Best Practices for FLOSS: these are divided into sub-sections described below:
    • Introduction: This section offers a general overview of the Best Practices of FLOSS criteria
    • Terminology: this section provides definitions for terms used to describe the entity being evaluated which in this case is projects.
    • Current criteria: In this section the criteria used in CII is then outlined
• Projects which follow these practices can then self certify and get a Core Infrastructure Initiative (CII) Badge
• the applicants then use BadgeApp to submit an application for a CII Badge. The BadgeApp is a web application found on this link. It is basically a multi-step form.
• 3 tier badges offered namely 'passing', 'silver' & 'gold'
• The best practices criteria and badges are updated continually each badge tagged with a release year identifier.

Conclusion In comparison the D&I Badging program provides a means for opensource events and projects to not only put CHAOSS D&I metrics of the Project Diversity and Event Diversity focus areas into practise but they get to show communities that they are diverse and inclusive.

The schematic differences between CII and D&I Badging program:

• Entities under evaluation
  • CII evaluates FLOSS projects to determine if they are compliant to outlined Best Practices whereas D&I Badging program evaluates open source projects and events to determine whether they put D&I metrics into practise.
• D&I Badging work flow takes place in the open on GitHub whereas CII uses a BadgeApp.
• The CII Best practices define FLOSS projects and associated terms which are referred to in the submission and evaluation process. It would benefit the D&I Badging program to adopt that so as to bring clarity into the workflow.
• The CII Badge is tagged with a release year and the docs give notice about continuous updates to best practices criteria whereas not much information is available about D&I Badge in that regard.

Projects and events are very different, but how different are they in our program? List one thing you would change about either, or both.

Projects and events are indeed different that I do concur. But on first impressions when going through the D&I Badging documentation for both projects and events that fact is not articulated. The assumption is that readers know the the kind of either events and projects being referenced too as well as the difference between the two. The documentation does not provide any definitions for the terminologies used nor does it provide any information about submission requirements.

The only notable difference between the projects and events is in their CHAOSS metrics as expected as they stem from unique focus areas.

My recommendations as a writer is to enrich the documentation. Provide as much detail to the readers as possible, using both CII & JOSS documentation as guideline. In addition to that it I recommend we make the docs easily accessible i.e makes the docs the first thing the reader sees when they navigate to the D&I Badging repos on Github.

[xiaoya-yaya]

Microtask 0

Q 0 Review [JOSS documentation](https://joss.readthedocs.io/en/latest/) on submission and review and see how it is related to the current workflow.

A 0

The workflow of JOSS

Submission -- Submitters prepare the paper into the form that is instructed by the submission documentation, then fill in the short submission form with an ORCID, this form contains basic information of the paper as well as a valid repository address.

After submission -- the review process is raised

An Associate Editor-in-Chief will carry out an initial check of your submission, and proceed to assign a handling editor.

Refer to the JOSS review repository, the assigning process is integrated as a bot to initial a reviewer-raised issue, along with a checklist for the assigned reviewers to work through.

To be a reviewer -- it is similar to submitting a paper. Fill in a form posted on the JOSS website and wait for the editorial team to get in touch.

Upon successful completion of the review -- The accepted JOSS paper is assigned with a DOI, its metadata is listed on the JOSS website, and an automatic tweet will announce it.

The JOSS holds a [website](https://joss.theoj.org/) to exhibit vital information and here is what I found particularly worthy for reference:

• The review process is performed on Github, but entries for submitting a paper or volunteering to review can be easily found on the website. These are the two main parts that involving people in the peer-review system thus using a web-page based interface makes it more available.

• Newly published papers are also tracked on the website along with the detailed review information posted.

We can see the website plays an indispensable role as an interface of the workflow.

Relation to the current workflow

the current badging workflow mainly focuses on applying for badges, a pr is opened to provide the details of a project or an event. The review process is waiting to be detailed.

• As JOSS integrates an editorial bot Whedon, In the badging workflow, a bot can also be integrated for assigning reviewers and interaction purposes (such as reminding reviewers and corresponding project/event managers.)

• A website as an interface for applying badges and volunteering to review can be applied. In the use of the website, we can gain basic information of either appliers or reviewers through a form like JOSS does.

• A checklist opened for the reviewer makes it convenient to track the progress and that is what we can use for reference.

From the documentation perspective, there are some ideas inspired by JOSS:

• JOSS hosts its document on Read the Docs, it’s an online document hosting service, and support clarity authenticity typesetting. This could be taken into consideration as one of the choices to host our docs regarding the community-facing perspective.

• Based on the user story by @bistaastha (thanks astha!), the document should also have respective guides correspond to different roles. Each guide explain responsibility and process to take.

• The documentation should be well structured and have good navigation, which can be realized by using a document hosting service.

• Since there are two kinds of badges -- event badge and project badge, it’s good to define the concept of the project and event that we are referring to in the document.

[tharun143]

Hola, I hope everyone is fine and staying safe. @Nebrethar and @bistaastha take a look and feel free to comment on the work. Looking forward to working with you guys 😄

Microtask 0

Q1

About CII practices

• The CII (Core Infrastructure Initiative) is to show that the projects follow best practices.
  • The fascinating part of this program is the project can voluntarily self-certify, at no cost, by using this web application to explain how they follow each best practices.
  • The CII badging was inspired by the other badges available in the Github.
  • By providing the badges to projects as a result they were more likely to produce higher quality secure platforms. However, there where there is no set of practices that can guarantee that software will never have defects or vulnerabilities; even formal methods can fail if the specifications or assumptions are wrong.

• These best practices have been created to:

  • Encourage projects to follow best practices,
  • Help new projects discover what those practices are, and
  • Help users know which projects are following best practices

• The requirements vary from badge to badge as the badge level goes higher the requirements need to be secure and trustworthy. The standards for the project is also going to vary as the badge level varies.

• As of my observation, avoiding Formal-Peer-Review and relying on the self-certify website is not a good practice. There can be some cases where a project can be vulnerable to the community.

However, I couldn't find the criteria and the background of events in CII. I guess the CII is only for badging projects not for events.

The differences in CHAOSS D&I Badging workflow of event and project are:

Event

• The standards followed in CHAOSS D&I Badging program in verifying an event are more focused on the code of conduct and the demographics of people.

• The attendee demographics in an event can help us to know the diverse nature of the people and it also gives a chance us to know about the commitment of attendees towards diversity and inclusion.

• The Code of conduct plays a predominant role in any event. The Code of conduct provides strict standards and protocols that have to be followed by the attendees in an event. Upon violating the code of conduct a clear avenue is always needed, support and proper justification should be given to victims.

• Diversity Access Tickets are helpful to know about the precious results of an event how the attendees have involved in the event. Direct Access Tickets also shows the interested sponsors.

• Family friendliness of an event shows the diversity and inclusion of an event and also allowing children and youth the events can bring an impact to the diversity and inclusion.

• Understanding Speaker demographics will give a brief insight into the event and it also shares the quality if the event.

  Projects

• Communication channels in the project show how welcoming, responsive, and respectful are interactions even on hot topics of debate.

• Response Time's & Quality shows the quality of the responses from the developers, administrators, or collaborators. It also shows whether the responses are quick or slow and their quality.

• Having proper documentation for projects is predominant and a project without proper documentation is of no use. Having a proper README and Contributing files in a project will attract people from various diversity and it can increase software development.

However, these requirements are not sufficient for validating a project.

• Using formal peer review instead of self-certifying will helps us to avoid vulnerabilities in a project.
• The license should be checked in the projects.
• Security is a primary requirement in any project and having good cryptographic practices in a project can avoid vulnerabilities and attacks in the future.
• Code analysis should be done as a requirement.
• The requirements should be changed for D&I Badging program as the badge varies from level to level. The requirements for the projects in gold and silver should follow best practices and standards.

[tharun143]

Microtask - 1 Q 0

Hola, I hope everyone is fine and staying safe. @Nebrethar and @bistaastha take a look and feel free to comment on the work. Looking forward to working with you guys 😄

I have sent a draft PR to the event-diversity-and-inclusion repository as a part of Microtask-1 Q0

Microtask 1 Q0

Observations

• The questions in the pull request template are in an excellent standard and all the questions are related to the diversity and inclusion of the event.
• As a part of my observation, I would like to suggest that the D&I Badging program should also provide the template for the attendee demographics and speaker demographics. If the particular template for the demographics is given then it will be transparent for any event and all the events will follow a particular order.
• The proof required questions are a great idea. But instead of attaching the pictures how about asking them to mention the social media accounts. So, when the event goes under the peer-review process then the peer can analyze the social media accounts of the event and he can conclude it.
• I had a suggestion for implementing another section in the pull request template about the experience of previous attendees. Surveys should be taken from the previous attendees and the results of the surveys should be submitted in the proof required sections.

[tharun143]

Microtask - 1 Q 1

Hola, I hope everyone is fine and staying safe. @Nebrethar and @bistaastha take a look and feel free to comment on the work. Looking forward to working with you guys 😄

I have reviewed a mock project as a part of Microtask-1 Q1 submitted by @xiaoya-Esther 😄

Mock project

Everything was clearly described and the answers met the requirements. The answers were done in a complete precise manner. A badge of silver could be awarded to the mock project.

The response times and quality has not met the requirements. As only 4 requirements were met according to the badging process of CHAOSS D&I. The silver badge is awarded to the project.

The description of communication channels and issue trackers could be explained more. Instead of giving a one-line answer an essay describing the process in the communication channel and the tags that are used for the issues could be explained more which will give crystal clear idea about the project to the reviewer and the chance of getting a high-level badge can be assured.

[xiaoya-yaya]

I have reviewed a mock project as a part of Microtask-1 Q1 submitted by @xiaoya-Esther 😄

Mock project

Everything was clearly described and the answers met the requirements. The answers were done in a complete precise manner. A badge of silver could be awarded to the mock project.

Thank you @tharun143 for your kind review! 😄

[tharun143]

Thank you @tharun143 for your kind review! 😄

Feel free to review my PR as a part of microtask 😄 @xiaoya-Esther

[tharun143]

Mcirotask - 2

Hola, I hope everyone is fine and staying safe. @Nebrethar and @bistaastha take a look and feel free to comment on the work. Looking forward to working with you guys 😄

Summary

Submission and Review workflow

I submitted a draft PR to the event-diversity-and-inclusion repository on a mock event. The fields involved in submitting an event describes how the events are diverse and inclusive. All the parts involved in creating an event exhibits the diversity and inclusion of an event. The questions differ from project and event.

The attendee demographics and speaker demographics will give better insights to understand the diversity and inclusion of attendees and speakers. The various fields in the attendee demographics and speaker demographics like age, place, region, nationality, and gender, etc can exhibit that diverse people are involving in an event. Having a proper CoC is always necessary for an event. The CoC provides the strict protocols that the attendees had to follow in an event and strict actions will be taken if someone violated the rules at an event. The Diversity Access Tickets exhibits the interest of sponsors in sponsoring the event in the future. Family friendliness will have a great impact on the event and the addition of youth and children to the event can boost the energy of people in the event. By involving the family in the event the diversity and inclusion of the event will be developed.

After answering the questions of the project or event. The PR should be submitted in the open repository. As the CHAOSS D&I Badging program follows the peer-review process the peers will review the PR. As per the requirements met the badge will be provided to the event or project.

If a project or event exhibits a badge receives a badge that means the project or event is following best practices of diversity and inclusion.

I think this was a bit long but I think I have covered all the points. 😅

@Nebrethar @bistaastha All the microtasks are completed. In the meantime, I will try to solve the issues that we discussed in yesterday's D&I working group meeting. 😄 🎈

[xiaoya-yaya]

Microtask 0

Q 1 Review the Core Infrastructure Initiative self-report badging system on projects and events and report schematic differences.

A 1

Here is a brief review of what I found out about the CII badge:

The aim of CII Best Practices badge is

“a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices”

The workflow is self-reported, mostly involving only the appliers to obtain a badge in comparison to the D&I badge peer-review system, which associated with more roles.

The CII badge system focus on Free/Libre and Open Source Software (FLOSS) project, criteria are defined from the FLOSS projects’ perspective and can be divided into six main parts:

Basic Information Change Control Reporting Quality Security Analysis

These are the six perspectives to evaluate how well does the project follow the best practice, and each criterion is well documented, note that the terminology of project is well defined in the documentation found in Github.

I have applied for a badge using a mock project of my own, and find that it has some automatic integration, the system digs out as much information in the project submitted and fulfill the information into some of the questions. As the CII project is built for self-certifying purpose, and false information is difficult to automatic trace and verify, the system does not take measures for faking.

Here are schematic differences I found in comparison to D&I badge:

• The CII badge system requires no review process to apply for a badge, it is a more technical-based self-reporting process. The D&I badge program is mainly manual at present and requires both application and review process.

• The reporting process of CII badge system is performed on a website in the form of filling out a form which contains essay question and multiple-choice; D&I badge program conducts it on Github and uses PR to apply for the badge, each question requires a typing answer. (a draft idea: multiple-choice is an intuitive way of question, consider how to apply it to the MD.file, maybe use a checklist. Just a thought:)

• The CII badge program mainly focuses on software projects while the D&I badge distinguish between projects and events.

• The motivate of CII badge is to encourage projects to follow best practices, in comparison, the D&I badge evaluates from the perspective of Diversity and Inclusion metrics produced by the CHAOSS project.

Another thought motivated by the CII badge criteria is that we should provide clear references or links to the jargon addressed in the PR template, or, they should be well defined/sorted out in documentation.

Project and Event

Below is my definition of projects and events that D&I badging program refers to, not sure if this is correct 😅

• D&I Badging Projects refer to the work of creating a unique produce, service, or result, which are most appreciated to be handled in the opensource community style. Usually, a project holds it’s outcome on GitHub or other code management platforms.

• D&I badging Eventsrefers to tech get-togethers, conferences, festivals, and any other tech event that promote tech-related concepts, mostly off-line meetups, but digital events are also included given in certain circumstances.

The differences between projects and events lay in:

• Aims: projects always hold the purpose to solve critical problems with the productive aim; events serve more communication purposes

• Forms: projects rely very much on online collaboration and technical tools; events are always in forms of conferences and meetings.

• Period: projects can fast grow at the preliminary stage and need long-term maintenance afterward; events are periodically, always holds for a short few days.

• Participants: the participants of events are less fixed than which of projects, and wider in demographics, that’s why attendee is an important factor to evaluate the D&I of an event.

• Outcome: projects tend to have more practical outcomes, however, events put a high value on the influential results.

Adress to one thing I would change about, I think the PR templates still have space to be enriched, I referred to the D&I metrics, found out that the template of events corresponds to the Event Diversity, and the template of projects corresponds to the Project and Community. I think it will be richer to combined with other D&I metrics like Governance, Contributor Community Diversity, etc. since the project idea is based on D&I metrics:)

[xiaoya-yaya]

Microtask 1

Q 0 Submit a non-existent project to understand the workflow.

A 0

Below is the mock project I submitted

Microtsak 1 Q0

Part of the observation are described in the comment above:

I have opened a draft pr, it's for the first step wrote in the document -- to append an entry in the table, and when I prepared to merge the pr, I found a conversation template to answer the detailed questions in step 2 was already created for me, so I finished it and the process looks like to provide detailed D&I information in the pr description.

And here are some other observations:

• Firstly, I clicked on the project badging homepage, it is precisely described on how to apply a badge. But as I described in the patch I think the README.mdexists ambiguous descriptions on instructions, I have submitted a PR to this. > The descriptions above and below the table seem like the same meaning but refer to different things, it's a little ambiguous, so I changed the first sentence into a different expression

• The Pull Request template is in clear layout and each question is well described and easily understood, I also find the reference of each related CHAOSS metric are provided in a CHAOSS-metrics.md file, though it is not so difficult to seek out, I think it will be better to mention it somewhere in the document.

• There is a table at the front of the PR template for basic information collecting purpose, I think it’s clear. But I have a confusion about what the “labels” stands for, I assume it represents whether this badge application is for a project or an event, but it wrote “event“ in a project PR template, so now I’m not really sure what this means.

• Another proposition is to enrich the PR template with more D&I metrics, as I mentioned in Microtask 0 Q 1

• The last observation is also a confusion from above, > So, does this basically the whole procedure, or do I need to open another pr and work on the PR template md file I guess I submit the PR in the right way, so from my view, the present document does not totally match the workflow, since we don’t have to submit another PR for detailed questions. Maybe this part of the doc should be reorganized.

In conclusion, I understand the project is in the beginning state, some of the observations above can be easily solved once the workflow is built out, and the documentation can be well structured and navigated. I’m so looking forward to perfecting these with you guys!

[JackieBinya]

Hello everyone

Is office hours in session yet, as in now?

I am failing to join 😔

On Thu, 11 Jun 2020, 15:03 Esther, notifications@github.com wrote:

Microtask 1

Q 0 Submit a non-existent project to understand the workflow.

A 0 Below is the mock project I submitted

Microtsak 1 Q0 https://github.com/badging/project-diversity-and-inclusion/pull/1

Part of the observation are described in the comment above:

I have opened a draft pr, it's for the first step wrote in the document -- to append an entry in the table, and when I prepared to merge the pr, I found a conversation template to answer the detailed questions in step 2 was already created for me, so I finished it and the process looks like to provide detailed D&I information in the pr description.

And here are some other observations:

-

Firstly, I clicked on the project badging homepage https://github.com/badging/project-diversity-and-inclusion, it is precisely described on how to apply a badge. But as I described in the patch https://github.com/badging/project-diversity-and-inclusion/pull/3 I think the README.md exists ambiguous descriptions on instructions, I have submitted a PR https://github.com/badging/project-diversity-and-inclusion/pull/3 to this.

The descriptions above and below the table seem like the same meaning but refer to different things, it's a little ambiguous, so I changed the first sentence into a different expression

The Pull Request template is in clear layout and each question is well described and easily understood, I also find the reference of each related CHAOSS metric are provided in a CHAOSS-metrics.md file, though it is not so difficult to seek out, I think it will be better to mention it somewhere in the document.

There is a table at the front of the PR template for basic information collecting purpose, I think it’s clear. But I have a confusion about what the “labels” stands for, I assume it represents whether this badge application is for a project or an event, but it wrote “event“ in a project PR template, so now I’m not really sure what this means.

Another proposition is to enrich the PR template with more D&I metrics, as I mentioned in Microtask 0 Q 1 https://github.com/badging/meta/issues/25#issuecomment-642485637

The last observation is also a confusion from above https://github.com/badging/meta/issues/25#issuecomment-641340532,

So, does this basically the whole procedure, or do I need to open another pr and work on the PR template md file I guess I submit the PR in the right way, so from my view, the present document does not totally match the workflow, since we don’t have to submit another PR for detailed questions. Maybe this part of the doc should be reorganized.

In conclusion, I understand the project is in the beginning state, some of the observations above can be easily solved once the workflow is built out, and the documentation can be well structured and navigated. I’m so looking forward to perfecting these with you guys!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/badging/meta/issues/25#issuecomment-642633887, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL7QJD56WI6VRFODKGWCGYDRWDI3JANCNFSM4NTBCFVQ .

[Nebrethar]

Hi @JackieBinya, The office hours are on for the next 50 minutes and the link is:

https://meet.google.com/rip-zkbs-biy

[JackieBinya]

@Nebrethar and @bistaastha May I please have the links you shared during the meeting.

Thanks.

[tharun143]

@JackieBinya

https://hackmd.io/@7f7uN_UHRtOhM5rnON3_HQ/H1NFDGn2L https://docs.google.com/document/d/1WrY4PjOrC_Fp6aiWFjfRRZuujlolSraUlTAJHPfbw9I/edit https://docs.google.com/document/d/1p52ngmP_6CntBIu969VtQO2fPirAwKrjO2TAUo2jRHs/edit#

[JackieBinya]

Thanks @tharun143....

[xiaoya-yaya]

Microtask 1

Q 1 Review a mock event created by someone else.

A 1

Hello mentors, I reviewed a mock event submitted by @tharun143 , the mock event is listed below:

Mock-Event-4 by Tharun

I issued a gold badge to the Mock Event 4 for reasons of: The event meets all the related D&I metrics and further information is provided in detailed description and well illustration.

• [x] Attendee Demographics: the process for measuring attendee demographics is reasonable and effective. Good tools are used. The commitment is considered to be reliable.

• [x] Code of Conduct at Event: is posted on the website; It has a clear avenue for reporting violations and provides support to victims of inappropriate behavior, though concrete information channels are suggested to list in the answer. Besides, the complete CoC is provided, which makes the answer more proof-based and credible.

• [x] Diversity Access Tickets: the metric is perfectly met, it will be even better to define more types of diversity access tickets and specify the criteria.

• [x] Family Friendliness ：Good measures have taken to promote family friendliness and the commitment is considered to be reliable.

• [x] Speaker Demographics: Speaker demographics are measured from plenty of angles and the commitment is considered to be reliable.

[xiaoya-yaya]

Microtask 2

Q 0 Provide a brief summary of the submission and review process.

A 0 Here is my explanation of the workflow: To apply for a badge, firstly, append the name of your project/event in the respective repo’ README.md:

project event

Click the link under the tabular, this will change the README file into editable mode, add your project/event name by following the instruction written in the annotation, and propose changes. Github will remind you to create a pull request, by doing this, a message template is created with D&I metrics related questions that require you to answer. Provide as much detail as you want when addressing these questions as it will help the reviewer to have a thorough overview.

After the PR is submitted, 1 or more reviewers will be assigned to review this PR. During the review process, check if all the metrics are met, and then focus on the detail. (I believe specific criteria shall be formulated for a reviewer to consult about which badge should be issued)

The reviewer should put the badge into the tabular, corresponds to the project/event. This means the badge is successfully issued, and the applier can embed the badge in his website’s HTML or project’s markdown file.

All my Microtasks are finished🎉🎉, this issue is getting extraordinary long, I think I might open another issue to hold all my microtasks, which will make it more intuitive. I wish you all have a nice day.

[Nebrethar]

It was nice to get to know you all on the GSoD Office Hours call!

@xiaoya-Esther brings up a good point:

All my Microtasks are finished🎉🎉, this issue is getting extraordinary long, I think I might open another issue to hold all my microtasks, which will make it more intuitive.

I think it's important that we have a public doc where we can leave comments. Here are the current docs now on HackMD:

Tharun Jackie Xiaoya

I will be reviewing and leaving comments early next week. I have to get to an exam but I will leave more details of the microtask workflow later :)

Thank you!

[xiaoya-yaya]

I think it's important that we have a public doc where we can leave comments. Here are the current docs now on HackMD:

Tharun Jackie Xiaoya

Awesome @Nebrethar, this is better:)

[JackieBinya]

Microtask 1:

Q 0 Submit a non-existent project to understand the workflow.

I submitted a mock event VueGotham-2020, and opened a PR.

These were my findings:

• I initially had problems trying to figure out how to apply for a badge, the screenshots below explain how that came about as well as my recommendations to address the issue.

• After I figured out that the instructions on how to apply for an event badge where in a link called README. I was able to follow the badge application process seamlessly. The questions asked not only ascertain whether an event meets CHAOSS metrics but they offer what I would describe as a checklist for anyone who wants to ensure that their events are inclusive and diverse.
• I stumbled upon this gem of a resource called the Diversity Charter it contains information that might be useful as a reference and in crafting a submission criteria for events. I think we have a rare opportunity to impose an opinionated standard for diverse and inclusive open source tech event through formulating a submission criteria. The submission criteria may include requirements for an events website where data on diversity and inclusiveness is shown amongst other things. I believe that having such a submission standard would safeguard transparency of the application and review processes as well as ensure that all information submitted is accurate.
• Lastly I would like to point out that it would be really nice if we had an in progress and complete labels for pull requests during the application phase. This would help differentiate PRs which are still in progress and those which complete and ready for reviews. Additionally this would put contributors who are making incremental contributions at ease.

[JackieBinya]

Microtask 1

Q 1 Review a mock event created by someone else.

I reviewed a Project Badge Application by Esther link

I did what I would describe as a mock peer review and left the comments in the PR (highlighted in the qoute below) outlining my findings. From my understanding D&I badging reviews ought to be peer reviews this is done so as to allow sharing of ideas within the community so as to collectively improve on diversity and inclusion. The D&I Badging docs currently do not provide a review guide/specification.

My name is Jacqueline Binya. I am a core contributor to the YY-Search. These are some of my recommendations after going through your application: To address How welcoming, responsive, respectful are interactions even on hot topics of debate? What is the diversity of voices speaking/being heard? and How well does the project issue tracker setup to invite new contributors, skilled contributors, non-technical contributors?

• At YY-Search we have a contributing guide which includes a link to a Code of Conduct. The Contributing Guide is quite useful in on-boarding contributors of different levels of expertise to the project. Consequently we are then able to attract a more diverse pool of contributors. The Contributing Guide is written in an easy to understand manner and we made an effort to avoid use of unnecessary technical jargon. Its content includes a general overview of the project, installation and set up guides as well as as basic contributing instructions.
• In the Contributing Guide the participants are explicitly advised to read the Code of Conduct and make sure they understand it before contributing. This has to some extent sanitized our communication channels, as in the Code of Conduct consequences in failing to comply are stipulated.

I therefore issue a passing badge for the project:

[JackieBinya]

Microtask 2

Q 0 Provide a brief summary of the submission and review process.

After reviewing the workflow process and all of the moving parts that create it, provide your idea of how this workflow can be best explained. This task is focused to the submission and review workflow of the Badging Program.

The CHAOSS focus areas which implement D&I Bagding are Project Diversity and Event Diversity.The D&I Badging workflow takes place on GitHub in the open. The CHAOSS D&I Badging workgroup created two repos Project Badging and Event Bagding . All the documentation pertaining to the the D&I Badging workflow and D&I metrics for the above mentioned focus areas is also found in these repos.

In the documentation the prospective applicants are provided with information on how to apply for a badge. This is a two-step process which starts with appending either an event or project in a events or projects table in the corresponding repos of the entities. The table is used to showcase the badging status and/or outcome of either events or projects for which badging applications were made. Because of the underlining git workflow once the applicants append their entities to the tables i.e make changes, they can open pull requests so as to submit their changes. The PRs opened have an embedded template which is a form the applicants are expected to fill out in Markdown. The questions asked in the form are used for D&I assessment. So far review guides or specifications are yet to be advised.

[JackieBinya]

@Nebrethar, @bistaastha and @community

I have made updates to my microtasks and I am happy to announce that they are complete, may you please kindly review them.

@Nebrethar I was not sure on which platform I was supposed to submit my updates . I finally settled on GitHub so that my work is consistent with everyone else's. Please advise am I supposed to also push my updates to hackmd.io ?

Thanks in advance...

[Nebrethar]

@JackieBinya Thanks for submitting your microtasks! Your updates have been added to your hackmd document.

@bistaastha and I plan to review all microtasks on hackmd (adding comments) over the next three days. I also updated the main post with these guidelines. Thank you for asking; it got me moving again!

[JackieBinya]

Hello D&I Badging Community

I would like to excuse myself from today's office hours. Despite my wishes I unfortunately could not attend the meeting. I have a WiFi outage😔. I have been refreshing my browser to no avail for the past 30min. I am honestly gutted.

I am looking foward to catching up on the minutes.

Regards...

On Tue, 16 Jun 2020, 16:09 Matt Snell, notifications@github.com wrote:

@JackieBinya https://github.com/JackieBinya Thanks for submitting your microtasks! Your updates have been added to your hackmd document https://hackmd.io/@badging-sub-2020/JackieBinya.

@bistaastha https://github.com/bistaastha and I plan to review all microtasks with comments on hackmd over the next three days. I also updated the main post with these guidelines. Thank you for asking; it got me moving again!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/badging/meta/issues/25#issuecomment-644789976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL7QJD6POMU7KC6L6HCYNJLRW54IPANCNFSM4NTBCFVQ .

[Nebrethar]

@JackieBinya I appreciate that you mentioned what was going on. I also happen to be having internet issues at home! 😢 See you around. Also, I have an announcement coming up...

[Nebrethar]

I have left comments all of your microtask submissions on HackMD!

Tharun Jackie Xiaoya

Let me know if you have any questions or comments!!! 👍 Still awaiting reviews from Aastha, but they will be here!

@xiaoya-Esther @JackieBinya @tharun143 @bistaastha

[JackieBinya]

Hello @bistaastha and @Nebrethar and @community

@Nebrethar and @bistaastha please review my updated proposal for the new D&I Badging Documentation in this link

@Nebrethar I opened an issue on tagging D&I Badges with release year information as you had advised.

I had almost forgotten, I wrote a blog post about life, the lessons I had learnt about CHAOSS and the D&I Project and finally why I think the D&I project is great. If anyone is interested in that sort of thing please do read and let me know what you think. 🌻

[JackieBinya]

Hello I just wanted to find out if the Office Hours was in session yet? And just to find out is it a weekly event.

[xiaoya-yaya]

Hi @JackieBinya the link is here https://meet.google.com/eot-jikt-for