Here are some photos 📸🌅
✨
🐬
🏖️
After reading The Cathedral and the Bazaar, I better understood why open-source projects can grow so fast even without a highly centralized team. The “bazaar” model feels very different from the traditional idea that large software must be carefully built by only a small group of experts. Instead, the reading shows how open collaboration, frequent releases, and contributions from many people can make software stronger over time. I especially liked the idea that a project does not need to be perfect before being shared, because real improvement often comes from many different people looking at the same problem from different perspectives.
And I do not think AI coding tools fundamentally change this idea. AI can definitely help with repetitive work, such as generating boilerplate code, summarizing files, or helping contributors understand unfamiliar syntax faster. These tools can make contribution easier, especially for beginners. However, I still think the “community” is the most important part of the bazaar model. AI cannot replace maintainers’ decisions, user feedback, design discussions, or the shared understanding that comes from many contributors working together. In that sense, AI may speed up the process, but the strength of open source still comes from the people behind the project.
During the past few days, I submitted my first PR for AFFiNE, which was really exciting for me. The issue was a language switching bug in the settings panel. The hardest part was actually finding the exact file related to the bug because the project is pretty large and I was still learning the file structure. Even though my PR was later replaced by a maintainer’s version, it still felt rewarding because it showed that my debugging direction was correct and my work helped point toward the final fix.
For the next few weeks, I hope my teammates and I can keep finding more manageable issues and maybe explore backend or desktop/mobile related changes instead of only web fixes. Reading other groups’ reports also made me realize many of us share similar blockers, especially environment setup and understanding large codebases. Overall, this week made me feel much more confident in reading unfamiliar code and contributing to real open-source projects.
]]>This week, our group started to move into real contribution work instead of only participating in Discord chats and discussion posts in the repository. It felt exciting because this was the first time I was getting closer to actually fixing a real issue in a large project.
The first issue I wanted to work on was a bug related to switching languages in AFFiNE. When users changed the display language, some parts of the UI did not refresh immediately, and the page needed to be manually refreshed before the changes showed correctly. I found this issue very interesting because it is small in appearance, but it directly affects user experience.
My main work this week was reading through the related code files, understanding how the language setting is updated, and trying to locate where the UI refresh was missing. At first, it was a little difficult because the project structure is much larger than the class projects I usually work on, and searching one keyword often showed many related files. However, this process helped me better understand how a real open source project organizes its modules and state updates.
Although I have not fully fixed the bug yet, this week gave me a much clearer direction. I now know which files are related to the language setting flow, and I feel more confident moving from “reading issues” to actually solving them.
]]>Here are some photos 📸🌅
✨
🐬
🏖️
This week, each group presented the final project they selected and their progress. One group mentioned that they were considering contributing to Pandas, a popular open source library used for data analysis in Python. Compared to our project, Pandas is more focused on data processing and backend functionality rather than user interface or application design. In contrast, our group selected AFFiNE, which is a productivity and knowledge management application that focuses more on document editing and user interface features.
There were also other interesting projects, such as Keycloak. Even though different groups are working on different projects and are at different stages, the initial setup process seems quite similar. Most groups first need to install the development environment, read the documentation, and explore the codebase before they can start contributing.
For our group, we have mainly been focusing on setting up the development environment and exploring the AFFiNE issue tracker to find some beginner-friendly issues. Some of the problems we noticed include small user interface adjustments, font issues, and minor layout bugs. These types of issues seem like good starting points because they are relatively small and clearly defined.
Looking at other groups’ reports also helped me realize that it is normal for the first stage of an open source project to involve a lot of exploration and preparation. Many groups are still learning how the project works and trying to identify their first contribution. In the coming weeks, our group plans to continue exploring the AFFiNE codebase, read more documentation, and hopefully start working on our first issue or pull request.
]]>This week I met several times with my teammates, and luckily everything went quite smoothly. First, we sat together and created our group working agreement. We decided our weekly meeting time and shared our previous group experiences, including both good examples and mistakes we want to avoid this time.
After that, we started looking for possible open source projects. Each member suggested several projects that might be interesting. Then we checked their repository pages and documentation to see whether they are beginner-friendly and suitable for new contributors.
In the end, our group decided to work on the project AFFiNE. We thought it was an interesting tool and also a project where we could potentially make small but meaningful contributions.
Next, we tried to install the development environment and run the project locally. Setting up the environment took some time because there are many dependencies to install.
Our professor also mentioned that before becoming contributors, we should first be users of the project. So my plan is to start using AFFiNE to take our group notes or organize some of my tasks. By using the tool in real situations, I hope to understand the product better and identify possible areas where we can contribute.
]]>Last week, I made my first formal PR. It was also my first real step into open source. At first, it was hard to find a repo that felt suitable. Many projects were too complex. Luckily, I met a very nice maintainer who replied kindly and clearly.
I improved the UI by adding a file path under the file name, implementing a fallback “Open File…” button, and creating a test set to help the maintainer check the feature. It was a small change, but it made the interface clearer. The biggest challenge was understanding the code structure before touching anything.
In the future, I hope to work on projects where I can improve UI and user experience. I know I can contribute careful UI changes and small improvements. The contribution I am most proud of is the fallback button — it looks simple, but I really thought about how users would use it.
]]>During the past two weeks, my teammate and I built a fun Chrome extension called MindMelt (you can check our repo and install it!). The whole process was very interesting and helped me understand more clearly how open source projects work in real life. I learned not only how to write code together, but also how to discuss ideas, divide tasks, and solve problems as a team.
This week, different groups presented their extensions. I noticed that every idea, even small ones, can improve user experience. For example, one group designed an extra browser page so users do not need to switch tabs again and again. That idea was simple but very practical. Watching others made me realize that good projects usually start from small daily problems. My biggest takeaway from our group work and others’ presentations is that open source projects are truly user-centered. The goal is not to show how complex your code is, but to make something useful, clear, and easy for people to use.
One idea that impressed me most was: open source is not about building a moat. This means open source is not about blocking others or protecting ownership. Instead, it is about sharing, collaboration, and growing together. This idea changed how I see software. Before, I thought coding was mostly individual work. Now I see it can also be a global teamwork process.
Another thing I learned from the talks is that many important contributors are not always the most visible ones. Some people fix bugs, review code, or improve documents quietly, but they are essential to the project. This made me understand that contribution is not only about writing big features.
After watching many presentations, I realized presentation style matters as much as content. Good speakers usually:
One key lesson for me is that practice is very important. The groups that practiced more looked more natural and confident. In the future, I want to improve my own presentation style by rehearsing more and focusing on clear explanations instead of too many technical details.
Overall, this week helped me learn not only technical skills, but also teamwork, communication, and presentation skills. These are just as important as coding in real projects.
]]>This week we learned Git and version control workflow. Before this class, I always mixed Git and GitHub and did not really understand how Git works. After doing exercises like git add, git commit, and git log, I finally understand the process: modify → stage → commit.
I also tried Git on my own game project. It felt really helpful because I can save versions and go back if something breaks. This made me realize Git is not just theory, it is a real tool developers use every day.
Our group evaluated the React project. It has more than 1,700 contributors and over 21k commits, which shows it is very active. One thing I noticed is that contributor info is not easy to find on the main website. We had to look inside the repository to find guides. The instructions there are clear and helpful, and maintainers respond to issues quickly. The community looks active and friendly. However, many beginner issues still look hard, so it seems contributors need strong coding skills.
Looking at different projects, I think open source communities are very different from each other. Some are beginner friendly, some are more advanced. What excites me most is the chance to work on real projects and learn from real developers. It feels more meaningful than normal assignments. The biggest challenge for me is starting. Large codebases look scary and it is hard to know where to begin. To overcome this, I plan to start small, read docs carefully, and learn step by step.
This week helped me see how real development works. Git and open source felt confusing before, but now they feel more understandable. I think once I take the first step, contributing will become much easier.
]]>This week my teammates and I started our first steps toward an open-source project. We created and installed our very first Chrome extension called “Hello Team.” It was simple, but it helped me understand how browser extensions work and how different files connect to each other.
After that, we explored the Chrome Extensions Samples repository on GitHub. We found and read important files like README.md, LICENSE.md, CONTRIBUTING.md, and CODE_OF_CONDUCT.md. Through this process, I learned that open source is not only about writing code, but also about community and communication. I especially realized how important clear rules and respectful behavior are for collaboration.
Working with my team was both challenging and fun. At first, we had many different ideas for our extension, and it was hard to choose one that was realistic. However, everyone shared ideas openly and listened to each other, which made the discussion very positive.
In the group, my role was to help organize ideas and think about what would be practical to build. My biggest contribution was helping analyze the documents in the repository and explaining why the LICENSE and CONTRIBUTING files are important.
One surprising thing I discovered about myself is that I care more about teamwork and community than I thought. I used to focus mostly on coding, but now I see that collaboration and communication are just as valuable in open source.
]]>The Code of Conduct for the Go community lists many important ideas to prevent potential conflicts in future cooperation. It helps maintain a peaceful and friendly atmosphere in the community, and therefore helps the Go community stay active and full of vitality in the long term. For example, contributors may come from different countries and have different backgrounds. This document provides a baseline standard of behavior to reduce conflicts caused by different social values and communication styles. In my opinion, this kind of Code of Conduct can also benefit other projects, even small ones. Since every open source project involves cooperation, the ideas in the Go document give a good example of how to balance relationships between contributors.
The document on the Contributor Covenant website is a general template compared to the Code of Conduct for the Go community. The two most obvious differences I found are in structure and content style. First, in terms of structure, the Go community document spends a large section explaining its community values, including guidance on how to communicate, rather than only listing rules to avoid bad behavior. Second, the default logic in the Contributor Covenant is that when unacceptable behavior occurs, it should be reported, investigated, and enforced. In this sense, conflict is treated as a serious problem that must be solved. However, the Go Code of Conduct is more delicate in its approach. It states many times that conflicts and differences are part of a healthy community, and it treats conflict as a process that needs to be managed rather than simply a violation.
The code of conduct document for Eclipse and the Go Code of Conduct were both inspired by the Contributor Covenant, but they have different structures and content. The Eclipse document uses more official and institutional language, such as “Conduct Committee,” “Enforcement,” and “Amendments.” One obvious reason for these differences is that Eclipse is a foundation. Many contributors participate as part of companies, so its Code of Conduct needs to be more formal and able to stand firm in disputes.
The code of conduct document for the Sugar Labs project is based on another code of conduct, which is different from Go project. The Sugar Labs Code of Conduct is more practice-oriented and education-oriented. It uses phrases like “Be considerate,” “When you are unsure, ask for help,” and “Step down considerately” to give me really specific personal guidance and a sense of security. Overall, it feels more like a practical guide on how to work together within the community.
One of my favorite open source projects, NumPy, also has its own code of conduct document. What stood out to me is that this Code of Conduct combines advantages from the two discussed above (Go and Sugar Labs). It agrees that conflicts are inevitable, and it is also education-oriented. At the same time, NumPy places more emphasis on professional and clear procedures. Without doubt, the NumPy Code of Conduct is based on another document, as it clearly states: “We drew content and inspiration from the SciPy Code of Conduct.”
The presentation How to Drive Consensus and Transparency Within Open Source Communities helped me better understand why a Code of Conduct is necessary for each open source project — not only to punish bad behavior, but to create shared expectations for respectful collaboration. The speakers said that conflict is inevitable in diverse communities, so a Code of Conduct functions as a common baseline that guides how people communicate and resolve disagreements. I also realized that inclusivity is not only about welcoming people, but about designing communication structures that allow different people to participate. For example, offering multiple channels — such as meetings, mailing lists, and recorded discussions — can make participation easier for non-native English speakers or quieter contributors.
]]>