JackieBinya === # Microtask 0 Q0 **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](https://github.com/badging/project-diversity-and-inclusion).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. # Microtask 0 Q1 **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](https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md) * `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](https://bestpractices.coreinfrastructure.org/en/projects/1#changecontrol). 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 make the docs the first thing the reader sees when they navigate to the D&I Badging repos on Github. # Microtask 1 Q0 `Q 0 Submit a non-existent project to understand the workflow.` I submitted a mock event `VueGotham-2020`, and opened a [PR](https://github.com/badging/event-diversity-and-inclusion/pull/4). 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. ![one-2](https://user-images.githubusercontent.com/50267279/84676684-15f5ad00-af2e-11ea-9a19-d26177157013.png) ![one-3](https://user-images.githubusercontent.com/50267279/84676718-1e4de800-af2e-11ea-885c-8d775a0ff753.png) * After I figured out that the instructions on how to apply for an event badge where in a link called [README](https://github.com/badging/diversity-and-inclusion/blob/master/README.md#applying-for-badges). 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](https://diversitycharter.org/) 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. # Microtask 1 Q1 I reviewed a `Project Badge Application` by Esther [link](https://github.com/badging/project-diversity-and-inclusion/pull/1) 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](https://google.com). >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: <img src="https://camo.githubusercontent.com/038a8f888ac3ff52e6be97529274d42705d0d075/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f44253236492d50617373696e672d70617373696e673f7374796c653d666c61742d737175617265266c6162656c436f6c6f723d353833353836266c6f676f3d646174613a696d6167652f7376672b786d6c3b6261736536342c50484e325a7942325a584a7a61573975505349784c6a4569494868746247357a50534a6f644852774f693876643364334c6e637a4c6d39795a7938794d4441774c334e325a794967646d6c6c64304a76654430694d434177494449314d4341794e54416950676f38634746306143426d615778735053496a4d554d35516b51324969426b50534a4e4f5463754d5377304f53347a597a45344c5459754e79777a4e7934344c5459754f4377314e5334354c5441754d6d77784e7934314c544d774c6a4a6a4c5449354c5445794c6a4d744e6a45754f4330784d6934794c546b774c6a67734d43347a54446b334c6a45734e446b754d336f694c7a344b50484268644767675a6d6c7362443069497a5a42517a64434f5349675a443069545445354e4334324c444d794c6a684d4d5463334c6a49734e6a4e6a4d5451754f4377784d69347a4c4449304c6a63734d6a6b754e5377794e7934354c4451344c6a566f4d7a51754f554d794d7a59754d6977344d4334794c4449784f5334354c4455784c6a63734d546b304c6a59734d7a49754f486f694c7a344b50484268644767675a6d6c736244306949304a474f554e444f5349675a443069545449774e4334354c44457a4f533430597930334c6a6b734e444d754f5330304f5334354c44637a4c546b7a4c6a67734e6a55754d574d744d544d754f4330794c6a55744d6a59754f4330344c6a59744d7a63754e5330784e793432624330794e6934344c4449794c6a514b43574d304e6934324c44517a4c6a51734d5445354c6a55734e4441754f5377784e6a49754f5330314c6a646a4d5459754e5330784e7934334c4449334c5451774c6a49734d7a41754d5330324e433479534449774e4334356569497650676f38634746306143426d615778735053496a52445978524456474969426b50534a4e4e5455754e6977784e6a55754e6b4d7a4e5334354c44457a4d5334344c44517a4c6a4d734f4467754f4377334d7934784c44597a4c6a564d4e5455754e79777a4d793479517a63754e5377324f5334344c5451754d6977784d7a63754e4377794f4334344c4445344f4577314e5334324c4445324e5334326569497650676f384c334e325a7a344b" alt="CHAOSS Passing Badge" /> # Microtask 2 Q0 >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](https://github.com/badging/project-diversity-and-inclusion) and [Event Bagding](https://github.com/badging/event-diversity-and-inclusion) . 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.