Over the past couple of weeks, our group has become much more comfortable navigating the AFFiNE repository, documentation, and issue tracker. At this point, our group have started looking through the pages of issues and figured out which one to take over.
One of the biggest things we realized this week is that finding a suitable issue is more challenging than we initially expected. We have been regularly browsing the issue tracker and identifying potential bugs or improvements that seem manageable for new contributors. However, we ran into a recurring problem: several of the issues we were interested in ended up being resolved quickly by other contributors before we had the chance to start working on them.
Another challenge is that many of the open issues are feature requests rather than small bugs. Because of this, our first initial response was to ignore it and continue filtering through the list for smaller scoped issues.
Looking back on my previosu contributions, I noticed I’ve not been trying my hand out on harder contributions. Sure, I have OpenStreeMap and Wikipedia, but they’re not code based. For next steps, I do hope to be on track and get my hands dipped in heavier issues for example, ui/ux or maybe even some scrollbar issue for a website.
]]>This week was interesting because, in addition to continuing work on our own project, we also looked through reports from other groups to see what kinds of projects they chose and how their experiences compared to ours. It was helpful to see how other teams approached it early on.
One group we looked at chose to work on Keycloak, an open source identity and access management system. It seems like their process started similarly to ours. In their case, they considered options like ActivityWatch, Pandas, GIMP, and Keycloak before ultimately deciding on Keycloak. Our group also spent some time comparing different projects before selecting AFFiNE.
On a similar note, both our teams managed to set up the development environment early. The projects themselves seem quite different in terms of complexity and focus. Keycloak is centered around authentication and identity management, which likely involves more backend-heavy systems and security considerations. In contrast, AFFiNE is a productivity and knowledge management application that is more focused on document editing, organization, and user interface features.
The Keycloak group mentioned exploring things like theme descriptions, translation support, and compatibility with bcrypt hashing for legacy databases. It’s also crazy to think that their group has already started making contributions. Though it’s ok if our team is starting out slow and steady.
Our group focused on browsing through the AFFiNE issue tracker to find smaller bugs or improvements that might be manageable for first contributions. Some of the issues we identified include things like adjusting the position of UI elements, fixing font-related problems, and improving how images or lists behave in the interface. These seem like good starting points because they are smaller, clearly defined problems that we can investigate without needing to fully understand the entire codebase yet.
Overall, it seems like many groups are going through a similar early phase of open source contribution: choosing a project, setting up the development environment, and trying to understand the codebase well enough to find a first issue to work on. Even though the projects themselves are very different, the general workflow appears to be fairly consistent.
Seeing another group’s progress also reassured me that it is normal for the first couple of weeks to involve a lot of exploration and preparation.
Over the next week we plan to continue using the application, read more of the documentation, and start interacting with the project’s community through discussions or issues. Ideally, we will be able to either open a new issue or begin working on a pull request for one of the existing bugs we identified.
]]>This week our group decided on a project. We decided to communicate through an Instagram group chat and set a regular meeting time on Wednesdays from 8–9 PM. Our first meeting was held in person on March 4.
During this meeting we mainly focused on getting organized and making sure everyone was on the same page about expectations. One of the first things we completed was our group working agreement, which outlines how we plan to communicate, collaborate, and keep each other accountable throughout the semester. Having this agreement early on helped make the project feel more structured and less chaotic.
Before the meeting, everyone looked through a few possible open source projects so that we could come prepared with ideas. During the discussion, we compared different options and thought about things like how active the repository was, whether the documentation looked approachable, and whether we could realistically make contributions within the time we have for the class. We have considered Itch.io and even applications like Godot Engine.
After discussing several possibilities, our group decided to work on AFFiNE, an open source productivity and knowledge management tool. The project seemed interesting because it combines elements of document editing, organization, and collaboration, which makes it somewhat similar to tools like Notion. It also has an active repository and clear documentation, which makes it a good candidate for beginners trying to make their first contributions. Though, we probably would need to use it first to understand how the entire application works.
As a group, our biggest accomplishment this week was setting up the basic structure for collaboration and deciding on our project.
So far we haven’t hit any major blockers yet, but we expect that the biggest challenge will likely be the development environment setup and understanding the structure of the project’s codebase. And good news, we have already setup that environment.
Our short-term plan is to start small. Over the next week we plan to explore the application itself, read through the documentation, and identify smaller beginner-friendly issues that we might be able to contribute to.
]]>For our group project, I hope we can contribute to something that feels meaningful but also that looks like it needs some UIUX fixing. I would prefer working on something still widely used, so that our contributions can realistically be accepted and also for bragging rights. Ideally, it would be something related to web development, game development or education tools, since those are areas I feel more comfortable with.
I think one thing that may stand in our way is the learning curve. Many open source projects have large codebases, unfamiliar structures, and contribution guidelines that can feel overwhelming at first. It can also be overwelming if that project is more math-based than you’d expect. The development environment setup worries me as it seems intimidating.
In terms of what I can contribute, I feel confident front-based, git, and I’m comfortable with structure. I might not be the strongest at complex backend logic, but I can contribute consistently in areas where clarity and design matter.
So far, my small contributions have mainly involved opening issues for the course site, and some wikipedia edits. I also attempted to set up development environments and looked through beginner-friendly issues to see what might be manageable for us. The biggest challenge for me was thinking what do I want to work on next? Well I’m proud of any contribution I made, even if it’s just wikipedia. But what next? Should I jump from wiki all the way to something like Visual Studio Code? That sounds scary.
Overall, this week made me realize that contributing to open source is less about making huge changes and more about taking small, consistent steps. I’m just not sure if I can find any more small steps to take after contributing to wikipedia. What’s is there next that isn’t crazy big.
]]>Over the past two weeks, my partner and I worked on building our browser extension. This experience helped me understand more clearly browser extensions even work. Even though the extension itself had it few bugs and more features needed to implement, it felt useful. Dividing responsibilites and given one that suits your strong suit really helped get this project going.
We’ve seen a few other browser extensions as well. Some extensions focused on productivity, while others focused more on humor. It’s crazy and hard to understand how people come up with these ideas sometimes. I myself always gets into a brain fart.
My biggest takeaway from both my own group and others is that building something usable is more important than making something complicated. Clear design and purpose make a project more meaningful. It’s also ok if the project itself have a long way to go because that’s what open source is for.
A talk by Craig McLuckie discussed the risks involved when developers rely on AI tools. It made me realize that even though AI can help generate code faster, developers still need to understand and review what they are using. When it comes to documentation, even AI might need some reveiwing.
I also watched a conversation between Linus Torvalds and Dirk Hohndel. Linus talked about how he started projects because he personally needed them. He also believe that well if there’s going to be AI, might as well use it and move faster with it.
After watching many student and conference presentations, I learned that presentation style makes a big difference. The best presentations were easy to follow and explained ideas clearly. Speakers who showed demos and spoke confidently made their projects easier to understand.
One important lesson for me is that confidence and preparation are very important. In the future, I want to improve by practicing more and making sure I explain ideas clearly instead of rushing. My mind can go empty when I think about what if I say things wrong. But, maybe if I have a clear structure to follow through, it could be easier.
]]>This week’s Git exercises helped me understand Git a lot better. I already knew Git to a decent level, but I usually don’t use commands like git log to check history. It showed me there’s a lot more I can do with Git, especially for tracking changes and understanding what’s happening in a repository. It made me feel more confident using Git beyond just add, commit, and push.
I looked at a few projects that other students evaluated. Some looked easier to contribute to because they had clear instructions and easier installation setup. Others seemed more complicated and harder to understand at first, like Brave, which is a browser. There’s so much you can contribute to, but the installation process alone can take up to an hour.
It made me realize that good documentation makes a huge difference. Projects that explain things well feel way less intimidating.
I’m excited to contribute to real projects that people actually use. It feels more meaningful than just doing assignments.
The biggest challenge will probably be understanding large codebases and knowing where to start. My plan is to start small, read the documentation, and look for beginner issues, especially in the wiki.
]]>For our meeting, my team had multiple ideas. The current one we have decided on is a drop-down slider for social media tabs. For example, if a user had two tabs open in their browser—one being Brightspace and the other Discord—imagine being on Brightspace and hovering over the upper-right corner of the screen to have a tiny Discord window slide down where you could chat and communicate. The window would preferably be around 200px wide and half the height of the screen on the right side. It’s like a phone display in the top right when you hover above.
This idea came to mind first because, for people like me who hate switching between tabs or applications that take up the full screen, it would be really handy to declutter my desktop.
This might be a very complicated project, so I think our team might have to scope it down. There are only three people on the team, but we haven’t run into any major issues so far. For collaboration, I’m well-versed in GitHub and handle JavaScript fairly well. However, I have never made a Chrome extension and am not sure if this project would allow us to manipulate different tabs and screen formats effectively. My biggest contribution so far has been initiating ideas and making small edits to our repository. During this activity, I also learned that I have quite a few pet peeves. We’ll see how this goes!
]]>When exploring different open source projects, I realized that some are less about strict rules and more about setting expectations for how people should treat each other. It’s interesting looking at how different communities decide what flies and what absolutely does not. Obviously, it’s not always as simple as how monkey see and monkey go.
When taking a look at the code of conduct for The Go project, we mainly see a few several lines of how to respect people and how conflicts should be handled. Having guidelines in place helps prevent small issues from turning into big conflicts especially when considering people contributing to these projects aren’t all from the same town. But yes, if everyone is from the same town, I’d say it’s ok to be rude.
The Go project’s code of conduct is based on the Contributor Covenant. There’s not much change you’ll notice when reading these documents but compared to the original template, Go’s version is easier to read and places more emphasis on open discussion, accessibility, and community values. These changes make the document feel more welcoming instead of overly formal. It feels like Go wanted a document that encourages conversation and learning rather than just listing punishments. Though, I’d much prefer it to list punishments.
Some other code of conducts, like Eclipse takes a more detailed and structured approach. Their code of conduct (Eclipse Community Code of Conduct) is longer and more specific about enforcement and procedures. This could be because Eclipse is a large and long-running project that has likely dealt with more complicated conflicts over time, so they need clearer processes in place. The Sugar Labs code of conduct is based on the Ubuntu Code of Conduct, which gives it a different feel from Go’s. It offers versions in multiple languages, such as Spanish, which shows an effort to be inclusive and accessible. However, it does not clearly list support contacts or reporting methods, which makes it feel more like a set of guiding values than a strict rulebook. It seems as if they’d rather us to fix our issues rather than you reporting to them about your issues.
Let’s take a look at iNaturalist: Basically “Don’t Be Weird” (iNaturalist Community Guidelines). While they are not called a “code of conduct,” they serve the same purpose. This might be the most specific code of conduct ever. Going through the examples, you can really tell they’re trying their best to dummy proof all the different possibilities of things that could go wrong. From minor inconvieniences to going out of their way to explain how to block a user but also at the same time suggest you really shouldn’t be blocking them. Listed on their site, they listed “Don’t write in all CAPS”. AND YOU DON’T HAVE TO HAVE THE LAST WORD. AND OF COURSE IF YOU DON’T LIKE SOMEONE JUST MUTE THEM. IF YOUR EMOTIONS ARE RUNNING HIGH, CALM DOWN. OVERALL, THE GUIDELINES FEEL PRACTICAL WHICH MAKES SENSE SINCE MANY PEOPLE CONTRIBUTE THOUGH INTERACTIONS RATHER THAN JUST THROUGH CODE.
LOOKING AT ALL THESE CODE OF CONDUCTS, YOU’D THINK PEOPLE FINALLY FOUND A WAY TO COLLABORATE WITHOUT THINGS EVER GOING WRONG. WELL NO. TRY FINDING A VIDEO ON THAT, YOU CAN’T. WELL YOU CAN WATCH “How to Drive Consensus and Transparency Within Open Source Communities”, WHICH TELLS YOU THAT THERE’S NO RIGHT RESOLUTION TO WORKING WELL TOGETHER. BUT THERE’S SOMETHING YOU CAN DO TO WORK WELL TOGETHER AND THAT IS TO, JUST BE NICE.
]]>When I hear “open source”, I think of source code that is pubilcly available and contributable. It’s a collaborative space where developers across the world work on the same project together. Open source is exactly like wanting to take apart a toy to see how it works. It’s great for learning especially when considering it’s real world code written by experienced developers from all over the world. It’s also free.
However, some issues with open source may include the lack of security or quality. Because the code is open, someone out there might not be reviewing it carefully. Due to the lack of security, there’s even more reason for students in this field to understand how important version control and documentation is.
Most developers don’t work from scratch up and instead work on existing projects so I think learning how to properly contribute is a valuable skill.
As someone who enjoy UI/UX, I use Bootstrap often to style webpages and look for inspiration. From that, I then work out the layouts in VSCode. In addition, I make use of Discord bots, which is very useful when it comes to managing people in a server. It would be nice if rather than just using these tools, I can contribute to them.
]]>