By the end of this, developers should be able to:

• Ask for assistance using a project issue tracker.
• Describe what the tracker should be used for.
• Define what "good" questions are, and describe why asking better questions is important.

A good question isn't a good question because of its content, but instead, how it is asked. A good question is the question most likely to get an answer. Part of our goal for this program is to help you get better at asking questions so you can grow after starting your first job!

Take 5 minutes to read, and 5 minutes to discuss among your squad, "How to be great at asking coding questions" by Gordon Zhu.

During project periods, you may find yourself stuck or needing help. Never fear! The consulting team will answer questions and help you fix bugs.

To manage requests for assistance, the team uses GitHub's 'Issues' feature - this allows us to address issues asynchronously in an intelligent way.

Use the issue tracker for the appropriate project (for example, game-project) to file your requests. Please note: the issue tracker isn't only for bugs. Use it for any and all requests you have during project work time, even 1on1s.

If you require a 1on1 for personal reasons, please request that through an e-mail or Slack message to every member of instructional staff.

Don't forget to monitor your issues for our responses, and close them with notes when resolved.

Before you add a new issue to the tracker, the team will expect you to go through the following checklist; this will help make the process more efficient by allowing the team to spend most of its time on hard issues, rather than easy ones.

1. Run your linter.

   It may not seem obvious, but being consistent with this will save everyone a lot of time. Whether you use the linter built into Atom, grunt nag, bin/rake nag, or something else.

2. If you have tests, run them.

   Test your JavaScript with grunt test; test your Ruby with bin/rake test (or bundle exec rake test).

3. If you have an error message, read the error!

   Error messages are great, because they tell you what's going wrong. Take note of

   1. what type of error you have,
   2. what file it occurred in, and
   3. the line and character numbers at which the error occurred.

   Reading an error carefully frequently gives you the information you need to correct it and move forward.

4. At least once, try using your debugger to see when the error appears.

   Debugging tools exist for a reason: in JavaScript, set a breakpoint in the Chrome debugger (or drop a debugger; in your code); in ruby, add a binding.pry to your code. Your code will stop executing at that point. See if you can figure out how far the program runs before it hits the error. This can also help you check the values of variables as you go.

5. Read through the documentation.

   Every tool we use has some sort of documentation available. Many documentation sources even implements a search feature, so that you don't have to go digging. Read them carefully! The function signatures in particular are very useful since they explain what inputs a function is supposed to take; passing a function the wrong input value(s) is a very common error.

6. Search Google and Stack Overflow for your issue.

   You're probably not the first person to ever encounter your issue. Try copying the content of your error message (in quotes) into a search bar; you might be surprised what turns up.

7. Ask a peer.

   See if any of the other developers have encountered a similar issue - you are often working on more-or-less the same thing, so someone else may already have the solution to your specific problem. Also, check open issues, you may be able to collaborate on a solution to a shared problem.

8. Read/search closed issues.

   Similar to the previous one, but in case other developers aren't around, you can actually sift through other issues and see if a solution exists by clicking on the tab marked Issues <open issue count> and then selecting ✓ <closed issue count> Closed at the top of the issues list.

Directions for each project can be found in a repository ending in -project, and this is also where issues relating to that project will be handled.

To create a new issue and request assistance,

1. Go to the 'Issues' tab and click 'New Issue'.

2. Create a title for your issue.

   Please try to use the following format:

   "[ language or framework you're using ] - [ short (< 80 chars) description of issue ]"

3. Give a description of the issue you've got.

   Please try to use the following format:

   Linter Output:

   [ output from grunt nag/bin/rake nag ]

   Issue Description:

   [ what you were doing when the problem showed up ]

   [ error message (as text), if one exists ]

   [ the code that caused the error (as a fenced code block) or ]

   [ the code that isn't working as expected ]

   [ things you've tried to fix the problem ]

   [ the last point at which code worked ]

Screenshots are seldom helpful and you should avoid pasting them into an issue.

1. Click 'Submit New Issue'.

If possible, work on something else! If you've been using version control effectively you may have multiple different branches for working on different features. In that case, just switch to a different feature branch and working.

Another possibility, if you want to keep working on the same feature, is to use git stash (to temporarily store uncommitted changes) and git checkout to go back in time to a previous commit -- specifically, the last time everything was working. Once there, you can create a new branch (or branches) off of that commit, so that you can experiment with other ways to solve the problem.

Whatever you do, don't sit around waiting. Project time is limited, so try to use it as effectively as possible.

• Asking Questions
• Asking for Help

1. All content is licensed under a CC­BY­NC­SA 4.0 license.
2. All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact [email protected].