This week we had an in-class meeting and discussed our progress on the Frosty project. Everyone continued working on different tasks and shared updates during the meeting.
I commented on an issue and continued working on the adaptive themed icons for Android. This week I was able to finish the implementation, and I am now preparing to test it before submitting a pull request. This is the first time I worked on a feature like this in an open source project, so I want to make sure everything works correctly before submitting.
Yuxuan submitted a pull request adding documentation, including a contributing.md file. He also commented on an issue related to implementing Twitch’s message pin feature. Paul continued working on fixing the issue where audio is not present on the home screen or lock screen.
As a group, we also reviewed some merged pull requests together. This helped us understand what successful pull requests usually look like, including how they are structured and how contributors explain their changes. This was very helpful because it gave us a clearer idea of what maintainers expect.
One challenge we are still facing is communication with the maintainer. We are trying to reach out, but responses are not always immediate, which makes it harder to confirm whether we are working in the right direction.
For next week, our goals are to write a CODE_OF_CONDUCT.md file and continue working on other issues. I also plan to finish testing my icon changes and submit my pull request.
]]>This week our group met on Google Meet and discussed our progress on the Frosty project. Each member worked on different parts of the project and we shared updates during the meeting.
I mainly spent time going over the codebase and looking through existing issues. I also updated my ideas for contributions and started working on them, including adding adaptive icons, editing documentation, and thinking about how to improve some user-facing error messages. This process helped me better understand how the project is structured.
Paul worked on fixing the double play button issue and already submitted a pull request. During the meeting, he explained his implementation, which helped the rest of us understand the problem more clearly. Yuxuan focused on learning the structure of the codebase, which is also an important step for contributing.
As a group, we also discussed the “play in background” issue and whether it is something we can work on next. We realized that understanding existing implementations is important before trying to add new features.
One challenge we faced is communication with the maintainer. We are still waiting for responses, so it is sometimes difficult to know if our direction is correct. To deal with this, we decided to continue working on smaller tasks while waiting for feedback.
For the next week, our short-term goals include reviewing Paul’s pull request, writing a contributing.md and Code of Conduct.md file, and exploring more issues on GitHub. We also plan to take a closer look at the “play in background” feature.
]]>During the presentations this week, we noticed that many groups are still in the process of setting up their development environments. This seems to be a common challenge for students who are contributing to open source projects for the first time. Some groups mentioned that the setup process can be quite complicated. For example, the group working on Oppia said that they need to use Docker to run the development environment. For beginners, learning how to use tools like Docker can take some time, but it is also an important part of real-world open source development.
Our group is also currently working on setting up the development environment for our project. One interesting situation is that most of my teammates are using Mac computers, while I am the only one using Windows. Because of this, we sometimes need to check whether the setup process works properly on different operating systems. Although this can create some extra challenges, it also helps us understand how development environments may behave differently across platforms.
]]>So far our group has been discussing what open source project we want to contribute to. When choosing the project, we considered several important factors. One important factor is whether the maintainers respond to pull requests and issues in a reasonable amount of time. Since we are new contributors, feedback from maintainers is very important for learning how the contribution process works.
We also wanted to find a project where the issues have different difficulty levels. This allows us to start with smaller beginner-friendly tasks and slowly move to more complex problems.
One obstacle we noticed when evaluating projects is that many repositories have a large number of unresolved pull requests. In some projects, maintainers do not respond very actively, which can make it difficult for new contributors to receive feedback.
Because of this, it was not easy to decide which project would be a good fit for our group.
Fortunately, one of our teammates, Brandon, found a project that seemed much more suitable for beginners. The maintainers of this project appear to respond to issues and pull requests more actively, and the repository has some beginner-friendly issues.
]]>This week our group discussed what kind of open source project we want to contribute to. We are hoping to find a project where maintainers respond to pull requests in a reasonable amount of time. Since we are new contributors, getting feedback from maintainers is important for us to understand how the contribution process works.
We also want to find a project where the issues have different difficulty levels. Some beginner-friendly issues can help us start contributing, and later we might try slightly more difficult tasks.
Another thing we considered is whether someone in the group has used the project before. If at least one person understands how the project works as a user, it will be easier for us to understand the purpose of the project and what problems we can help solve.
One challenge is understanding the codebase of a new project. Many open source projects have existed for a long time, so the structure and code can be difficult for new contributors.
Another challenge is learning the contribution workflow. Every project has different guidelines, so we need to carefully read the documentation and understand how they handle issues and pull requests.
To deal with this, we plan to start with small issues first and gradually learn more about the project.
So far my contributions have mostly been small improvements to documentation and project materials. For example, I helped fix some minor issues in documentation, such as correcting small mistakes and improving clarity.
I also helped fix some small problems reported by others, such as images in reports that were not loading correctly. These types of small fixes may seem minor, but they help make the project documentation clearer and easier for others to use.
One challenge for me is learning how to explore large repositories and understand how different files connect with each other.
The contribution I feel most satisfied with so far is helping fix small documentation issues. Even though these changes are small, they improve the usability of the project and help other contributors understand the project more easily.
]]>This week we watched presentations from different groups and saw the extensions they created. Many of the projects were very creative. One group made a video that showed how the brain forgets information by gradually speeding up the playback, and it was very funny and memorable. Other groups built extensions that were practical and useful in everyday life. It was interesting to see how different teams approached the same assignment with completely different ideas.
Watching these projects made me realize that there are many ways to design a browser extension. Some teams focused on solving small daily problems, while others focused more on creative ideas and storytelling. Seeing these different approaches was inspiring and helped me think more broadly about project design.
Thinking about our own highlight extension project, the biggest takeaway for me was the importance of communication. When we clearly divided tasks and shared updates regularly, the work became much smoother. When I did not understand something, asking my teammates helped me learn faster.
Everyone in the group had different strengths, and combining those strengths helped the project move forward.
The three OSS conference videos we watched were also very interesting. Compared with student presentations, the speakers in the conference talks were more concise and focused more on explaining the purpose of their work. They often explained why their project matters instead of only talking about technical details.
Another thing I noticed was that their slides were usually very simple. They used less text and more clear structure, which made it easier for the audience to follow the presentation.
Watching many presentations this week helped me think more about presentation style. Some presenters spoke very confidently and explained ideas in their own words, which made the presentation more engaging. Others relied more on reading slides, which made the presentation feel less natural.
From these observations, I learned that good presentations require preparation and practice. For my own presentations in the future, I want to focus on speaking more naturally, using simpler slides, and explaining clearly why the project is important, not just how it works.
]]>This week we practiced more Git exercises in class. We explored how Git works inside a repository and learned more about the .git folder. It was interesting to see how Git stores commits, branches, and history.
We also practiced some basic Git commands and workflows. For example, we learned how to create commits, check the status of a repository, and view the commit history. At first Git still feels a little confusing, but practicing these exercises helped me understand the workflow better.
One thing I realized is that Git is very powerful for collaboration. It allows many people to work on the same project without overwriting each other’s work.
For the project evaluation activity, our group looked at GIMP, which is an open source image editing software. It is often compared to Photoshop and is widely used by designers, artists, and photographers.
One thing I noticed is that GIMP has a very large and active community. The project has many contributors and a long development history. It also has documentation, issue tracking, and many discussions about improvements and bugs.
Looking at GIMP helped me understand how large open source projects are organized. It is not just about writing code, but also about managing issues, documentation, and communication between contributors.
After looking at different projects, I think one exciting part of open source development is the opportunity to collaborate with people from around the world. It is interesting that people with different skills and backgrounds can contribute to the same project.
However, I also think the biggest challenge might be understanding a large codebase. Many open source projects have been developed for years, so the code can be complex and difficult for new contributors to understand.
To overcome this challenge, I think it is important to start with small contributions, such as improving documentation or fixing small issues. Over time, this can help new contributors become more familiar with the project.
]]>This week our team started working more seriously on our first open source project. The idea of our project is a Chrome extension that allows users to highlight text on webpages and keep the highlights even after refreshing the page.
During our meetings we talked about how the extension should work and what features we should focus on first. We also created the GitHub repository and organized the files. Everyone shared their ideas and we discussed how to divide the work.
One challenge we had was some technical questions about how to store the highlighted text locally. We are still exploring the best way to do this. We also had some uncertainty about which license we should use for the project.
Another small difficulty is scheduling. Because everyone has different classes, it is sometimes hard to find a time when all team members can meet.
My main contribution so far is helping with documentation. I worked on writing some project documents, including the Code of Conduct, and helped organize information in the repository.
I also joined discussions about the project structure and features. I tried to help make the repository clearer so that other people can understand the project more easily.
One good thing about our group is that we have open discussions and everyone is willing to share ideas. The communication in the group has been positive so far.
One thing I realized during this process is that documentation is actually very important in open source projects. Clear documentation helps other contributors understand the project and know how they can participate.
Overall we are still at the early stage, but I think our team is making good progress.
]]>This week we talked about open source communities and the importance of having a Code of Conduct. I learned that a Code of Conduct helps create a respectful and safe environment for contributors. Because open source projects are open to people from many different countries and backgrounds, it is important to have clear rules about communication and behavior.
A good Code of Conduct usually explains what kind of behavior is acceptable and what is not. For example, contributors should respect others, avoid harassment, and communicate professionally. It also usually explains how to report problems if someone breaks the rules. I think this is very important because without clear guidelines, conflicts can easily happen in large online communities.
We also watched a presentation called How to Drive Consensus and Transparency Within Open Source Communities. One thing that stood out to me is how difficult communication can be in open source projects. Many contributors work remotely and may never meet each other in person, so most communication happens online.
The presentation emphasized the importance of transparency. Project leaders should make decisions openly and explain the reasons behind them. This helps build trust within the community.
Another important idea was consensus. Instead of one person making all the decisions, many open source projects try to discuss ideas and reach agreement as a group. This can take more time, but it helps contributors feel involved and respected.
This presentation also made me think about teamwork in general. Even in small group projects, communication and transparency are very important. If people share ideas openly and respect different opinions, the group can work more smoothly.
I think these lessons are not only useful for open source communities but also for any collaborative project.
]]>When I hear the term open source, I think about software where the source code is public and anyone can see it. People can study the code, change it, and improve it. Many developers from different places can work on the same project together.
One advantage of open source is that it is very transparent. Because the code is public, people can understand how the software works. If there is a bug, someone from the community can help fix it. Open source projects also benefit from collaboration, because many people can contribute ideas and improvements.
However, open source projects can also have problems. Many contributors are volunteers, so sometimes development can be slow. It can also be difficult to manage many people working on the same project.
I decided to take a class about open source software development because I want to understand how large projects are built by communities. I also want to learn how developers collaborate using tools like GitHub.
There are several open source projects that I have used before or that influenced me.
One example is Linux. It is a very popular open source operating system and it is widely used on servers and by developers.
Another example is Mozilla Firefox, which is an open source web browser. It focuses on privacy and open web standards.
I also use VLC Media Player, which is an open source media player that can play many types of video and audio files.
I have also used some browser extensions that help when buying tickets online or refreshing webpages. Some of these extensions are open source and their code can be found on GitHub.
During this first week, I also started setting up my blog and learning how to use GitHub and Jekyll. At first using Git and the terminal was a little confusing, but after practicing basic commands like cloning repositories and pushing changes, I started to understand the workflow better.
I am looking forward to learning more about open source communities and contributing to projects in this class.
]]>