Difference between revisions of "OSD & DPS909 Fall 2019 - Release 0.1"
(→Submission) |
(→Submission) |
||
| Line 178: | Line 178: | ||
|- | |- | ||
|Ryan Marzec | |Ryan Marzec | ||
| − | | | + | |https://marss64.wordpress.com/2019/09/22/open-source-my-release-0-1/ |
|1: https://github.com/cindyledev/my-note/issues/2 <br/> 2: https://github.com/ragnarokatz/my-note/issues/1 | |1: https://github.com/cindyledev/my-note/issues/2 <br/> 2: https://github.com/ragnarokatz/my-note/issues/1 | ||
|1: https://github.com/cindyledev/my-note/pull/3 <br/> 2: https://github.com/ragnarokatz/my-note/pull/2 | |1: https://github.com/cindyledev/my-note/pull/3 <br/> 2: https://github.com/ragnarokatz/my-note/pull/2 | ||
Revision as of 12:23, 22 September 2019
Contents
Release 0.1
Due Date
Monday September 23rd. See Requirements below for details on what needs to be included in your submission.
Overview
This first release is designed to expose you to the common workflows and tools involved in contributing to open source projects on GitHub. In order to give every student a similar learning experience, we will all be working on the same project and code. NOTE: in subsequent releases, students will have more freedom to contribute to other projects.
Our goal will be to help improve and extend the Web Notepad from Lab 2. We will do so with a focus on git and GitHub usage and contribution processes vs. complexity of code changes.
Learning Goals
In addition to the actual code you will write, the ultimate goal of this first release is to help you gain experience in many aspects of open source development and contribution, specifically:
- reading and searching through existing code
- working with branches, commits and other aspects of git
- creating Pull Requests in GitHub
- filing, triaging, and working with Issues on GitHub
- working as part of an open source community
- reviewing other contributor's Pull Requests
- using open communication tools, such as Slack
- writing about your own work via your Blog
You will also have the chance to work on multiple issues across different repositories, and learn more about what it's like to work with code you didn't write, and with other collaborators on the same project.
Watching Your Lab 2 Repository
Before you do anything else, begin by Watching your repository from Lab 2. By default, GitHub will not set a watch on repositories you create, and you won't see email notifications when people file issues or send pull requests.
Watching your repository is important so that when other people start filing bugs below, you get notifications and can respond.
Filing Issues
You are asked to file 2 separate Issues, each in a different repository from the Lab 2 Submissions list. See this article on GitHub for more details on how to file an issue.
The first issue should be to fix or improve something in the repository's existing code. Try running the code, and see if you can find any bugs. Read the code and see if there are any problems you notice with the way it's been written. You're looking for a way to help make the app and/or code better than it currently is. This does not include making coding style changes. Respect the existing coding style of the author vs. your own preferences.
The second issue should be to add a new feature to a second repository. You can use the list of suggested features from Lab 2 or suggest your own. You'll need to convince the repository's owner that your idea is worth doing, and give enough detail about your change for them to think it necessary.
In both cases, before you file any new issues in a repository, take a look at the other issues that are already filed, and any pull requests that have been made. Don't duplicate someone else's work, or get in the way of another contributor.
Fixing Your Issues
Once your issue is filed, begin your fix by forking the appropriate repository and creating a new branch. You must create a new branch before you commit any code or submit a pull request. If the issue you filed was #5, create a branch named issue-5.
On your new branch, you can make as many commits as you need to. Don't worry if you make mistakes, or need to overwrite/undo something; just add more commits to fix the problems. Do not merge any code into your branch. Leave that for the very end, when your fully reviewed and corrected pull request will (hopefully) get merged by the repository maintainer.
Getting Help
At every stage of your work, make sure you ask for help, and get feedback from others in the community by asking questions. Don't struggle on your own and get stuck, or miss the due date.
Please use Open Source Slack to help with communication. If you can't get a maintainer for a repository to respond to your Issues, or give feedback on reviews, you should try and reach out on Slack. If that doesn't work, consider switching to contribute to another repository.
Requirements
You will be graded on the following. Please make sure you have addressed everything that makes sense below:
- One Issue filed for a bug fix
- One Issue filed for a new feature (on a separate repository from the bug fix)
- Professional and respectful interactions in your issue with the maintainer.
- Proper Pull Requests are completed for both Issues you filed
- An Issue should be filed before your create your Pull Request. The Issue must have a complete subject and description of the problem or change you believe needs to be made.
- The Pull Request should reference the Issue Number in its description (e.g., "Fixes #7: Add feature to do ...")
- Changes must be made on a new branch (e.g., if you are fixing Issue 123, use issue-123 as your branch name)
- Proper code to fix your Issue
- Code follows style of the original repository author
- Co-ordination with other student/community Pull Requests. Make sure you don't duplicate another fix or change that someone else has already done.
- All review comments have been addressed, and subsequent commits have been added to correct any problems. Ideally your Pull Request is merged.
- Reviews of Other Student's Pull Requests
- Compare the Pull Request to the related Issue it is trying to fix. Has everything been covered?
- Confirm that there are no other related Issues or Pull Requests that might conflict with this Pull Request
- Review code and other changes, making comments and suggestions about any improvements you can see, or other issues that need to be addressed
- Blog Post
- Discussion of the changes you made. What was your process? What did you learn? What would you do differently next time, or what worked and you would do again?
- Link to the Issues you filed, and discuss the bug/problem/addition you wanted to address.
- Link to the Pull Requests you created, and discuss the fix.
- Link to the Pull Requests you reviewed, and discuss what you did and found.
- Discussion of what you did to address your review comments.
- Evidence of Community Involvement. Could be Issues you worked in to help others, help you gave people on Slack, mentoring or other help you gave people in person. How did you engage with the community of developers working on Filer?
- Add Info to Table Below
Submission
When you have completed all the requirements above, please add your details to the table below.
