Pull Requests :
Overview
We have created a substantial number of projects in this course, each of which can be enhanced. You will create pull requests for other projects, thus learning how to participate in the open source software community.
Step 1: Identify an Issue
First, review the course projects listed below:
Find an issue that you believe you can fix, or identify an issue not already listed and create it. If you create the issue, it is best to make sure the original developers agree that it is an issue before proceeding, otherwise it is likely that your pull request will not be accepted.
Once your found an issue, write a comment that you are going to claim the issue. You will then have one week from your post to create a pull request to address this issue. After one week, your claim is rescinded and someone else can begin work on this issue.
Step 2: Make a Contribution
Now, fork the repository to create a copy in your own space. As you work, make sure you are
- directly addressing the issue
- working within the style of the project
- including sufficient comments so that the original developers know what you are doing and why
- commiting your changes regularly after each reasonable step of progress
- continuing to pass the unit tests for the project, or
- writing new unit tests for your new functionality.
If another pull request is accepted or new code is committed to the original repository, be sure to sync your fork with this new code before making your pull request.
Step 3: Create a Pull Request
Once you have completed your work, open a pull request between your branch and the main branch in the original repository. Write a comprehensive title, and in the description, specify by number the issue being addressed (e.g. #4). Discuss the reasoning behind your solution, and any software design principles you followed when making your changes.
When the pull request is submitted, it is now the original developers who must review, approve, and merge the request into their repository. If there are issues discovered in the review, or the request does not fit with the vision of the project, the owners must provide detailed targeted feedback so the pull request can be modified.
Step 4: Present Your Success
After your pull request is accepted, you will make a brief presentation in class about your update. Demonstrate the project before and after your update, and any software design principles you followed. Everyone will cheer!
Minor vs. Substantial
You are required to make three (3) substantial pull requests. A substantial pull request is one that either refactors a major component of the code to reduce complexity, or enhances the capabilities of the project with new functionality. A minor pull request fixes typos or small bugs. If you are uncertain of the level of your pull request, please check with Dr. Goadrich for a final ruling.
Grading
A substantial pull request is graded as Complete after the presentation. A minor pull request is graded a Partially Complete.
Three minor pull requests can be combined to become one Complete pull request for the purposes of grading.
At least one of your Complete pull requests must be substantial to earn an A in the course.