MokoConsulting/MokoCLI
Public Access
1
0
Fork 0
Code Issues 2 Pull Requests Releases 8 Wiki Activity
Page: unnamed
Pages Recent changes
unnamed workflows-release-system workflows-renovate workflows-reusable-workflows workflows-rs-deployment workflows-secret-scanning workflows-shared-workflows workflows-standards-compliance workflows-static-analysis workflows-sub-issue-management workflows-update-server workflows-workflow-architecture
Clone
40
unnamed
Jonathan Miller edited this page 2026-06-22 00:32:24 +00:00
Table of Contents

Issue Workflow

Issue Types

Configured at the org level in MokoGitea:

Type Color Use For
Bug Red Something is broken
Feature Blue New functionality
Enhancement Teal Improvement to existing feature
Task Gray Non-code work (docs, config, cleanup)
Test Purple Manual test verification ticket

Priorities

Priority Use When
Critical Production broken, data loss risk
High Blocks release or major functionality
Medium Default -- normal work items
Low Nice-to-have, cosmetic, deferred

Issue Lifecycle

Open  -->  In Progress  -->  Review  -->  Closed
  1. Open: Issue created with type, priority, description
  2. In Progress: Developer assigned, branch created
  3. Review: PR created, code review in progress
  4. Closed: PR merged, issue auto-closed via Closes #N

Branch Auto-Creation

issue-branch.yml creates a branch when an issue is assigned:

Issue Type Branch Pattern Example
Feature feature/{#}-{title} feature/42-add-telegram-plugin
Bug fix/{#}-{title} fix/139-duplicate-curl
Enhancement feature/{#}-{title} feature/142-mailchimp-templates
Task feature/{#}-{title} feature/134-update-issue-bodies

Closing Issues

Use commit message keywords to auto-close:

  • Closes #42 -- closes when PR is merged
  • Fixes #42 -- same behavior
  • Multiple: Closes #42, closes #43

Test Tickets

Pattern for manual test verification:

  • Title: Test: {feature description}
  • Body: Checklist with - [ ] items for each test step
  • Related: References the implementation issue/PR

Master Tracking Issues

For releases, create a master issue with layered sub-issues:

  • Layer 1: Critical path (must pass)
  • Layer 2: Features (should pass)
  • Layer 3: Integration (nice to have)
  • Layer 4: Backlog (post-release)

Revision History

Date Author Description
2026-06-22 jmiller Initial version
Pages