GSoC with CHAOSS - Community Bonding reports

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.

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 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: