Week 10 Reflection This week, I worked with my teammates on the Nanobot project. While using the system, I found an issue (Issue #2487). The problem was that the agent sometimes showed messages like it was working or had finished something, even when no real action happened. This could confuse users.

I tried to understand the cause of the problem and then created a fix. I submitted my solution as a pull request (#2525). In my fix, I made sure that progress messages only show real actions, instead of showing unclear or misleading text. This helps users better understand what the system is actually doing.

I also submitted a small OpenStreetMap edit (changeset #180477745) to correct camera details on a node near California Street and 18th Street in Denver, so the map data better matches what is on the ground.

At the same time, my teammates were also working on different issues. Some issues were found by themselves, and some were reported by other users. Everyone focused on solving their own part, but together we improved the project step by step.

This experience felt very different from normal assignments. Instead of just finishing a task, we were working on a real project that other people use. I had to read existing code, understand how the system works, and make sure my changes did not break anything else. Writing a clear pull request was also important so others could understand my work.

Overall, this week was a very valuable experience. I learned how to find and fix real problems, improve user experience, and work with a team in an open-source project. It also showed me how important clear communication and teamwork are in software development.

Week 8 Reflection After reading the reports from other groups, I noticed that many teams faced similar early-stage challenges as our group. For example, the Oppia group spent most of their time discussing which project to contribute to and evaluating the pros and cons of different options. Their meeting notes show that they focused heavily on project selection and communication before starting technical work.

In comparison, the Nanobot group quickly decided on a project and created a fork of the repository. Our early work focused on organizing the team and planning possible pull requests. However, we had not yet encountered many technical problems at the beginning.

One interesting difference is that some groups already discussed Docker and shared development environments, while others focused more on identifying issues. Overall, it seems that most groups are still in the preparation stage: learning the codebase, setting up tools, and planning contributions.

Week 7 Reflection This week our group met on Discord to decide which open-source project we want to work on for the rest of the semester. After looking at several options, we decided to choose Nanobot. We picked Nanobot because it is an AI-related project and the repository looks active. The documentation is also clear enough for us to start exploring the code. We believe this project will help us understand how real open-source projects are structured and maintained.

However, we also noticed some challenges. The codebase is fairly large, so it may take time for everyone to understand how the system works. Some group members are also not familiar with all the tools used in the project yet. Because of this, setting up the development environment might take some effort at the beginning.

For the next step, everyone in the group will try to clone the Nanobot repository and run the project locally. If we encounter problems during the setup process, we will share them with the group so we can solve them together. After that, we will start reading the code and looking for beginner-friendly issues in the repository. Our goal is to understand the project better and prepare for our first contribution.

Week 6 Reflection I hope to contribute to a practical and user-focused open source project with my group. Since my background is in computer science and game development, I am especially interested in projects related to interactive applications.

However, there are some things that may stand in our way. One challenge is understanding a large existing codebase, which can take time at the beginning. Another possible obstacle is coordinating schedules and communication within the team, since everyone is busy with other coursework. In addition, learning the project’s contribution workflow and coding style may require some adjustment.

I know I can contribute to the group in several ways. I am comfortable reading code, debugging, and implementing small features. I can also help improve documentation and organize tasks because I have experience managing my own game projects.

So far, my small contributions are going steadily. I have helped review the repository structure, made minor code improvements, and assisted with documentation updates. The biggest challenge has been getting fully familiar with the project architecture and making sure my changes match the existing style.

Week 5 Reflection This week, although I was unable to attend the live presentations, I reviewed several student projects. One extension that particularly caught my attention was Mind Melt. I found the idea very creative and memorable. Instead of improving productivity, the extension intentionally disrupts the YouTube viewing experience by fading the screen, altering audio, and so on. This showed me that browser extensions can also be used to create experimental or artistic experiences, not just practical tools. It was interesting to see how a simple technical implementation can produce such a strong and unique user feeling.

My biggest takeaway from our group work was the critical importance of clear communication and early alignment on technical decisions. At the beginning, small misunderstandings about goals and implementation choices created unnecessary confusion. As we improved our check-ins and clarified responsibilities, our workflow became much smoother and more efficient.

In place of Wednesday’s class, I watched the three assigned videos. A major theme across them was that successful open-source collaboration depends heavily on communication. Clear documentation, small incremental contributions, and respectful community interaction were repeatedly emphasized. I realized that writing good code alone is not enough; making the project approachable for contributors is equally important.

Watching the three videos helped me better understand what makes a presentation effective. One of my biggest takeaways is the importance of clarity and focus. The speakers organized their talks around a few strong core ideas instead of trying to cover too many details. This made their presentations easier to follow and more memorable.

Another thing I learned is the value of a natural and conversational delivery style. The presenters used real-world examples and spoke in a way that felt engaging rather than scripted. They also used pauses and emphasis effectively to highlight important points.

Week 4 progress In class, the Git exercises helped me better understand how version control works in real projects. Practicing commands like clone, add, commit, and push made the workflow much clearer. I also learned why it is important to pull before starting new work and how branches help teams work safely without breaking the main code. The professor’s discussion about merge conflicts was especially impressive to me. When two people edit the same location, conflicts happen. It is fair that Git requires manual resolution, but the process can be troublesome and time-consuming.

After evaluating several open source projects, I noticed that different projects vary greatly in size, documentation quality, and community activity. Large projects like Brave are very active and well-structured but can be intimidating for new contributors, while smaller projects are easier to understand but may have less community support.

I am excited about the opportunity to contribute to real-world software used by many people. Working on an open source project allows me to collaborate with experienced developers and improve my skills.

The biggest challenge will likely be understanding large codebases and navigating complex contribution processes. To overcome this, I plan to start with small contributions such as documentation fixes and gradually work toward more complex issues. I will also carefully read the contribution guidelines and learn from community discussions.

Overall, I believe contributing to open source will be a valuable learning experience！ Team Project For the project, we selected the theme I chose — Tab Color Changer, an extension that can change the color of the whole browser tab area. I first implemented a Chrome version but discovered that Chrome does not provide an API for changing tab colors directly, so I created a workaround using tab grouping and labeled the first tab with the selected color. However, the team thought we should keep the original idea instead of using grouping, so they pivoted back to the original concept and implemented it in Firefox. Based on their work, I implemented the reset color button. I also wrote the CONTRIBUTING file and the README.

Week 3 progress This week our team worked on planning our first open source project and discussing possible ideas for a Chrome extension. We came up with several options, including a Google Docs dark mode tool, a homework or assignment reminder connected to school websites, and a tab color changer. After considering difficulty and time limits, we decided the Tab Color Changer is the most realistic choice for our first project.

One challenge we faced was choosing between creative ideas and what we could actually complete. Some ideas sounded exciting but required more technical knowledge and permissions. A positive part of our teamwork was that everyone shared ideas and listened to each other.

My role was helping evaluate which idea was practical and helping describe the project clearly. Lastly, we decided to choose tab color changer. My biggest contribution was providing the creative idea of tab color changer. I also help to evaluate other ideas in term of coding and designing.

Video Reflection The Code of Conduct activity raised important questions about why rules are needed in open source projects. Even though open source emphasizes openness and freedom, a Code of Conduct helps set clear expectations for respectful behavior. It protects contributors from harassment, encourages inclusive participation, and provides guidance on how conflicts should be handled. Without it, power imbalances and misunderstandings can easily discourage people from contributing.

The presentation emphasized that consensus does not mean everyone fully agrees, but that everyone has been heard and understands the decision. Transparency plays a key role in this process. By making discussions, decisions, and documentation open, communities build trust and reduce confusion. Tools such as public issue trackers, RFCs, and open communication channels help contributors follow the reasoning behind decisions.

Overall, the presentation helped me understand that strong open source communities rely not only on good code, but also on clear processes, transparent decision-making, and shared behavioral standards. A Code of Conduct supports these values by creating a safe environment where collaboration and consensus can thrive.

Reflection of Code of Conduct Activity

The Go project’s Code of Conduct is useful because it clearly tells people how to behave in the community. Open source projects include people from different cultures and backgrounds, so conflicts can easily happen. Having rules written down helps prevent harassment and makes new contributors feel safer. It also shows that the project cares about respect and inclusion, not just coding skills. Compared to the Contributor Covenant, Go’s version feels more specific to its own community and communication spaces. It is also less formal in tone. They probably changed it to better match their own culture and make the rules feel more practical.

The Sugar Labs Code of Conduct feels more general and value-focused compared to Go’s. It talks a lot about respect, collaboration, and creating a welcoming space, but it doesn’t go into as many detailed behavior examples. Since Sugar Labs works in education, this makes sense because their community includes students and teachers, not just developers. The language is simple and approachable. It seems like the document may be based on an existing template because the wording sounds similar to other community guidelines. Unlike Go’s more customized version, this one feels broader and designed to fit a mixed learning environment.

https://policies.python.org/python.org/code-of-conduct/ I looked at the Python project as another example. Their Code of Conduct is more structured and formal than Go’s and much more detailed than Sugar Labs’. It includes clear examples of unacceptable behavior and explains how to report problems. This probably reflects the size of the Python community, which is very large and global. Compared to the simpler style of Sugar Labs, Python’s version feels more like an official governance document. This shows that bigger projects often need more detailed processes, while smaller or education-focused communities can rely on simpler guidelines.

What I Think About Open Source

When I hear the term open source, I think about software or projects that are open for everyone to use. It means the source code or content is public, and people can collaborate together.

Advantages of Open Source

One advantage of open source is collaboration. Many people from different places can contribute ideas and fix problems together. Open source is also usually free, which is very helpful for students. It allows beginners to learn by reading real projects.

Problems with Open Source

Open source also has some problems. Sometimes projects do not have clear management, so decisions can be slow. Some projects also lack good documentation, which makes it hard for new contributors to start.

Why I Took This Class

I decided to take a class about open source software development because I want to learn how teamwork works in real projects. I think open source experience is important for my future career.

Open Source Project I Use Visual Studio Code

Github

Eclipse

Blender These tools show are open-source and also fit my workflow!