Currently, we are focusing on Implement missing domain objects with full validate() function #21970 in the Oppia project. One shocking thing we found out is how structured the getting started guide is for Oppia. We had to fill out a bunch of forms and surveys, which showed the project has been around for a while and is very welcoming to beginners. This week, we asked the maintainers to assign us parts of the issue so we can start working on it. We described the changes we plan to make in the pull request to ensure we understand the problem correctly. We are currently waiting for a response; in the meantime, we are exploring other issues and testing the platform for bugs.
]]>I have also noticed teams discovering projects by looking at open-source alternatives to the projects they were already using. The group AFFiNE for example, chose it because it was an open-source alternative to Notion. This is also a really nice way to discover new projects that give meaning to contributing. It makes it so you are not only using the free tool but also contributing to it as a way of generously paying it forward for other people to have a better product.
Our groups planning stages were also very similar to most of the posts I have read so far. We have initially short-listed a bunch of alternative or overall projects that we use on a daily basis. We have then removed the projects that we were not familiar with or took way too long to set up. This eventually led us to Oppia.
]]>good-first-issues tag.
This led to eliminating near half of the projects. After which we have decided to eliminate projects that requires a previous domain knowledge about for example quantum physics. This led to us short listing about 5 projects at the end. Choosing between these 5 took awhile as we wanted to see which one would be best for all of us. We ended the meeting with the 5 short listed project and decided to go home and think more in detailed about each of the project along with trying to set it up. Over the weekend we all tried the projects and ended up deciding to work on oppia due its documentation for new comers and also this project covered a wide variety of languages.
Our group did not hit any obstacle. I think all of our communications were really good and overall my team is very supportive. We have all listened to each others thoughts and discussed every idea as a group. Decision making in this case did not take much time as though the encouragement of discussions and weighing in the pros and cons we have easily decided on a project to work on.
]]>I am hoping to contribute to projects like openfoodfacts, which I used to a personal food tracker app I built last summer. I really liked their free api and the project overall and would like to give back. I am also hoping to contribute to flutter as I am beginning to like it a lot better compared to the react native alternative for cross platform development. I find flutter to be very easy to understand and have started to use it for one of my recent project. I think it would help me improve my coding skills a lot more by reading the source code and contributing to it. As I am still a beginners and flutter being notorious for delaying prs in the past, I think the biggest barrier might be getting pr’s approved. Also getting myself familiar with the project may also take some time.
]]>Presentations are not just about learning about other projects but also about learning how other teams have come up with their idea through the ideation process and how did they handle conflicts. Our group had pretty much a smooth run from the start, Paul and I have found a weird connection where we both agreed on most of the topics. To the point where we would try to purposefully try to disagree to see if our decision is the correct one. Working on this project has taught me how crucial it is to have discussions especially when working on open source software development. Nobody can one-off just work on something themselves and push a PR out of nowhere expecting it to get merged. It is crucial to communicate and explain one’s thought process so that not only everyone can be on the same page but also discover if the solution is the right one or there exists a better one.
During the class last week we watched a collection of videos from the Open Source Summit of North America (2024). While watching this video something that caught my attention is how dedicated some open source maintainers are to the idea of FOSS where the idea of free is freedom. Even when companies take the project to make money off of it, maintainers stick to the core principles. I found it to be very inspiring where the host has turned down significant potential money to stick to the principle of FOSS, where anyone can take the source code and do whatever they want with it according to the license.
This week was packed with various presentations from students to professional ones. One thing that I took away from these presentations is that speaking slowly and also being present matters a lot. The most enjoyable presentations were the ones given by the likes of Linus Torvalds, which did not seem like a lecture or talk but casual, funny and also informative. He would laugh and make jokes here and there which made the talk even more enjoyable. I have also noticed this during our presentations in class, where the most engaging presentations were by groups that were lively, present and interacted with the audience. I hope to implement these skills in the upcoming presentations.
]]>git for a long time, but I was surprised to learn what is the proper way of using git. I was mostly familiar with the 3 most commonly used commands of add ., commit -m "", and push. In class we learned that relying too much on add . command is not conventional and often disliked by people, as this could lead to adding files you don’t want to be tracked ending up being tracked and becoming a hassle to remove later. I have experienced this first hand today where I unzipped a large file inside the git repo but before checking the size I added all, committed and when trying to push it failed. Getting back to untracking the files and resetting without losing my changes took a lot of time, which could have been easily avoided if I added the files I needed manually and not used the add . command.
We have also learned about the git init command which had the most impact on me. Personally when I am working on a project I end up first making the git repo and cloning it or if I make a mistake I reclone the repo into a new location. This seemed like a hassle to me but it let me get by as I mostly worked on private repos, but learning about git init significantly improved my workflow where I no longer have to do that.
Based on the Project Evaluation I have seen a wide range of projects ranging from quantum computing to javascript libraries. These selection of projects in my opinion covers a wide range of topics which is good for our upcoming project. The maintenance of the selected projects mostly seemed very organized and mostly beginner friendly.
I have personally found jellyfin to be the most exciting project to work on. This is mostly because I self-host this in my home server and have been tinkering with it for a while. I love this software and want to contribute to its development in a way of giving back.
The biggest challenge would be getting familiar with the codebase of jellyfin in a short amount of time. I would be curious to hear you guys thoughts on how to pick up a project structure and get familiar with a code base fast, feel free to email me kazi.h@nyu.edu. Currently I am planning to overcome this by getting my hands on not only reading the code but also writing out smaller functions to check how everything interacts together.
]]>What made this learning to build extension over a short period so fun was my teammate Paul Chan. Any time I would get stuck we would discuss and try to figure it out together. This was very effective and surprising to me as due to this none of us got stuck an issue for too long. We enjoyed the process of hands of building the tool and discussing ways to improve it at the same time. I also like JavaScript and enjoyed writing code for the extension. My biggest contribution was refining the idea for this extension.
We have nailed on the idea of building an NYU wallpaper chrome extension. Right now every new tab is a boring monochrome color, we want to change that. Out extension NYUwall would bright a little deligt for every new tab experience. You will be greeted with beautiful NYU wallpapers. So far we have finished building the basic skeleton of the app.
One problem that we are discussing at the moment is that we both have a lots of feature we want to add for example showing quotes along with the wallpaper and various others. We are having a hard time deciding which features would people like the most without making the extension a bloatware.
]]>Two differences I have noticed between the Go code of conduct page and the Covenant Code of Conduct is that the go code of conduct is much easier to read at the start. By giving a summary (tldr) style view at the start of the conduct it made it much easier to read. This allows people to glance over the code of conduct to get a general sense of the conduct and not drown in reading multiple pages long conduct before even interacting with the project. Another difference is that the Go code of conduct has decided to add a section on conflict resulation “Conflict Resolution” which is missing in the Covenant Code of Conduct. I think the reason for this is that it is crucial to establish how different ideas are handled when it comes to contributing to a programming language which can be very opinionated based on who is maintaining the project. It is curcial that these opinions and disagreement does not lead people away or cause harm but makes the project better. Establishing how to handle conflict without disrecpeting people makes it more welcoming. Here the code of conduct of the Eclipse Foundation which was also adapted from the Contributor Covenant, but also have subtile difference. In the Eclipse Foundation’s code of conduct we can see a new section called “No Retaliation” which details how to protect people who have raised an issue in the likes of harassment, discriminaion etc. The foundation may have added this section to encouge the community to report any misbehavior and protect the reporter against retaliation to create a safe and efficient environment for everyone to collaborate.
The code of conduct document of Sugar Labs project is slightly different from the Covenant Code of Conduct one. The Sugar Labs one is based on the Ubuntu code of conduct which is similar but to me seems more welcome. As it clearly ask people ask questions when in doubt, the ones from earlier can be seen more daunting.
The arch linux code of conduct is another example of a slightly different styled code of conduct. To me this code of conduct seems less beginner friendly compared to other ones as at the start it writes “The Arch community is a technical community” which might scare off beginners who are just starting their linux journey with arch linux. Compared to the ubuntu one this seems more like dedicated for already technical people, where the Covenant Code of Conduct seems like a more general one. Although there are sill similarities on how to handle trolls and people misbehaving/being disrespectful.
Watched this talk today which goes over similar rules as the code of conducts mentioned above. I have personally felt like the talk made it much more welcoming and easy to understand the general code of conducts compared to the readings. I agree to most of the points mentioned in talk, like for example communication being critical where you are not only transparent but not just asking to ask. I have learned a lot about not only how to intereact with other people working on the same project but also how to ask questions and collaborate better.
]]>Open source softwares are often times free because you can make your own changes and compile it yourself. This open architecture has both its pros and cons, some of which are still heavily debated by tech enthusiasts. Open source softwares for intance keep the code base less prone to security vulnerabilities as people around are world are looking at its code and suggesting fixes all the time to make it better. However, since anyone can see the source code and contribute to it sometimes it is possible to get malicious code injected into the source code by a bad actor. Since most of the technology to some extent relies on open source softwares it can cause a supply chain attack, compromising various machines.
I have decided to register for this class because I wanted to learn more about how to both contribute and maintain open source softwares practically. Here are some of my favorite open source softwares :
]]>