Eric Raymond’s essay describes the cathedral as a traditional, closed-source development, led by elite groups with infrequent, large public releases. He describes the bazaar as a method of development with decentralized, open source development. The bazaar, he argues, leads to faster development and higher quality of code.
I believe that with AI tools, the bazaar method of development is more important than ever. AI tools allow more people than ever to take a look at open source projects and contribute their changes to it. Being able to release these changes more frequently allows their community to be able to test these rapid releases in smaller increments.
I was able to address broken links leading to the colorMode() reference page.
I want to continue contributing to their website and fixing bugs on their. Web development has always been a passion of mine, and being able to contribute to it on such a large scale has been super rewarding. There are a lot of bugs in their translated pages as they are all handled in a separte way from english - this could be a great contriubtion.
It was interesting how many of the groups mentioned that they were struggling to get their PR’s merged into the code base. For example, the nanobot, pandas, affine, etc. all mentioned their struggles with getting the maintainer to accept their PR. P5.js maintainer Kit is quite responsive, and I am very thankful for that.
]]>03/23 -> 03/25 - New York Times article
This was our first week back from Spring Break, and we came back with lots of new ideas on how to get started!
Grace found a broken link in their reference pages. I thought this was a great way to get started contributing to their platform. I did a deep dive into their reference pages and found that all references to the page /colorMode() were broken.
]]>Although all the different groups were tackling different problems - statistics, identity management, workspace software - many of them were struggling with the same setup issues. I was surprised by this as I thought installing the development environment would be one of the easiest steps in the process. In our group, two of us successfully installed the P5.js dev environment, while the other two encountered test failures during the build process. We were able to sort this out together as a group by comparing what worked for those who were able to install successfully.
The groups that had the most success were those that started looking at the first issues they wanted to tackle. The Pandas group specifically mentioned that they were shocked by how quickly issues were taken, often within the first few minutes of being published. While Pandas is larger than p5.js, the speed at which issues are taken is definitely something to consider. We will need to ensure that we stay up to date on the current issues being published.
It was valuable to listen to the different reports, so that if they had encountered a similar issue, we could just ask them about it. Also, it was fun to compare our progress to the other groups.
]]>Our group started with 2 main tasks. First, we wanted to set clear rules and expectations before starting any project work. We discussed how often we plan to meet, when we plan to meet, and the consequences if we don’t complete our work on time. We also discussed our goals and aspirations for what we wanted to accomplish during this project, so that we were all on the same page. Secondly, our group discussed different project types we might be interested in.
Before meeting on Wednesday, we decided that everyone should come prepared with a few project ideas that we were interested in. Upon meeting on Wednesday, we all went around and talked about each of the projects that we were interested in. As each person presented their project, each of us would look through the evaluation on the Project Evaluation repo to learn more about it.
After each person presented, we narrowed down a few favorites; however, one specifically stood out the most. P5.js is a very beginner-friendly project that has an active, welcoming community. We all loved the lively community and what they are building.
We talked with the professor to ensure that our group could do it, and we wouldn’t be competing with other groups. She spoke highly of the project and said it was run by educators, some of them even at NYU Tisch. We were all quite excited about this and knew that P5.js was definitely a project that all of us wanted.
We have not encountered any major obstacles so far. Our initial planning, setting our expectations and goals, helped make sure that we were all aligned on what we wanted to work on before starting. I am super excited to start contributing to this project!
]]>Wikipedia and OpenStreetMap are where I have made contributions. I found that it is best to stay in the small local areas where you grew up or have lived. These spots you know better than anyone else and can confidently make contributions. For me, this was businesses, roads, and the local airport in the west of Calgary, Canada.
The biggest challenge for me was making sure that I did not commit any mistakes. I was worried that I might submit a spelling mistake or misinformation and have it publicly available on the web forever (yikes).
Another challenge was learning to use the OpenStreetMap interface. I had to use a tutorial initially to better understand how to edit roads, buildings, and business information.
Finding a mistake on OpenStreetMaps in my local community was a lot of fun. The road had a turn off into the middle of nowhere, which is not accurate. I edited it to be a straight road connecting to a driveway. The city did construction a few years ago on this intersection, and it seemed to never be updated correctly (until now!)
]]>The presentation that stood out to me the most was Kelsey Hightower’s talk on open-source development. His method of presenting through a story was incredibly engaging. It was as simple was him telling us about the story of the suit jacket he was wearing, and then ended up tying it back to open source development.
Along similar lines, one of the groups presenting their extension explained the problem they faced before presenting their solution. This personal touch, similar to Kelsey’s story, made it feel much more important.
Most of what makes a good presentation is ensuring your audience is engaged. The best way to do this is by adding a personal touch through your past experiences or a story. Any information that you present will be received better when they are interested in what you are talking about. Adding this personal touch adds a ‘why.’ Spending time in the audience over the last week, the ‘why is this important’ makes everyone much more engaged.
]]>The git exercise was interesting for two main reasons.
First, I learned how to better use the log command and the restore command. I am already familiar with Git, having used it in multiple classes and during my summer work; however, it is interesting to learn about Git best practices. The log command can be used with git log --oneline to print a one-line summary of all commits. Additionally, the restore command could be used restore from a specific commit: git restore --source e5f6g7h foo.txt.
Second, I learned how git objects are stored. I found it interesting that each file is stored as a compressed SHA hash that is entirely unique. Also, each commit stores the entire history, not just the deltas between the most recent commit.
During the project evaluation presentations, I found it incredibly interesting how professional many of these projects seem on the outside, but when you look at their repos, it tells an entirely different story. For example, the Brave browser is a very well-known browser that has missing information on its website about contributions.
I am most excited to have my first line of code be accepted onto an open source project. Being able to say that I contributed to a project I believe in would be so much fun for me.
My biggest challenge will be being able to find a project that I understand enough to be able to contribute to. A lot of code bases are incredibly advanced, and it can be hard to contribute to them without a very strong coding knowledge. I plan to overcome this by picking a project I am very familiar with. This will give me an advantage as I will have an intuitive understanding of how things work and what is wrong.
]]>After four years of studying computer science in college, this is my first semester working on a group project for a class. Both challenges and positives arise when developing code in a group. Below are some thoughts about our progress so far.
The Good Open source software development requires you to communicate openly and clearly with others. I am thoroughly enjoying this new aspect of the computer science world; it is like you are finally able to climb the mountain with other people, compared to being all alone. Each member of the project is very good at talking about where they are skilled and where they can contribute.
The Bad Maintaining an organized Github repository is definitely a problem that we have run into. With each member working independently, it is important that we use a version control system to see who is contributing to each part of the project. We found that dividing up the work into small segments and pushing/pulling into the repo frequently is the best way to be organized.
My Contributions Having taken AIT (a class focused on Javascript and web development) two semesters ago, I am familiar with a lot of the coding required in this project. I was able to help another member of our project out by setting up her directories correctly in class.
What Have I Learned? I learned that I really enjoy this kind of collaborative work. My skills in communication, organization, and punctuality all work well in a group setting. Before this class, I wasn’t sure if I would love or hate the collaborative coding work required. High school group projects generally entail simple lab reports and dedicated group project work time.
]]>Code of Conduct documents, such as the one in the Go Project, allow the open source project to be able to maintain a safe community for development. The documents describe the common-sense rules that encourage a welcoming community, and also outline the actions the project would take if someone does not follow these rules. Without having such a document, there would be no way punish those who are misusing the community.
Go’s code of conduct is based on Contributor Covenant’s code of conduct. However, a few differences exist between these two documents. First, the Go Project has a specific about section outlining how this document benefits the Go project. Second, in the conflict resolution section, there are the direct steps you should take, including Go email addresses. The Contributor Covenant’s document is general and does not have any project-specific information.
Eclipse’s Code of Conduct, another document based on Contributor Covenant’s code of conduct, has many differences from Go’s code of conduct. Eclipse’s document differs in that it includes project-specific information in its code of conduct, provides different contact email addresses, and has its own pledge. While these two documents are based on the same document, their amendments to it can make them different in many ways.
My favorite open source project, Swift, also has its code of conduct based on the same Contributor Covenant document. Since it is based on the same original document, many similarities in the structure are apparent. However, there are unique email addresses for handling problems, and a brief intro to why Swift should be inclusive.
Swift, Go, and Eclipse’s code of conduct attempt to drive consensus and transparency in their respective communities. The Linux Foundation’s video talks about the specific approaches to create this consensus and transparency. First, they talked about “Finding the North Star.” Having an overarching goal is critical for the community to work together toward something, or else it would create a sense of chaos.
Next, The Linux Foundation talked about the following points: communication is critical, inclusivity, and seeking consensus. People will only want to work in a community where their voice is heard, they are being treated with respect, and everyone has an equal opportunity to get involved. Similar to the atmospheres at school or work, creating a welcoming community is essential.
Lastly, handling issues proactively and effectively is another section the Linux Foundation mentions in its presentation. Swift, Go, and Eclipse all have a very specific procedures for handling issues that arise. The Foundation emphasised handling issues with “North Star” in mind. Referring back to what your goals are can help these projects handle these unwanted issues.
]]>