---
# System prepended metadata

title: Tharun143

---

Tharun143
===

# Microtask 0 Q0
### 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**| <ul><li>Firstly, an entry of the readme file will be appended to the respective repository whether it is an event or project.</li><li>Secondly, a pull request should provide the details of the project or event in the given respective template.</li></ul> |<ul><li>Make your software available in an open repository (GitHub, Bitbucket, etc.) and include an OSI approved open source license.</li><li>Make sure that the software complies with the JOSS review criteria.</li><li>Should follow the correct format.</li><li>(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.</li></ul>|
|**Review process**| Peer review process|Peer review process and checklist driven by the reviewer.|
|**Grades for submissions**|<ul><li>Pending 0-2</li><li>Passing 3</li><li>Silver 4</li><li>Gold 5</li></ul>|<ul><li>Accept</li><li>Minor Revisions</li><li>Major Revisions</li></ul>|
|**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**|<ul><li>Using exsisting standards of **IMS global**.</li><li>Using **JOSS** as reference.</li></ul>|<ul><li>Uses **pandoc** for converting md files to pdf.</li><li>**JOSS paper review service** can test that your paper is properly strucutured.</li></ul>|
|**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!|
---------------------------------------------------------------------------------------

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

# Microtask - 1 Q0


I have sent a draft PR to the event-diversity-and-inclusion repository as a part of `Microtask-1 Q0`
> [Microtask 1 Q0](https://github.com/badging/event-diversity-and-inclusion/pull/3)

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

# Microtask - 1 Q1

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

>[Mock project](https://github.com/badging/project-diversity-and-inclusion/pull/1)

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. ![Silver]

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.

[Silver]: https://img.shields.io/badge/D%26I-Silver-silver?style=flat-square&labelColor=583586&logo=data:image/svg+xml;base64,PHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgdmlld0JveD0iMCAwIDI1MCAyNTAiPgo8cGF0aCBmaWxsPSIjMUM5QkQ2IiBkPSJNOTcuMSw0OS4zYzE4LTYuNywzNy44LTYuOCw1NS45LTAuMmwxNy41LTMwLjJjLTI5LTEyLjMtNjEuOC0xMi4yLTkwLjgsMC4zTDk3LjEsNDkuM3oiLz4KPHBhdGggZmlsbD0iIzZBQzdCOSIgZD0iTTE5NC42LDMyLjhMMTc3LjIsNjNjMTQuOCwxMi4zLDI0LjcsMjkuNSwyNy45LDQ4LjVoMzQuOUMyMzYuMiw4MC4yLDIxOS45LDUxLjcsMTk0LjYsMzIuOHoiLz4KPHBhdGggZmlsbD0iI0JGOUNDOSIgZD0iTTIwNC45LDEzOS40Yy03LjksNDMuOS00OS45LDczLTkzLjgsNjUuMWMtMTMuOC0yLjUtMjYuOC04LjYtMzcuNS0xNy42bC0yNi44LDIyLjQKCWM0Ni42LDQzLjQsMTE5LjUsNDAuOSwxNjIuOS01LjdjMTYuNS0xNy43LDI3LTQwLjIsMzAuMS02NC4ySDIwNC45eiIvPgo8cGF0aCBmaWxsPSIjRDYxRDVGIiBkPSJNNTUuNiwxNjUuNkMzNS45LDEzMS44LDQzLjMsODguOCw3My4xLDYzLjVMNTUuNywzMy4yQzcuNSw2OS44LTQuMiwxMzcuNCwyOC44LDE4OEw1NS42LDE2NS42eiIvPgo8L3N2Zz4K

# Microtask 2 

# 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. 😅

