Reviewing Work & Opening Issues

To maintain the quality of our site, we’re going to help police each others’ work. We’ll use Github Issues to do this, just like open source projects do. Here’s a reminder of what to check for.

Each assignment post should have: - should have a well-formatted title - should have the author’s name and metadata - should be formatted like a post

Each Assignment Pull Request - Should have a well-formatted pull request title - Should have well-formatted YAML header with the correct author (their github name) and layout: post - Should include whever trinkets or other materials the assignment requested - Should be in a file that’s in their subfolder, titled correctly.

If any of these things are missing, Open an Issue, no more than one issue per assignment. Title it intelligibly, something like “@classmate’s Turtle post title needs spaces”. If there are multiple issues, you can be broader, like “Formatting issues with @classmate’s Turtle post”. In the issue, list the things that are missing. You can make checkboxes if needed like this:

- [ ] A checkbox item

Tag the issue “Student Todo” (if you have commit access yet). If there’s a problem with an open PR, tag it with “Awaiting Changes”.

Assign the issue to your partner. If you don’t have the ability to assign the issue, @mention your partner on the issue.

Handling Issues Assigned to You

If your partner found an issue, no worries! You have all the tools you need to fix it. Using the class notes, how-to sections and/or assignments, fix the issue via a pull request - either the one with the issue if it’s open or with an entirely new one if it’s with an old one. In your pull request title or description, include the phrase “Fixes XX”, where XX is the number of the issue. This will create a link between your PR and the issue AND when the PR gets merged it will automatically close the issue. Neat!

In the beginning, issues won’t count against you. We’re still gettting the hang of things. If you have open issues from me or a classmate, learn why they happened and next time make sure to doublecheck those specific things. A large part of being successful in programming is paying attention to details, which often just means slowing down and/or using internal checkists for yourself.

But as the semester goes on, just like in a professional setting, creating extra work for your peers by doing low quality work will start to negatively impact my assessement of your work. So think of these first issues as FYIs of the things you’re still learning. Soon you’ll be expected to get all of this right every time so that we can focus on the content of your posts.