pull = fetch + merge:

This week my browser extension team met up and worked alongside each other. I also usually just default to git pull but I did notice that I would continuously git pull and git push and be met with merge conflict errors. It took some getting used to especially since prior to this I’ve only simultaneously worked with one other programmer on the same repository. Looking back, if I had remembered to separate the commands then the split (read: miniscule) second of panic I had would not be a thing.

Haha, dont rm rf * you’re so sexy:

I actively avoid the rm command just because I’m always paranoid about deleting something very big. I just always assumed that if I accidentally deleted something, my chances of recovering it were nil.

Jellyfin:

A free server to store and stream self-owned media. Their documentation was so robust that it was almost overwhelming. It is definitely made apparent that this is a project forever meant to be free and accessible. An interesting component was rather than simply including the link to their Github, they offer a questionnaire and depending on your answers will provide the repo. I assume this was mainly due to the various different repositories they have for plug-ins, servers, clients, etc. A quick look at the issues log indicates that participation and communication is consistent, averaging a new commit multiple times a week with multiple comments. Personally, I wouldn’t look to Jellyfin as someone just dipping their toes in OSSD. While their instructions are extensive, it seems a little overwhelming and would probably be best for someone who is an active user of the service.

Going Forward

I have been browsing through repos I mentioned in my prior post, especially through their issue lists. Something that stuck out to me was the Exercism team’s note of repos that have “easy first issue” tags, especially since it is often hard to figure out the complexity of an issue before it is properly fixed. Rather than basing possible PRs on the tags, I want to look closely at how often I see consistent communication under tickets in case I ever need to ask for further insight about a bug.

My team is a very friendly bunch. We decided on making a Google Extension but have yet to decide what it should be. Overall, everyone seems very capable. In terms of difficulty, the only setbacks were unfortunately on my part due to an issue I had with the beastify extension tutorial on Firefox. Since a big portion of the time was spent trying to fix it, we had to move on and only got to part 3 of the project. Moving forward, we have all agreed to meet in the coming week in person to work on our project. As of right now, I am still brainstorming on potential extensions that could be made.

In terms of contributions outside of class, I’ve started dipping my toes in Wikipedia. Besides looking at suggested articles to revise links, I have tried looking at files pertaining to my culture and native language to see if anything further can be added. I have also gotten in the habit of browsing other open source projects. Some users on the open source subreddit have lists of beginner friendly FOSS to contribute to. (https://github.com/MunGell/awesome-for-beginners?tab=readme-ov-file) is a list of open source projects in multiple languages that are great for first pull requests.

Part 1: The Code of Conduct is a solid foundation for community etiquette. It acknowledges that conflict can be inevitable especially with bigger communities, and therefore is supposed to be used as a way to ensure respect is always given. In the event that anything is violated, it also provides a medium to alert of any violations, making community members feel safer.

This does seem beneficial for other projects as it makes it highly clear that above all, respect must be fiven in a community that requires such large scale of communication.

The Go project includes its own section on conflict resolution unlike the Contributor Convenant. While CC does briefly mention the difference between constructive criticism and hatred, the Go project elaborates on this. This could be because they acknowledge the difficulties that come with disagreements in an open source community, and seek to emphasize that it is different from unacceptable behavior listed. The Go project also added in the explicit goals of its Code of Conduct. It seems to highlight the parts of its conduct that were implemented specifically for Go. For example, one of the goals emphasizes healthy debate, which is elaborated on in the previously mentioned section.

(https://www.eclipse.org/org/documents/Community_Code_of_Conduct.php) - Eclipse’s Code of Conduct has extra sections emphasizing action and investigation against all violations, including false accusations. It also highlights that the code is subject to change. As a bigger community, it makes sense for Eclipse to have bigger potential violations; so, of course, over time Eclipse has amended its code with standard procedure for their investigations.

Part 2: The Sugar Labs Code of Conduct is based on the Ubuntu Code of Conduct. It seems to include more emphasis on delegation/authority in terms of how hierarchies may work; it even specifies instances of a step down in authority, making sure to emphasize that leaving the community when necessary is not frowned upon and must be understood.

Part 3: (https://exercism.org/docs/using/legal/code-of-conduct) - Exercism’s Code of Conduct is derived from Front End London Slack (https://github.com/frontendlondon-slack/Code-Of-Conduct). As a document, it is shorter and more bullet point heavy than Ubuntu and CC derived codes. This could be to encourage reading the code, but Exercism include’s its own “The simple version” section, made to summarize rules of etiquette. Besides that, Exercism does not delve into specifics regarding decisions or healthy disagreements unlike Eclipse and Sugar Lab’s codes.

When I think of open source, the first things that pop in my head are Discord and community guidelines. This is mainly because any open source projects I’ve come across are very transparent about communication in order to improve the project, as well as focusing on growing their community. Often times, their guidelines are mentioned in the home page for new users including a public discord invite. The main advantage of open source would have to be extensive documentation; since the community is forever growing, its important to make sure anyone who is just joining can follow the flow of changes made without issue. One of disadvantages in comparison to closed source projects would have to be the response time sometimes. Just because a community is big doesn’t guarantee that requests will be met quickly, and sometimes there is an overload (too many cooks in the kitchen). I decided to register for this course because the idea of working more on open source projects interested me, and it seemed like a great way to force myself to socialize and practice working in tandem on a project.

The most common open source projects I use these days include:

Hot-And-Cold - A reddit game that has to do with word association. It is a running joke that all users have a love hate relationship with it as word rankings sometimes don’t make sense (like how is the word carrot but then bunny is ranked 1000 and tomato is ranked 650???) I just found out it is OSS so the devs do accept further help and it has me curious as to how the word rankings are determined.

GIMP - When i first got into editing as a kid and I didn’t have photoshop money, GIMP was the only application that had extensive tutorials on it that I could use. Though I don’t use it as much now, I recently found out that it has been FOSS this entire time.

Exercism - It’s an open source coding website for coding practice in 100+ languages. I sometimes use it when I am bored, or when I want to practice a new language I just came across. They provide documentation and are very transparent about how anyone can contribute.

p5.js - An open source software that is great for using javascript and learning for websites and the sort. I’ve used it in high school and IDM courses.