Issue Checklist Template

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 *

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

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)