release 0.4 - humphd/topics-in-open-source-2024 GitHub Wiki

Release 0.4

Due Date

Dec 11, 2024 by midnight

Overview

In Release 0.1 and the initial Labs, you were asked to become familiar working on an open source project on GitHub. This included working with git, filing issues, creating pull requests, receiving and conducting code reviews, etc.

In Release 0.2, you were asked to take what you'd learned in 0.1, and start to expand your abilities, working on 4 pull requests in various open source projects. These pull requests were due weekly, which didn't give much time to work on larger tasks.

In Release 0.3 you were asked to work on larger issues in an existing open source project, further developing your skills as a developer.

Requirements

For 0.4 you are asked to take your experience and skills in open source development and work on something meaningful to you. I want everyone to have a chance to do a piece of work that they'd be proud of before the term is done. This work can take a number of forms (choose what works best for you and your goals):

Add a feature to an open source project, where a "feature" is defined as writing new code vs. fixing existing code. For example, you could work on a new feature in a repo that you've been contributing to in the previous releases. A "feature" adds functionality to a project, and isn't a CSS bug fix, or an update to the docs, although those things might be part of it. Features often require writing tests, docs, config, CI/CD updates, etc.
Fix a more difficult bug and write or update tests, where a "difficult" bug is defined as a problem that can't be solved in one sitting. If you are able to solve a bug in a few hours, it's probably not what I'm describing (see the next option). A difficult bug takes time (days or perhaps weeks) to untangle and fix. The number of lines of code in the fix can be small, but it will also result in new test cases being added.
Work on a family of related, smaller bugs/fixes, where a "family" is defined as 2, 3, etc smaller bugs that are connected in some way. Perhaps this means writing tests in one PR, adding an implementation in a second PR, and updating docs in a third; or perhaps you work on a few bugs in a particular file or area of the code. In both cases, this type of work is often characterized by becoming quite knowledgeable about a particular area of a project.
Work on a bug in a large open source community/project, where "large" is defined by a project with hundreds of developers working on a significant sized code base spread across one or more repos. This type of work is often characterized by longer review cycles, stricter guidelines on what your contribution must be, and fixes that take a long time to make due to the need to read and understand big code. For example, you could fix something in node.js.
Contribute to a project or community that has some special meaning to you. Maybe you are drawn to a project because of the goals, who is involved, the mission, etc. Use your skills to help others.
Work on something that would help further your career prospects. Pick a company or technology that would be a valuable addition to your resume.

The scope of your work should fill the remaining weeks of the course (i.e., you can't do what I'm asking a few days before the deadline). I will not accept minor PRs at the 0.2 or 0.3 level that are done quickly in the final week. You need to show continued progress and follow-through, and push yourself to do a bit more than you've done in the past.

In summary:

don't pick something so far outside your comfort zone that you set yourself up for failure. Make sure you are capable of accomplishing this with enough time
don't aim so low that you aren't able to progress in your skills and confidence. Remember, you have many weeks to do this.
don't leave this until the last minute. Work consistently, a bit at a time, over the coming weeks. I want to see slow progress every week.

Working Open

An additional challenge for 0.4 will be the requirement that you do the work in the open. This means writing blog posts, being active in the project's community channels, taking part in discussions on GitHub, etc.

As you work over the coming weeks I will expect you to write 3 blog posts (roughly 1 per week):

A post in week 1 describing what you will do in 0.4, why you are choosing this work and project, and how you will approach it. This is a chance to plan your 0.4 and set goals. Part of your assessment will be how well you are able to achieve these personal goals. You are in charge, so set yourself up for success.
A post in week 2 giving an update on your progress to date. What have you done so far? What are you stuck on? What have you managed to figure out? How will you adjust to meet your goals by the end? Talk about your research and initial learning.
A final post discussing your results. How well did you do achieving your goals? How did you build? Discuss the technical features of the work, and the methods by which you accomplished it. What did you learn from this process? How were you able to leverage and interact with the community to get your problems solved?

These posts should tell a technical story over the course of three episodes. Try to add knowledge to the web and be technical in what you write. If other people did a Google search looking for info about what you did, would your posts help them?

Further Requirements

Make sure you follow-through on any review comments. The goal of 0.4 is not simply to make a Pull Request, which you already know how to do. Rather, it is to contribute something useful and meaningful to a project, and to do it at a high level of quality. Your Pull Request(s) should be merged by the end, if at all possible. If they are not, you need to explain why, and if the reason is that you didn't do the work on time, you will face deductions. You must also use git and GitHub properly and professionally (e.g., branches should be clean, rebases done correctly, etc).