Difference between revisions of "OSD & DPS909 Winter 2018 Release 0.3"
(→6. Submission) |
(→6. Submission) |
||
| Line 184: | Line 184: | ||
|- | |- | ||
| 22 | | 22 | ||
| − | | | + | | Aliaksandr Ushakou |
| − | | | + | | Brave |
| − | | | + | | https://github.com/brave/browser-laptop/pull/13915 |
| | | | ||
|- | |- | ||
Revision as of 19:16, 23 April 2018
Contents
0.3 Release
In this release, you are asked to continue your work contributing to real open source projects, and show a degree of growth in your approach and effectiveness. This release is due the week of April 23.
1. Picking a Possible Project(s)
You are free to work on the same project as 0.2, or choose a new one. Ideally, the work you did in 0.2 can be leveraged in 0.3, since you shouldn't need to start at square-one. However, if your project choice in 0.2 was not ideal, picking a new one could be a good move.
2. Growth
One of the goals of this course is to help you grow as a developer, in your professional practice, and in your own confidence through gaining real-world experience. As such, you are asked to explicitly define a set of goals for yourself that will define "growth" to you. Some suggestions to consider:
- to work on a larger type of bug (e.g, not a "good first bug")
- to work on more bugs than last time (maybe you did 1 bug last time, and now you'll tackle 2 or 3)
- to add a feature to a project
- to work in a particular technology that interests you, or use some language/framework/tool
- to build your experience with a particular type of programming (e.g., writing tests, automation, etc)
- to gain more experience in different areas of contribution (e.g., docs vs. tests vs. code)
Each student can define their growth differently; but all must have an overarching set of goals in this release.
3. Find some Bugs to Fix
Once you've decided on your project, and decided on your plan for growth, it's time to pick some bugs to work on. Look in the project's Issues and perhaps talk to them on Slack/IRC or wherever they work, and find some possible bugs.
Pick bugs that align with your chosen growth strategy, and will help you achieve your goal(s). Also, try to pick a bug (or bugs) you can accomplish in the time you have available. For example, if a bug is really small, consider fixing more than one. If a bug is really huge (adding a new feature), consider whether it's reasonable to do this during this first release, or if you should wait for the next. You can talk to your professor to get help.
You are encouraged to work on any/all of the following:
- Fixing code bugs
- Writing documentation
- Automating processes (e.g., build system work)
- Localization, translation
- Writing tests
When you've decided on bug(s) to work on, please leave a comment in the bug(s) asking if it's OK for you to do this. Someone else might be working on it, the bug might not exist anymore, or there might be a better bug you can work on. Communicate with the project's community before you spend hours working on the wrong thing.
4. Submit Pull Request(s) and Fix Review Comments
Submit one or more Pull Requests in order to fix your bug(s). Make sure you follow the project's instructions carefully for submitting work--every project does this slightly differently. When in doubt, go look at other closed pull requests to see how they did things.
When you get feedback, make sure you respond, and push more commits to fix any problems pointed out by your reviewer.
6. Submission
Please fill out the table below with all relevant links, including:
- Your name and the name of the open source project you're working on
- Links to all Pull Requests you make to the project on GitHub.
- A final blog post describing everything you did. Make sure to include your chosen growth goals in your post, and how you met them via your contributions. Please include links to bugs, pull requests, and discuss what your bug was about, how you fixed it, what you learned, etc. Feel free to include screenshots, screencasts, video, or anything else you need to properly describe your work.
