This is a checklist I use to work on issues. For this purpose I extracted several cards related to the makandra process and ported them into a check list and refined that over time a little bit.

This task list is divided by the Gate keeping process in the following steps:

1. Starting a new feature
2. Working on the issue
3. Finishing a feature
4. After Review

Here are some tips on it's possible usage:

• I copy the template for every new issue I work on and adjust it accordingly beforehand and use it throughout the gatekeeping process.
• This template is a rather extensive example, you might not consider everything important enough for your own checklist regarding your level of experience
• Feel free to create your own template based on this example as an inspiration
• I like to use Obsidian for updating the checklist because it gives me shortcuts to create, toggle and navigate checklists quite fast while being able to fold completed headings.
• You can also consider adding the checklist for implementing design and the points from Building web applications: Beyond the happy path

The template:

1 Starting a new feature

• Set the issue to "In Progress" in Linear
• Pull the most current main/master branch
• Branch off the master with geordi branch or manually
  • Name your branch like sort-users-by-name-73624, i.e. start with the issue id, then a shortened description. You can also start your branch with your initials, so that everyone can see who is working on the branch, e.g. ab/73624-sort-users-by-name.
  • Make an initial commit with Linear ID and the name of the issue using

    Copygit commit --allow-empty -m <message>
    

• Read the complete issue
• Reread the complete Issue and check if the issue needs further checkpoints

2 Working on the issue

To Do

• Review Acceptance Criteria and Notes
  • Get an overview of what it should do
  • Translate it to code and browser logic

.... Checks from issue ...

3 Finishing a feature

3.1 Check acceptance criteria

... I have a second Checklist to re-check everything from the issue after I finish it ...

... Possibly a second list of things I want myself to remember ...

3.2 Create the merge request

• Within your feature branch, merge the current master and push using:

  Copygit pull origin master  
  git push -u origin feature-branch-name  
  

  You're encouraged to use git pull --rebase if you know how it works.
• Open a merge request by clicking the link Gitlab prints on push.
• To open a merge request manually:
  • "Assign to" with yourself
  • "Reviewer" with your project manager
  • "Title" with a descriptive name, preferably using the issue id and title from Linear. Use the commit bookmarklet to auto-generate the title.
  • "Description", add a link to your Linear issue and Screenshots of any UI Changes
• Set the issue to "Review" in Linear

Merge Request Checklist *

• has been reviewed by yourself beforehand
• escapes all user input
• does not have any log or debugging statements like console.log(...), byebug etc.
• has green tests
• has tests for new features
• has been manually tested in the browser
• has no missing translations in the UI
• has no ugly UI changes (long content breaking out of boxes, elements without margins, etc.)
• works with lots of records without triggering a million queries or loading the world into memory
• sorts all lists (indexes, select dropdowns, ...) by either sorting in the database or using natural_sort in Ruby
• paginates long index lists
• has all necessary database indexes to speed up foreign key look ups and commonly used queries
• if it adds any migrations, takes care of existing records
• if it makes major changes, has updated the README as appropriate

4 After Review

4.1 If your code does not pass review

• Make sure that every comment is checked when you are 100% that it is done
  • Do it, check after it is done
• Run your new specs and features again
• Review Acceptance Criteria and Notes
  • Make sure everything necessary is done

4.2 If your code passes review **

Your project manager will either merge and deploy the changes, or he will ask you to do it yourself in a note to the merge request (you will receive an e- mail)

If you're supposed to merge yourself, you need to

• Run all tests again by using geordi t
• Get the latest master
• Squash your commits using git rebase - i master or something similar
  • Make sure the commit message matches our guideline
• Merge into master

  Copygit checkout master  
  git merge feature-branch-name  
  

• Push
• Delete the feature branch with

  Copygit branch -D feature-branch-name  
  git push origin :feature-branch-name  
  

• Deploy to staging
• Set the corresponding PT issue to “On Staging”
• Close the merge request on GitLab (happens automatically when you merge or delete the remote branch)

Also see:

• Gate keeping
• Merge request Checklist
• Issues
• Implementing design checklist
• Building web applications: Beyond the happy path