Issue Checklist Template

Updated . Posted . Visible to the public.

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
      git 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:
    git 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
  • Merge into master
    git checkout master  
    git merge feature-branch-name  
    
  • Push
  • Delete the feature branch with
    git branch -D feature-branch-name  
    git push origin :feature-branch-name  
    
  • Deploy to staging
  • Set the corresponding issue to “On Staging”
  • Close the merge request on GitLab (happens automatically when you merge or delete the remote branch)

Also see:

Felix Eschey
Last edit
Michael Leimstädtner
Keywords
issue, ToDo, list, to, do, story, stories
License
Source code in this card is licensed under the MIT License.
Posted by Felix Eschey to makandra dev (2023-03-09 09:11)