release 0.4

Release 0.4

Due Date

Friday December 10 at 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, filling 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, and also to contribute to our internal projects. The former let you further develop your skills as a developer, the latter exposed you to working on a rapidly changing project with many concurrent contributors.

Requirements

For 0.4 you are asked to work on something larger and more impactful than anything you have done in the previous three releases. This work can take a number of forms:

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 Telescope or another 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.
Fix a more difficult bug and write/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, 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, or more small 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 corner of a project.
Work on a bug in a large open source community and 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.

The scope of your work should fill the coming three weeks (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 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
don't aim so low that you aren't able to progress in your skills and confidence
don't leave this until the last minute. Work consistently, a bit at a time, over the next 3 weeks

You may work on an internal project(s), external project(s), or both. Pick something you'll enjoy working on and which you'll be proud to show in an interview.

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 coming three weeks I will expect you to write 3 blog posts (likely 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.
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?
A final post 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 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 this is, and if the reason is that you didn't do the work on time, you will face deductions. You must also use git properly and professionally (e.g., branches should be clean, rebases done correctly, etc).