Changes

If you're not sure what to pick, consider using BSD, MIT, or Apache.

You can use any existing open source code that will help you write your library. For example, if you can find a module that already implements the MD5 digest algorithm, use it. Don't write any code you don't have to, don't reinvent the wheel.

Make sure that any open source code you choose is compatible with the license you've chosen. You may need to adjust your license or language choice depending on what you find.

Follow the [https://help.github.com/articles/create-a-repo/ instructions on GitHub to create a repo] for your library. Make sure you choose a name that hasn't already been used by another project, company, or product. Try doing a Google search before you settle on your name.

[https://help.github.com/articles/fork-a-repo/#step-2-create-a-local-clone-of-your-fork Clone your repo] on your local computer.

Begin by planning your work as a series of Issues in GitHub. Each issue should be small enough to capture a single feature, improvement, or task. For example, you might file issues for each of the main functions of your library. You might also choose to break those down into a smaller issues. Do what feels right for you. Fixing many small bugs is often easier than a few large ones.

Now that you have issues filed, pick one and start coding it. Remember to do each fix on a separate branch. Once you get a feature finished, and you're happy with it, you can <code>merge</code> it into your <code>master</code> branch. Here's an example of what this might look like:

</pre>

When you've got a few of your bugs fixed and merged into <code>master</code>, it's time to publish your work on GitHub. To do this, you want to <code>push</code> your <code>master</code> branch:

Now visit your GitHub repo and make sure you can see your commits, and the code you've written. If anything looks wrong, do another commit to fix it, and push again.

When you're ready to have people contribute to your project, add your '''name''' and GitHub Repo '''URL''' to the table below. File any additional '''Issues''' in your project repo on GitHub for things you'd like help doing (see suggestions in step 7 below). You can also use the Slack channel to tell people about your project, and how they can get involved.

In addition to creating and maintaining your own library, you are asked to contribute to at least one other project in the class. You can work on a different language than you wrote your own project using, and are free to work with anyone in the class (e.g., don't limit yourself to people you know).

Finally, create a [https://help.github.com/articles/about-pull-requests/ Pull Request] for your change. In your Pull Request's description, make sure you use the pattern <code>Fix #...: ...</code> to have GitHub automatically close the associated issue when your Pull Request is merged. For example, if you are working on Issue 14, you might say, <code>Fix #14: add md5 unit test</code>. Also include a useful discussion of what you've done, how to test it, etc.

Every Pull Request will need to be reviewed by the project maintainer. When someone submit a Pull Request to your repo, you'll get an email. You should go and read their code, and make any suggestions for how you want it to be fixed (if necessary). Remember that as a maintainer, it's your job to help new contributors feel welcome and valued in your project--you want them to stick around and fix more bugs.

</pre>

Once you've submitted one or more Pull Requests, make sure you add links in the table below beside your name.

Write a blog post about your experiences in this lab. In particular, discuss each of the following: