Difference between revisions of "OSD & DPS909 Fall 2019 - Release 0.2"
(Created page with "=Release 0.2= ==Due Date== Thursday October 31. See Requirements below for details on what needs to be included in your submission. ==Overview== This second release is me...")
|Line 1:||Line 1:|
Revision as of 10:25, 25 September 2019
Thursday October 31. See Requirements below for details on what needs to be included in your submission.
This second release is meant to get you contributing to real open source projects, furthering your git, GitHub, and open source experience.
For the month of October, we will be participating in Hacktoberfest, a yearly event to encourage new people to get involved in the open source community.
The goal of this second release is to help you gain experience and confidence in contributing to open source projects through direct involvement in a number of real projects. As a result, you will learn more about what it's like to work within the open source development community. Finally, you will participate in a global event.
This release will also help you to continue to develop your blogging skills, and practice software planning, estimating, and scheduling, as you work to complete your pull requests each week.
Start by registering with your GitHub info on the Hacktoberfest web page.
You are then asked to complete 4 pull requests during October, doing 1 pull request per week. You will also be required to blog each week about your progress (see below).
You are expected to progress through your 4 pull requests. That is, each one should build on the previous one in some way. You can't, for example, fix 4 spelling mistakes in a single project. Rather, use each pull request as an opportunity to try something new, and to push yourself a little bit further.
You shouldn't take on huge issues in projects you don't understand, and overwhelm yourself. But you should challenge yourself to work just outside your current skill and comfort zones. The goal is to progress in your experience, competence, and confidence.
NOTE: many people "cheat" at Hacktoberfest by creating repositories that are simply lists of words, movie titles, etc and aren't really open source projects. Please refrain from contributing to these. Make sure you are picking issues from real open source projects. If you're not sure, ask your professor.
Weekly Labs and Blogging
Each week during October, for the course labs, you will be required to complete 1 pull request and 1 blog post. This will help you stay on track, and spread your work out during the month.
Your blog posts can include things like:
- Which issue did your work on? Include links
- What was the issue about?
- What did you need to do to prepare the fix? Was their much setup?
- What did you need to learn in order to make the fix?
- Explain the code for your fix. How does it work?
- If possible, include some kind of demo of the code before/after the fix (not all issues will lend themselves to this, but if you can, consider using screenshots, etc).
- What research did you do? Were there aspects of the issue that you found difficult?
- Did you have any interesting interactions with the project maintainers?
- What did you find difficult? How did you overcome this?
Finding good issues takes time, so be patient and leave yourself plenty of time. Also be aware that there will be thousands of other people contributing to Hacktoberfest, and competing with you for issues.
Here are some links to queries and tools for finding potential issues to work on:
- Issues labelled 'Hacktoberfest' - be aware that there will likely be a lot of competition for these
- Issues labelled 'good first issue' - sorted by least commented. Try different ways of sorting them, for example by newest
- Up For Grabs - currated list of projects with beginner-friendly issues
- good-first-issue - command line tool for finding issues,
npx good-first-issue feeling-lucky
- Finding Open Source Projects on GitHub - an article on different ways to search for projects on GitHub
Fixing Your Issues
When you find an issue that you want to work on, you are encouraged to leave a comment telling the project maintainers. This will help signal to other developers that you are working on it, and (hopefully) not submit a fix. Some people don't follow this rule, and submit fixes anyway.
Submit a pull request for your fix, following all guidelines for the project (see their README and CONTRIBUTING docs). Make sure your pull request is high quality, doesn't touch lines/files that aren't related to your fix, and has proper indenting and code formatting. Pay attention to small things.
You are expected to make any fixes that your reviewers request in subsequent commits. Be professional in your communication and the code you submit.
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.
You will be graded on the following. Please make sure you have addressed everything that makes sense below:
- Four proper Pull Requests completed on time (one per week)
- Clear progression in your work (i.e., you did more than fix 4 spelling mistakes)
- Professional and respectful interactions in your issue with maintainers, good communication in issues and pull requests.
- Pull Requests should reference the Issue Number in its description (e.g., "Fixes #7: Add feature to do ..."), and include sufficient information about changes you made
- All work is done on a new branch (e.g., if you are fixing Issue 123, use issue-123 as your branch name)
- Proper code to fix your Issues
- Code follows style of the original repository author(s)
- All review comments have been addressed, and subsequent commits have been added to correct any problems. Ideally your Pull Request is merged.
- Blog Posts for all Pull Requests
- 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.
When you have completed all the requirements above, please add a section below following the given template, including all necessary links:
@GitHubName - Full Name
- links to all issues you worked on...
- links to all pull requests you submitted...
- links to all your blog posts...