Skip to content

Home

Jump to bottom
jedpittman edited this page Sep 17, 2020 · 13 revisions

Welcome to the jobhopper wiki!

FAQ for Work a.k.a How to handle your issues:

We track our issues on the current sprint's project board. The Current Sprint Board has columns to show progress. As you work on the issue, move the issue into the correct column. (If you don't have permissions, update the issue in comments and/or update the title of the issue and once we see the change, we'll fix it.)

  • ToDo - Items in the sprint that are scheduled to be done.
  • InProgress - Items in the sprint that are being worked on actively.
  • InTesting - Items that are code changes that require testing by the developer prior to being ready. Coding is done, testing is in progress.
  • InReview - Code and Testing are done, but someone (second set of eyes) should review for quality, especially merge requests.
  • Done - Any issue that is worked on and finished OR closed because needs change.

In general, you should try to only have one issue at a time and take issues that have downstream items that depend on them only if you can turn them around fairly fast. Any issue that gets no activity may be reassigned.

Once you're done with an issue, you should feel free to grab an issue from the top (or near top) of the todo list that you think you can do with minimal help.

If you think an issue is not clear, please leave a comment and do a mention to Jed or the creator and we'll try to make it clear.

If you're stuck on an issue, reach out to other teammates if you think they can help using slack or comments. If you cannot get help for a period of time (1-2 days), then feel free to make a comment that the issue is blocked (with the reason). Then you can take another item from the list. If any decisions/information is developed, add/update documentation so the entire team has it available.

Filing New Issues

We're generally trying to make sure that all items are done at the end of the sprint, and most that have been taken are done at the end of Tuesday night each week. To that end, keep issues small (1-2 hours of work). If needed, add an item to the ticket that says "enter issue(s) to continue x". That is perfectly fine. If you think the ticket warrants a large issue, that is fine, but mark that as (BIG) in the title. As we groom each week, we'll get better at this.

If you think an issue is too big/hard/you cannot complete it, just write a comment in the issue and put it back in the todo list at the top. This should be rare. Only take an issue if you feel pretty confident you can do it yourself.

Normal Flow for adding Code

You should be familiar with Git Commands prior to doing this work.

Ensure you have a fork of the repo

Make local changes to work on the issue

  • Use git to clone a copy of the forked repo.
  • Make a new local branch to fix the issue. Recommended naming is ISS-# where # is the issue id for the code you're changing.
  • Make your changes on your local copy.
  • Test as much as possible locally.
  • Commit and push your code up to your forked copy (in github, this is the version of the code with your name e.g. https://github.com/yourusername/jobhopper)
  • File a pull request (PR) from your copy to the latest target release branch. (currently V1.0.0)
  • Make a note in your ticket that the issue is ready for review.
  • A member of the team will review your code, make comments etc as needed/approve the code if it looks good.
  • Once there's code that is approved, a team member will merge it into the Versioned branch.

Build Flow

Ideally once per sprint, a member of the team will "build" a full release of the code for the version in question,

  1. Get the latest code for the version in question
  2. Run all tests (automated and manual) and ensure they all pass, if not, work with team to fix issues
  3. Merge the code into master once final
  4. Create a new version numbered branch off of master

Resources for Onboarding to be added here.

Clone this wiki locally