Wildbase Work is the source of truth for what is being attempted and whether it is done. A pull request is the source of truth for a proposed code change. Keep the two linked.

Choose a task

Choose work with a clear user or operational outcome, a size you can reasonably understand, and no unnamed production authority. If useful work is missing, create it before investing heavily.

A ready task answers:

  • What is wrong or missing?
  • Who or what is affected?
  • What observable result would count as done?
  • Which repositories or systems are probably involved?
  • What constraint or prior decision must be preserved?
  • Does it need protected access, a vote, a migration, or a release owner?

If those answers are discoverable from code or existing decisions, add them yourself. Do not turn every incomplete sentence into a meeting request.

Claim it lightly

Leave a note such as:

Outcome: <observable result>
Next: <first concrete action>
Likely scope: <repositories or paths>
Open question: <only the question that could change the work>

Claiming the task means keeping its record accurate. It does not promise uninterrupted progress or reserve a whole product area.

Establish the baseline

Before broad edits:

  1. run git status --short;
  2. read all applicable instruction files;
  3. find the current source contract and focused tests;
  4. reproduce the reported behaviour when safe;
  5. run the smallest relevant checks; and
  6. record any failure that existed before your change.

Never discard or reformat unrelated work in a shared checkout. If existing changes overlap the task and cannot be preserved safely, stop that edit and record the conflict.

Open the pull request early

Create a branch and draft pull request before the implementation becomes difficult to explain. Use the description for:

Wildbase Work: <task link>

Outcome
<what becomes true>

Approach
<smallest coherent design>

Risks
<data, compatibility, privacy, deployment, or UX risk>

Verification
<checks and manual cases to run>

Follow the repository’s branch and signed-commit rules. Do not commit directly to the default branch. The complete Git rules live in Code and review.

Keep the record useful

Update the task when the scope changes, a decision is made, another repository becomes necessary, or a blocker survives the next obvious attempt. Put code-specific reasoning on the pull request and link it from the task.

Useful blocker notes state:

  • the action attempted;
  • the exact failure, with secrets removed;
  • what was ruled out;
  • the smallest missing decision, permission, service, or tool; and
  • the next safe action another volunteer could take.

“Blocked” without evidence moves the question to somebody else. Evidence makes it shared work.

Review and merge

Request a reviewer who has repository review permission and enough context for the risk. Resolve the substance of feedback, not just the comment thread. Re-request review after material changes.

Before merge, the pull request needs the required approval, passing required CI, and a verification note that distinguishes automated checks from manual checks and skipped checks. The author does not satisfy their own approval requirement.

Close or hand off

After merge, complete any authorised release or verification step named on the task. Then update Wildbase Work with the merged pull request, observable result, remaining work, and any follow-up issue.

If you stop before merge, leave the branch or patch recoverable and write:

Current behaviour:
What changed:
What remains:
Checks run:
Known risk:
Next action:

No apology essay is required. The hand-off is the useful part.