GSoC with CHAOSS - Community Bonding reports
Published: 2020-06-15 18:14:51

Hello reader!

These are my combined Community Bonding reports related to my GSoC work with CHAOSS.

TL;DR: I had four awesome weeks figuring out more about my project.

Here is the week by week summary for everything under community bonding period :)

**Week one [May 5 - May 11]**

This week I focused on taking out things out of my proposed work plan and arrange them in the form of issues and to-do lists.

After taking around 48 hours processing that my proposal was selected, explaining to my family what GSoC was and maybe a little bit of excited squealing somewhere in that time, I attended my first meetings on Wednesday as a GSoC student!

From there on mentors Matt S. and Saleh spread out the meeting schedule for CHAOSS Badging work for me and Tola, and Matt G. welcomed us on the D&I WG meeting.

On the meeting, we worked on a portion of Documentation Accessibility abd discussed Badging, and how the GitHub interface might potentially end up hindering non-developer applicants.

-----

Workflow management is an important thing here, and milestones on GitHub work well for me. Starting on I divided my tasks into lists and further created issues to keep track of progress and additional considerations. Also, I created user stories to gain a better sense about expectations and inferences related to CHAOSS Badging, and I would be making changes to them frequently in the near future. 

There were a bunch of tasks from the proposal which live as issues [here](https://github.com/bistaastha/badging-meta/issues).

Our work and community experience during the rest of the week was discussed on the Sunday Badging Session, where I asked a bunch of questions we had acquired.

Overall, this week was super positive, and this makes me even more excited about the things to come.

**Week two [May 12 to May 18]**

This week I started working on roles, and on exploring a bit about how Probot based GitHub apps could become a part of the CHAOSS Badging workflow and speed it up.

Roles for CHAOSS Badging is basically categorising participants according to what they would usually do within the Badging workflow. I divided each role into two parts:

- Responsibilities - what a certain kind of participant would at least be required to do in the process
- GitHub permissions - what things they would be able to do on the GitHub interface

[Repository permission levels](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization) allow for a more granular approach to what a member of a team on an organisation account GitHub would or would not be able to do on any certain repository, and there are certain levels defined for each role.

**Week three and four [May 19 to May 31]**

During this time I worked on reading more about how JOSS reviews worked, and then creating guidelines for Badging project reviews based on CHAOSS metrics. In the current form, the requirements state what a Project associated with an application would need to have at the minimum. This also lead to the beginnings of work on Review Checklist, which would be something a reviewer would compare with and mark their observations over.

To simplify roles created during the past week, Matt S. suggested that the permissions required for Badging can be represented in a simpler table. There are two parts to this represetation: the things a person in a perticular role would do under the Badging process and the things they would likely have the ability to do.

Associated links:

- Roles permission table: [Google Docs](https://docs.google.com/document/d/1W_W5IaAEm1cxigjtIaCXrVNz7yryr76oATCy4LdG3HE/edit) | [GitHub](https://github.com/bistaastha/project-diversity-and-inclusion/tree/latest/submission)
- Submission Guidelines: https://github.com/bistaastha/project-diversity-and-inclusion/tree/latest/submission
- Review Checklist in a Gist: https://gist.github.com/bistaastha/b7b7c8ca2139113f9cd7c58a7fa3177b