Feature Buddy Development Process

gistfile1.txt

* Development process

** Feature Tracking

The first step of development should be to have a task card. Typically
the team leads will create the cards, but this won't always be true---sometimes
you'll find a bug or take a bug from a Flowdock conversation. At that point you
can ask your team lead to handle the card, or you can do it yourself. If you
create a card that you're intending on working on immediately, make sure to put
it in the current iteration. 
If you do create the card yourself, let the appropriate team lead know so they
can assign it to a feature as needed for tracking.

When creating a card, or occasionally at your team lead's request, you should
estimate the time that a card will take in points. Points are a deliberately
non-specific unit whose association with actual time is meant to adapt to the
team that's using it as it evolves. While we are trying to align the whole team
on estimation, we are using the following rough point-to-time mapping:
 - 1pt = minimal work
 - 2pt = half day's work
 - 4pt = full day's work
 - 8pt = two days' work

You should only estimate 1pt if you know exactly how to do something
and it's just a few lines of code. The “work” mentioned above is
pre-code-review work.  While we are aligning the whole team on
estimation, we're assuming that:
1) the accuracy of an estimate decreases with size and 
2) the amount of work that a code review will generate can be up to
   equal the amount of initial work, and increases with estimate size. 

As such, a guideline we're using is that a person will complete ~2 8pt
tasks in one sprint, and that this won't necessarily be the same as
completing 4 4pt tasks in one sprint (since 4pt tasks are expected to
both be more accurate and typically have easier code review).

Some additional guidelines when setting up cards:
 - Consider ways to break the work down further.
 - Estimates should only be 1/2/4/8. You should not use 3 or 5-7pt estimates.
 - If you have a task that feels like >8pts of work, it probably needs to be
   broken down further.

There is work that is research-heavy. Work with the team leads to figure out
how best to account for that work.

** Feature Buddy

Every new feature will essentially be developed by two people: The
developer to whom the work item is assigned to, and the so-called
/feature buddy/.

It's the job of the feature buddy to know as much as the original
author about a particular change. He participates early in the
process, already in the design phase before coding starts.

Once a pull request is opened, the original author's code gets
reviewed in-depth by the feature buddy. His thumbs-up is the final
verdict on the pull request, after which the PR is handed over to the
/gatekeeper/.

Use the "Assignee" feature of the GitHub PR to assign the PR to the
feature buddy while it is under review, and also assign it to the
gatekeeper once review is done. This makes it easy to filter in the PR
overview table, to find out who is responsible for which PR.

Anyone can be asked to be feature buddy.

The role is long-lived. Generally feature buddies will work together
for the life of a feature. This does not mean that one will always be
coding and the other reviewing. If a feature spans multiple sprints it
would be common to alternate code buddy and review buddy roles.

If a buddy is sick, or needs to go on vacation, the other will be
qualified to discuss or pick up the feature, if needed.

For larger features that require more than one coder, more than one
developer can synchronize and plan with one review buddy.

If the larger feature uses an integration branch, the merge into the
integration branch can be done by the feaure buddy. This merge does
not need gatekeeper signoff.

This does not imply a project management responsibility for only the
reviewer. Everyone on the team is expected to understand at least the
immediate context of what they are working on.

** Gatekeeper

The role of the gatekeeper is to manage the stream of pull
requests. The gatekeeper will check that a particular PR fulfills our
development standards, such as:

- Containing a link to a feature tracker issue
- Has been fully reviewd by the feature buddy
- Any dependencies (such as Devops changes) have been completed
- etc.

If the gatekeeper agrees that a PR is ready, he is free to merge them
to our "develop" branch. Merges should include a descriptive message
about what the branch in question added/changed/fixed. Merges should
very rarely only use the default Github merge content. The PR
description should be such that it should largely be good content for
the merge message (though it may also include additional testing
information).

There is one gatekeeper that takes care about UI-related pull
requests, and one for platform related pull requests. More details
below about some UI-specific gatekeeping tasks.

The gatekeeper is a role that rotates among members of the team.

Every gatekeeper has also a substitute who takes over duties in case
the designated gatekeeper is not available. Futhermore, if the
gatekeeper was feature buddy or original author of a PR, he should not
merge his own work (or the work he reviewed and accepted), but hand it
off to the subsitute who will then act as a gatekeeper for that PR.

Should it happen that both the feature buddies are also gatekeepers
for their respective area (platform or UI), one of them will still
merge the PR, but has to be extra careful. It is ok if he wants to
reach out for someone else to give an additional thumbs-up.

** UI Gatekeeping

UI gatekeepers should keep an eye out for branches that can have
far-reaching effects. For example, branches that touch `common.scss`,
`admin.scss`, `main-template.html`, and other broadly-named files are
good ones to look out for. When these files are touched, the UI
gatekeeper should do a walkthrough of the UI to make sure that
everything is still working and looking reasonable at a high level ---
and pull in additional help where needed to check this.