Release 0.2

Due Date

Wednesday March 6th. See Requirements below for details on what needs to be included in your submission.

Overview

This second release is designed to build on the work you began in 0.1, namely, to have you gain experience contributing to multiple open source projects outside the context of the course. In 0.1 you worked with git and GitHub, and practiced the workflow common to contributing to open source (Issues, Pull Requests, reviews). In 0.2, you will have a chance to practice these skills by working with a number of new open source projects.

Your goal in 0.2 is to submit 4 pull requests to two or more open source projects. You can pick 4 issues in 4 separate repositories, or fix more than 1 issue in a repo. You must contribute to at least 2 repos (i.e., you can't fix 4 bugs in one project). Every project does things slightly different, and this is a chance to get exposure to multiple approaches.

Finding Bugs

Because you need to fix 4 bugs in 0.2, you'll need to focus on smaller issues. This release is about quantity vs. working on big bugs. It's probably not a good idea to take on a bug where you need to add a new feature to a project. Save things like that for 0.3 and 0.4.

In lab 3 you researched 3 open source projects. Begin with this list, and see if there are things you can fix in these projects. Here are some suggestions of issues to consider:

Issues with a label of "good first issue," "easy," "beginner," etc are a good signal
Use one of these query tools:
- all open "good first issue" on GitHub. You can further limit the search by language: Python, JavaScript, Java, C++
- Up For Grabs
- GitHub Help Wanted
- good-first-issue Good First Issue node cli tool

Finally, talk to other students in the class (Slack, in class, and read their blog posts). See if you can work on the same projects they liked.

Also consider looking for small ways to contribute:

fixing a small bug
documentation fixes, updates or fixing typos
localization (e.g., translating strings into a second language you know)
adding a test for some new code

Your pull request can be small (e.g., changes only 1 line of code). Our goal is to do multiple pull requests vs. one big one.

Blogging/Labs

For entire month of February, your labs (4, 5, 6) will involve writing status report blog posts. These update blog posts are meant to help you stay on track with the overall goal of fixing 4 issues this month.

Each Friday you need to post an update on your progress finding and fixing bugs. In each post, focus on the following:

What did you work on this week? Which project(s)? Which issue(s)? Include links.
What are the issues about? Why did you choose them?
Which technologies, languages, tools, etc. are you using to do this work?
How far have you gotten? Even if you haven't completed the work, discuss your progress
Did you have any involvement with the open source community this week (e.g., discussions in issues/PRs, slack or some other real time chat)?
Did you learn anything interesting this week that other students should know about?
What are your plans for next week? Have you picked new Issues(s)?

Submission

Keep track of your work in the section below, adding information for yourself based on the provided template. Please include:

your name
URLs to all of your Pull Requests
URLs to all of your weekly status update blog posts
URL to your final summary blog post

Your final summary blog post should include the following:

Links to everything you worked on this month (URLs to PRs)
Discussion of how things went. What went well? What would you do differently next time?
What did you learn through this process? About git/GitHub? About open source? About yourself?