Welcome! Here is a document covering a variety of computer setup and programming related questions that will help our team work best together.
This is a living document, changes, additions are expected and encouraged. If you find a section is lacking make some changes and submit a pull request.
These things need to be completed before you come in on Day 1.
You will need an @byjakt.com Google Apps account. This encorporates your email
and calendaring. Bug Josh if you have not received an
invite to Google Apps.
You will also need to be added to our Company Dropbox account. We have Dropbox for Business that allows you to keep both your personal and our company Dropbox accounts without merging them.
Once you have Dropbox setup it would be a good time to browse around and see how the folders are structured. Yes, in a perfect world perhaps we could remove the concept of nested folders but for now there is a very general layout of how things are structured.
├── Clients Client projects folder
├── Forms Legal and other forms
├── Personnel Personal folders for each employee
│ └── YOUR NAME Your personal folder
├── Assets Various purchased assets including images and fonts.
└── Books Various purchased books, good for reading
We’ll be giving you access to our bug tracking and scm solution. These are handled by FogBugz and Kiln. See the section’s below entitled Working with FogBugz and Development Workflow with Kiln below.
Clear and constant communication is a priority for our team. We have a short (<3 minutes) daily standup at 10:15am every morning. You have ~20 seconds to explain what you’ve completed, what you’re working on, and what (if any) issues are blocking you. Here are three main communication tools we use at JAKT.
You will be given an @byjakt.com. You should be in the habit of checking your
email a few times a day. Email is not a reliable real-time messaging platform
but often people expect replies quickly. If something more urgent comes up, you
are expected to be available on the common real-time messaging platforms below:
Slack is a team communication service that integrates with many different services. The core of Slack is built around an IRC-style layout with various channels that are used. Direct messaging is enabled as well. There are web, desktop, and mobile clients available.
Messages is an Apple-only messaging client that supports the following account types out of the box:
We’re actively investigating new solutions that will help us communicate better. If you stumble across one that looks good let us know!
There isn’t very formalized process for using FogBguz. I’m detailing some basic guidelines for how we use it but one of the best resources for you to go over is the FogBugz help desk, especially the FogBugz in Two Minutes video.
We create one project per client. All cases for a project go within here.
FogBugz has great email integration. That integration is placed in a special project called “Inbox”. Due to limitations on mailboxes all incoming email is funneled into the Inbox project where it is separated out by Areas. There is one area per-project. If you have access to the Inbox project you might be tasked with handling incoming email. In the case that an incoming email results in work that needs to be done create a new case in the appropriate project for that work setting the Parent Case to the case number assigned to the email.
Email handling is traditionally kept off the Kanban column.
Areas within a project are used to separate logical types of work. For starters each project will have an area called “Misc.” As the project grows we will expand the number of areas slowly to accommodate certain grouping of cases. One expansion of this is when we work on a project with other teams. In this case the “Misc.” area will become “JAKT” and a new area per-team will be created.
For starters each project will have a “General” milestone. There is also a global milestone called “Undecided.”
Milestones are used as general per-contract feature sets. This helps build in estimation and predict general due dates. Normally milestones run concurrently. In the case of mobile projects milestones are versioned and used to separate out various releases that are sent during development. Even numbered versions are public or client-facing. Use odd numbered versions for internal use.
The type of case. They are relatively self-explanatory. They are used in conjunction with the resolving status and project to define the workflow that a case should take. For example, Tasks are typically centered around things that don’t need to be double checked. Tasks when resolved are assigned to the person who opened the case. Features on the other hand need testing, this means resolving a feature assigns it to the Test Lieutenant virtual user.
Each category has different statuses you can assign it. The three major statuses are:
If you open a case for someone else to complete it is their responsibility to resolve it and assign it back to you. At that point it’s your responsibility to verify that the case is complete and close it out.
The kanban board is used to track the status of cases as they move through the system. Currently there are six columns:
We were experimenting with kanban colors previously using a color per-project. Now we’re using colors to better indicate case status. Important colors are:
Who is currently responsible for handling the case. Cases can be passed through team leads and onto individual developers or they may be directly assigned. If a case is assigned to you and you believe it is better handled by someone else or more information is required make a note when editing and assign it to the new person. Keep in mind you should be moving it back to the Proposed kanban column when doing so.
Current priority of the case. When in doubt, work on highest (1 high, 7 low) priority cases before lower priority cases.
Milestones are used to track progress towards an finalized release. Typically this is a version number but other milestones are possible. There is a global milestone available to all projects called Undecided. There should also be a milestone called General that is available per-project. If the case does not apply to a current milestone in the project please attach it to the General milestone. If the case does not really apply to the project but you’re not sure where to put it, put it on the Undecided global milestone.
We’re using Kiln because it’s enables our development teams to use git or mercurial as they like. It gives us the ability to branch repositories cleanly, perform code reviews with sign-offs, and it ties into our case management system in FogBugz.
All developers will have their own branch repositories off of the main repository. This repository is your playground; you are free to merge and rebase commit history to your heart’s content.
That said, the main repository is a church. Everything in it is holy and must be treated with the utmost respect. Code is not allowed to enter the pearly gates of the main repository until it has been subjected to a code review. Code reviews aren’t scary, in fact they are one of the fun points of the job. Anyone can perform a code review, however it’s best if Josh is the main reviewer until the development team expands.
To start off a project, create a branch repository from the main one in Kiln. Name it with YOUR NAME. Done, you’re ready to work on a case.
A quick workflow for working on a particular feature or bug:
NUMBER_some_description. Branches are prefixed
with the FogBugz case number, then an underscore, then a short description
replacing spaces and non-ascii characters with underscores.git push -t origin 123_example_branch).Ref case NUMBER is
perfectly acceptable.That’s our 12 13 step workflow for working on a case using
FogBugz and Kiln.