Checklists and Processes

Checklists for Whiteboard processes

Purpose: to create a maintainable, repeatable, bite-sized process lists to reduce error rates and increase measurability across disciplines on our team.

Setting up a new computer

• First things first: install Apple's developer tools. These come with XCode typically, but here's a list of downloads just in case.
• Install Homebrew
• Install RVM if you're doing anything Ruby related
• Setup your LAMP stack
• Get your local sites run on arbitrary .dev domains, using something like this in your .conf file:

Alias /phpmyadmin /usr/local/share/phpmyadmin
  <Directory /usr/local/share/phpmyadmin/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>
<VirtualHost *:80>
ServerName dev
  DocumentRoot /Users/JonathanCutrell/Sites
  VirtualDocumentRoot /Users/JonathanCutrell/Sites/%-2
  UseCanonicalName Off
  <Directory "/Users/JonathanCutrell/Sites/*">
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

• Consider modifying your dotfiles to make some defaults better
• Set up Backblaze
• Install Slack
• Install Chrome
• Make sure Git is installed and up to date. Try git -v, and then check out gitscm to see if it's old.
• Install Postgres.app
• Install the Heroku CLI, also called the "toolbelt"
• Install Transmit for SFTP, FTP, and S3 transfers
• Install NodeJS, which comes with NPM.
• Generate a keypair and add it to GitHub.

Note: Having issues with your sites directory not working? Make sure you uncomment the line that includes your user conf. It's commented out by default. httpd-userdir.conf - there's a line that includes the users/*.conf from your apache configs.

Pair Programming Session

• Come with a predefined task list
• Focus on a few tasks; both parties should take notes
• The purpose of notes will be to keep track of things that need to be addressed later, after the pairing session
• Look over this: http://guide.agilealliance.org/guide/pairing.html
• And this: https://teamgaslight.com/blog/guidelines-for-effective-pair-programming
• And then this: http://blog.codinghorror.com/pair-programming-vs-code-reviews/
• And maybe this? http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/

Moral of the story: Pairing can be good, but let's keep it under control. It's not always the most important thing to do. Steve Wozniak says to work alone, for example. There is value in solving problems on your own. Some research says pairing is bloat; let's make sure we invest in pairing for learning and out of necessity, not simply out of principle.

Code Review Session

• Code review, especially for more junior developers, should be done on a semi-regular basis.
• The review should be planned ~two days in advance, and should be limited in scope to keep the review between 30m and 1h.
• Code review should also be a time for developers to take notes about necessary/must-do refactorings, as well as "would like to" refactorings.
• Check this out for how to make this an effective thing: https://github.com/thoughtbot/guides/tree/master/code-review

Go-live for the first time: WordPress, WP Engine

1. Ensure that all assets are minified using the gulp script, and that all console.log lines are removed.
2. If staging has already been set up on WP Engine, skip forward.
3. Add the wp-content and wp-content/themes directory to the git repository. This is the only folder necessary to launch on WP Engine (do NOT add Wordpress to your git repo).
4. Make sure your public key has been added to the project on WP Engine
5. Add the production server as a remote; wait for 10-15 minutes after adding your public key to WP Engine to push.
6. Ensure that you've included the minified assets in the header/footer (via functions.php) before pushing live
7. git push staging master

Note that we have the highest tier of service from WP Engine. If ANYTHING goes wrong, chat with customer support; we pay for this, so it is much better to lean on their support than to ask another dev on our team. If their support can't or won't help, or is taking too long, then you should ask someone on our team to take a look.

Any kind of potential overhaul/extensive feature

• Create a new branch to work from (allows small fixes to still be manageable immediately)

Go-live for the first time: Rails, Heroku

• To-do

Pushing new features

• To-do

WordPress new project initiation

• Remove .git folder from Launchframe repository (if cloning)

Static new project initiation

• To-do

Rails new project initiation

• Set up testing

D+D Pre-Handoff Meeting Checklist

This meeting occurs between 50% and 75% of design phase. The following things should be validated as complete or to-be-completed.

• Assess basic feasibility of major sections - verbally identify areas of high complexity and low value (take notes, etc)
• Discuss overall layout approach - full width grid, mobile needs, animation concepts
• Deliverable: Style guide (At this stage, the style guide should be roughly complete. Note, style guide requirements are found below.)
• Determine all necessary ancillary views during this meeting. (This should be a working list of views that have not been explicitly designed yet, but that the content structure calls for.)
• Surface any other questions and concerns on both sides of the table

D+D Handoff Meeting Checklist

• All design assets in full form (not JPG, for example)
• Exported photos at full resolution with a reasonable naming structure
• SVG assets
• Links to font icons
• Accompanying type sheet with all font sizes (This should have been delivered with original style guide, but if it has changed, it should be delivered now)
• Any animations, videos, or other assets that aren't explicit in the design
• Accompanying design document explaining anything else that may not be clear, answering any questions that were raised in the Pre-handoff meeting.

D+D Post-Handoff Meeting Checklist

*This meeting occurs at the 50% or later mark during development.)

• Identify if content structure is still intact
• Confirm all deliverables, one page at a time
• Answer all final questions and concerns related to specific modules before development begins
• Discuss any mobile outliers

D+D Mid-dev Informal Meetings

• To-do

D+D Pre-Launch Meeting

• To-do

Style Guide

This is a good baseline; sometimes there is a need for components beyond the purview of this list, but sometimes you won't need to build out how a form would look & work. When in doubt, ask around.

• Type baseline (Weights/families)
• H1-H6 (Size, leading, tracking, & appropriate padding.)
• Body Copy (Size, leading, tracking (if any), italic, bold & underline treatment)
• Link style (Static/hovered/clicked)
• Button style (Static/hovered/clicked)
• Form (Input field, placeholder text, password field, drop-down list, text field, submit/cancel buttons, and respective inactive/valid/hover/click states for each.)