xiaoya-Esther
===

# Microtask 0 Q0

## The workflow of JOSS
**Submission** -- Submitters prepare the paper into the form that is instructed by the submission documentation, then fill out the [short submission form](https://joss.theoj.org/papers/new) with an ORCID, this form contains basic information of the paper as well as a valid repository address.

**After submission** -- the review process is initiated

> 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** and **volunteering to review** can be easily found on the website. These are the two main parts that involve people in the peer-review system, therefore 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 with assigning reviewers and interaction purposes (such as reminding reviewers and corresponding project/event managers.)

* A website as an interface for applying badges and finding reviewers can be developed. In the use of the website, we can gain basic information of either appliers or reviewers through a questionnaire like JOSS does.

* A **checklist** opened for the reviewer makes it convenient to track the progress, I think this is what the badging program can refer to.

### From the documentation perspective, there are some ideas inspired by JOSS:
* JOSS hosts its document on [Read the Docs](https://readthedocs.org/), 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 D&I badging docs from the community-facing perspective.

* Based on the [user story](https://github.com/bistaastha/badging-meta/issues/3) 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.

# Microtask 0 Q1

### Here is a brief review of what I found out about the [CII badge](https://bestpractices.coreinfrastructure.org/en):
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 involve 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 a project follow the best practice, and each criterion is well [documented](https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md), 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 under 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 to prevent 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 questions and multiple-choices; 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 jargons mentioned 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 Events `refer 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 those 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.

**Refer 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](https://docs.google.com/spreadsheets/d/1tAGzUiZ9jdORKCnoDQJkOU8tQsZDCZVjcWqXYOSAFmE/edit#gid=0), 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 combine with other D&I metrics like Governance, Contributor Community Diversity, etc. since the project idea is based on D&I metrics:)

# Microtask 1 Q0

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

# Microtask 1 Q1

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

> [Mock-Event-4 by Tharun](https://github.com/badging/event-diversity-and-inclusion/pull/3)

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.

# Microtask 2

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](https://github.com/badging/project-diversity-and-inclusion)
> [event](https://github.com/badging/project-diversity-and-inclusion)

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.