For past few weeks, I've been writing about my experiences working on ChatCraft, an open source AI chat bot, specifically catering to Software Developers.
So far, my weeks were pretty similar with little change in routine. I worked on some feature or fixing bugs, and reviewed a couple of Pull Requests opened by others. But this week was a little different as I got to be the Sheriff and was responsible for Release v1.3.0.
What is a Sheriff ⭐
Managing a serious open source project is not a walk in the park by any means. With various team and community members continuously contributing to the project, it gets pretty challenging to maintain the new and existing issues, incoming pull requests and the quality of code they bring that will ultimately land in production.
Which is why we need a Sheriff to help developers shepherd their code through the development and review process so that it can be landed cleanly in git, and to do so without breaking any tests, CI automation, or infrastructure. (See How to be a Sheriff)
Responsibilities
People often confuse a Sheriff as someone being responsible for fixing each and every problem, which is not the case.
Open Source is driven by community effort, and a Sheriff is responsible for coordinating those community efforts to quickly land fixes, and make decisions to keep the project going.
In ChatCraft, we have a rotation policy and every week there are two Sheriffs - one Primary and a Backup sheriff in case the person scheduled for the week is unable to perform duties. The primary responsibility is being available as the first line of defence in case anything anything goes wrong, keeping concerned people aware of ongoing problems, and getting necessary help to resolve them.
There are many responsibilities of a Sheriff and a good list of those duties can be found in this wiki:
https://github.com/humphd/osd700-winter-2024/wiki/How-to-be-a-Sheriff#responsibilities
Me as a Sheriff
I mentioned at the very beginning that I was scheduled to be ChatCraft's Sheriff this week. And now that we know the associated responsibilities, I'd like to share my experience being in the role.
Running the weekly Triage
Every Wednesday, we have a Weekly Triage meeting where the entire team gathers to discuss existing issues, pull requests and subsequently plan for the upcoming release.
This was when the Sheriff from previous week handed over the responsibilities to me, and I was to run the Triage.
Here's how it went:
- I started by looking at the existing Pull Requests opened for issues in the current release cycle (v1.3.0). We discussed 3 main things - how was the progress, if there are any roadblocks, and if need to schedule it for a further milestone.
- Next, I opened the list of issues scheduled for the week's milestone and again, we discussed if the issues could be closed within the milestone or if there were any showstoppers.
- The last step was to plan for the upcoming release v1.4.0. I asked everyone to move any of their assigned issues that they would like to Milestone 1.4 and also did it for myself. Once we had some initial issues scheduled, I started going through the list of existing unassigned issues - anyone aware of it explained the context, anyone interested asked to be assigned and the issue was moved to the upcoming Milestone if the assignee was comfortable with it.
Going through issues and pull requests also sparked some healthy discussions keeping the team engaged and up to date with what's happening with the project.
Here are the meeting notes if you're interested:
https://github.com/humphd/osd700-winter-2024/wiki/Meeting-Minutes-%E2%80%90-Milestone-1.3
Making Contributions
Being a Sheriff does not mean you're exempt from contributing yourself. You need to put some effort in striking a balance between helping others and delivering your own work.
In total, I got 3 contributions this week and a breakdown is as follows:
1. Improve audio recording UX: This one was a follow up to another issue in which I changed the mic recording behaviour to click instead of drag. All I had to do was add better indicators to the mic button, so users could easily identify the recording state of the control. So I added a Tooltip, a basic size and color transition to fix the problem.
2. Fix viewport pushed by switching chats: This was another instance of a pretty old issue that I fixed back last October. Since I had almost forgotten what I did back then, I revisited by blog post where the solution was documented, and quickly opened a PR with the fix. As this was essentially a regression, Dave (my professor) suggested we need to find a better fix for this. So I filed a new issue for it.
3. Make Sidebar Responsive: This was a continuation to an old Pull Request that I had put up last November. I have blogged about the problem and solution in my last post. But this was the final result on mobile.
Refactoring: Since this introduced a lot of duplication for sidebar related styles and logic, I tried to minimize that duplication by creating separate components for mobile and desktop sidebars and exposing them through a common Sidebar component.
I opened the Pull Request as soon as the sidebar changes were merged, but since it was late in the week and review were pending, I decided to move it to the next release.
Getting the PRs Reviewed 👁️
This was not too different for me as even normally we're expected to do code review for PRs that request our review.
But since a Sheriff is the one responsible for the either reviewing or getting the code reviewed as soon as possible, I had to make myself available all time. And as soon as a new PR was up, I went through the it to make myself of the changes and assigned reviewers appropriately based on their expertise.
I don't know WHY, but I felt like I wasn't entitled to request people for reviews if I didn't do myself as well. So I tried to review as much as I could. Normally I do around 2 code reviews each week. But this week was a little crazy as I reviewed 9 PRs in total and didn't realize until I counted.
Here's a list if you're interested:
- Command button enhancements
- Search Bar Placeholder Text
- Created list of supported ChatCraftProviders
- Allow users to authenticate with Google OAuth
- Replaced padding to use relative value
- Shorten mobile placeholder
- show delete submenu only when there is more than 1 delete option
- Allow running JS/TS remotely via val.town's eval endpoint
- Fix search/share id loading bug
Isn't that Crazy!
Time for the Release 🚀
All that hard work finally paid off as we were able to close most of the planned issues
And got to release ChatCraft v1.3.0 at the end of the week.
In this post, I discussed about the roles and responsibilities of a Sheriff in Open Source, and my experience Sheriffing a quality open source project for this week 🚀
Hope you enjoyed the post!
And here's one for me creating my first Software Release 🍻
Top comments (0)