Task Lifecycle

Intro

This documents the lifecycle of a simple task from ideation through to delivery. This workflow should scale to arbitrarily complex tasks.

Ideation

Let's create a Wiki to document technical standards like this! This work was discussed with the team and then documented in a new GitHub Issue within the SDK repository.

Ticketing

We create a new issue and fill out the template.

• The name of the issue is of the form: COMPONENT > type(scope): description. This is a modified version of Conventional Commits that prepends a "COMPONENT >" string so that on the project kanban view we can easily see which components tickets relate to. See the Conventional Commit examples for example types and scopes.

• Each ticket should have a # Why section that documents why we care about this. Generally this is the problem we are solving, and for whom we are solving it.

• Each ticket should have a # What section that documents what should be done. If we don't know what should be done we know that we need to do discovery and exploratory development, so put that here. This is usually a point-form solution of the problem defined in the # Why section.

• Fill out all of the fields you can on the sidebar.

Working on the ticket

Move the ticket to "In Progress" within the kanban view:

Make a branch

... in a new branch off main that is named after your Conventional Commits type and scope (see above).

git checkout main; git pull; git checkout -b type/scope

Example: git checkout -b docs/platform

Write code

Do your thing! This is the easy part.

Commit code

If necessary, rebase:

git fetch
git rebase -i origin/main

Then commit message should start with the Conventional Commits type and scope you've been using. It should also include a string that closes the related tickets. Also: sign the commit with -S!

Push to your remote and set up tracking, then hop over to the pull requests tab to open a Draft PR.

Open a draft PR

Make sure your merge to main looks clean. Make sure your PR title repeats your Conventional Commits type and scope (potentially add the "COMPONENT >" prefix if the draft is intended to be long-lived enough to show up on the kanban board).

Fill out the right hand sidebar, including requesting a reviewer.

Change the dropdown at the bottom of the PR to create a "Draft PR". Then click that button.

Automated testing pass

When the automatic checks pass, mark the PR ready for review and chase down your reviewer.

Resolve review

Iterate with your reviewer to close out comments, rebase as needed, etc. When they approve the PR, and all the automatic checks pass, and it will merge clean, squash and merge.

Final touches

Add any additional process documentation you would like to the description (new related tickets you're closing, etc), then confirm the squash.

Kanban automation

Now the tickets you marked closed in your commit message and the PR itself will automatically close in the kanban view.

Done!

And that how this wiki was created!