git

As my Data Journalism professor said, git is a form of black magic done on computers, which makes knowing it feel like knowing ancient sorcery. To people who don’t understand what git does and why it is so widely used, it seems extremely complicated, and it seemed so to me.

While I don’t claim to be an expert on git, I’ve used it extensively in my CS electives. Texting your teammate to approve your PR makes you feel like a real software developer, which is pretty cool. However, learning git wasn’t easy since in most classes, instructors (probably to emulate a real-world scenario) threw a bunch of git knowledge at the students and hope it’s stick.

This is why I appreciated the step-by-step git activity in class this week, since it gave me a much needed refresher on the core functionalities of this framework. At home, I decided to recreate the steps we’d done in class on my local machine and finished the activity in no time.

extension activity

Our extension activity, which I briefly discussed in last week’s post, went super well! We managed to get together after class on Monday (although one of the team members joined later because he had a job interview!! and it went well) and do most of the work.

I found Mozilla’s JavaScript APIs catalogue extremely helpful when looking for the methods we might use, for example the methods under tabs and storage. I also had to figure out the roles of background.js and popup.js files as well as the actual user-facing page of the extension popup.html. When my teammates and I had combed through all that information (skimming most of it, honestly), it was time to build the extension. It took the most time and a decent amount of googling, but we came up with a prototype by the end of the day. It took some simple polishing up and setting up the project’s structure until we finally had a presentable prototype.

I enjoyed working with my team. I would genuinely say that we did an equal amount of work on this project. Since none of us was familiar with making an extension, it was great to learn together. We did have an issue at the very end because the teammate that pushed the repo on GitHub did not give us admin permissions, so we had to wait for hours to merge our changes into the main branch.

presentation day

I loved each presentation! All developers presented their projects so creatively and professionally that the class began to feel like a conference of software developers at something akin a Mozilla event. Frankly, the really cool and original features of some of the projects (such as custom logos or a branded issue template) made me wish we’d gone with a simpler idea but prettier packaging.

For our project’s code of conduct, I decided to go with No Code of Conduct. I liked this concept when I was exploring small open source projects, and this felt like a chance to use it. I still think that templates like the Contributor Covenant are great — they do preach important things like mutual respect, no discriminatory language, no “me” centrism, etc. However, we are all adults, and we are capable of telling when someone is being inappropriate. And if I were a maintainer of an open source project, I wouldn’t need to consult a code of conduct to take action.

I also assumed (correctly!) that other teams would go with a more conventional template, which would make our project stand out.

Since I was responsible for including No Code of Conduct, I took the most of the questions about it during our presentation. I loved where our discussion went — how does this document ensure contributors aren’t being violated every 5 seconds? Well, No Code of Conduct has an answer to this, which is “Whatever you do, do not make a scene” and “Do not engage.” Probably like many others, I am on the fence about this approach, but I still think it’s cool and kinda badass.