Supporting Contribution Efforts within Richie Bus Schedule
Project Introduction
The project that I had chosen was the Ritchie Bus Schedule ran by Hiro Takeuchi, a software engineering major here at RIT. I picked this because of the Commarch we ran on the project for our final presentation. A smaller project, this project had 5 contributors prior with Hiro leading the commits by 70+. However, the Coefficient of Fail for this project was off the scale, with a total of 145 FAIL points. The categories which failed included bundling from source, communication, and documentation. Over the past few weeks, communication and documentation have improved, but this issue led into the core of my contribution.
Finding Issues and Contribution
In order to contribute, contributors could visit the “How to contribute to the bus app” Wiki page found here. This walks through on setting up the environment locally on a contributor’s machine:
Ritchie’s Bus App GitHub
All good first issues are marked with “good first issue” on the issues page found here. This is a good place for contributors to find issues, and where I found what issus I wanted to work with: Issues
Originally for my contribution, I planned on fixing accessibility issues for the bus page’s info button. I thought given my web background that this would be a simple fix. I started work on developing, and added aria-labels with proper labeling onto the buttons relating to the issue. The issue request can be found here:
Accessibility on bus page’s info button
However, I ran into several issues when it came to duplicating the environment on my local device. This issue arose from a seemingly new addition to the app of a Redis database. When trying to troubleshoot with Adrian, HFOSS TA and fellow contributor, the issue seemed newer and the Redis base seemed like a new addition. So to still contribute to the project and provide help, I decided to report issues and possible solutions that could lead to a future contribution.
Fixes
The fix for my original issue was never tested due to the local environment issues above, but here was the fix I attempted to implement:
return (
<div aria-label="Bus Stop Information">
<TooltipProvider>
<Tooltip open={open} onOpenChange={setOpen}>
<TooltipTrigger asChild onClick={() => setOpen(!open)}>
<Button
variant="ghost"
className=" aspect-square p-0 py-0 hover:bg-slate-300"
>
{children}
</Button>
</TooltipTrigger>
<div ref={tooltipRef}>
<TooltipContent>
<p>{tipMessage}</p>
</TooltipContent>
</div>
</Tooltip>
</TooltipProvider>
</div>
);
The first issue was relating to how Redis connections could be implemented on the Wiki page for contributing to the project. When documenting this issue, I walked through the process of how I reached the issue through the environmental variables as well as all of the errors that I had documented when walking through setting up the Redis database. This included a text file of errors, photo documentation within the .env file, and documentation relating to setting up a project within Redis. I provided the solutions that could arise from this issue, which is creating a new “Connecting to Redis” Wiki page as well as adding said Wiki page to the contribution documentation. My feature issue request can be found here:
Connecting to Redis Wiki Page
The second issue was relating to the “How to contribute to the bus app” Wiki page. This issue arose when I was trying to set up my local environment. To set up the local environment, you have to set up Clerk authentication as well as Supabase connection. However, under section number 3 of the document, the links reroute back to the home page of the Wiki. Since I was led in a circle, I was struggling to find the resources to actually set up the environments locally which led to delay and confusion. So to prevent from similar issues arising, I created a bug issue request which can be found here:
Connections to free external services
Blockers
The blockers for my project were outlined heavily above, as my main blockers led to my main contribution. I hope in the future to be able to build off of these blockers to lead to more contributions down the road, whether that be building a new page on how to connect to Redis or solving the issue above with the aria-labels.
Conclusion
Overall, while frustrating, this was a great project to work on. I didn’t get anything merged, but I was able to create and label issues that can be expanded on in future contributions. Being on the ground floor of a newer project is exciting, but that comes with challenges. The lack of documentation was a struggle, and led to confusion with my original issue. I’m glad to be able to contribute to a growing RIT based project, and support the future contributors on the project. I’m sure the issues that I had faced aren’t isolated to only me, and these are going to be vital for project leaders like Hiro so that developers are able to work on their own. Overall, I had a good experience and I hope to continue contributing in the future.