Xeplosion Technologies
Shared standards and workflows for work managed by Xeplosion Technologies, LLC.
The goal is simple: make work easy to understand, easy to hand off, and easy to track without adding process that does not provide value.
Issues are not just for developers. They can represent bugs, features, documentation, investigations, infrastructure changes, data work, configuration, research, questions, or other work that needs a clear owner and outcome.
The issue system provides a common language between people with different responsibilities. Someone reporting a problem does not need to understand how it will be implemented, and the person resolving it should not need to reconstruct why the work exists.
For work that does not directly involve code or the functionality of a product built with code, use an appropriate separate project board rather than mixing unrelated organizational work into a product's development board.
Start Here
Standards are useful when they make work easier to maintain, understand, review, or transfer to someone else.
They are not useful when following them takes more effort than the work itself and provides no meaningful future benefit.
Before adding process, ask:
Will doing this the quicker way create technical debt or make the work harder to understand, maintain, verify, or continue later?
If not, keep it simple.
A typo that takes thirty seconds to fix probably does not need an issue, branch, timer, review cycle, and completion report.
A production database change probably does.
The amount of process should scale with the consequences of getting the work wrong.
Work Lifecycle
When an issue is tracked through a project board, the standard lifecycle is:
Triage → Backlog → To Do → In Progress → [In Review] → Completed
In Review is conditional. Use it when the complexity, criticality, or potential impact of the work makes independent validation worthwhile.
The lifecycle matters because it gives everyone a shared understanding of what is happening:
| Column | Color | Meaning |
|---|---|---|
| Triage | #eb6420 |
The issue is being classified, evaluated, and accepted or rejected. |
| Backlog | #6b7280 |
The work is valid and worth retaining, but has not been selected for execution. |
| To Do | #3b82f6 |
The work has been selected and is ready to begin. |
| In Progress | #f59e0b |
Someone is actively working on it. |
| In Review | #5319e7 |
The work is complete enough for testing, validation, or a second opinion. |
| Completed | #22c55e |
The intended outcome has been achieved and the work is finished. |
These columns are the recommended standard. Change them when a project has a real reason to work differently, but preserving the standard makes it much easier for someone to join an unfamiliar project and immediately understand its state.
See Workflow Lifecycle for the complete lifecycle and the expectations at each stage.
Reference Board
The canonical example is the Project Board Template.
| Stage | Example |
|---|---|
| Triage | Issue #12 |
| Backlog | Issue #13 |
| To Do | Issue #14 |
| In Progress | Issue #15 |
| In Review | Issue #16 |
| Completed | Issue #17 |
Work Management
| Page | Covers |
|---|---|
| Issues | What should become an issue, what should not, issue types, and when to use each |
| Labels | Kind/, Priority/, Reviewed/, Status/, Branch/, Compat/, and Meta/ labels |
| Project Boards | When to use a board, how to create one, standard columns, and board organization |
| Workflow Lifecycle | Triage through completion, timers, review, handoffs, and closure |
Project boards are not required for every repository.
Some repositories need no board at all. Others need a repository-specific board. Cross-repository work may belong to an organization-wide board such as Infrastructure & DevOps.
Use the board that matches the work.
Development Standards
Software projects use the same issue-management system, with additional standards for source control, testing, automation, and maintainability.
| Page | Covers |
|---|---|
| Git | Branch strategy, working branches, protected branches, merges, hotfixes, and releases |
| Commits | Conventional Commits and commit-message standards |
| Testing | How much testing is appropriate and how risk changes the required confidence |
| Technical Debt | What technical debt is, when taking it on is reasonable, and how to document it |
| CI/CD | Managed repository templates, workflow propagation, validation, deployment, and shared automation |
Managed repository templates are the preferred starting point for new code repositories because they already include the expected issue templates, pull request templates, workflows, and configuration.
They are a convenience and consistency mechanism—not a requirement when another approach better fits the project.
Language & Platform Conventions
Language-specific pages define project structure, naming, formatting, testing, dependencies, template files, and CI/CD integration.
| Platform | Conventions |
|---|---|
| .NET / MonoGame | .NET & MonoGame |
| Node | Node |
| TypeScript | TypeScript |
| Python | Python |
| PHP | PHP |
| Shell / Scripts | Shell & Scripts |
| Google Sheets | Google Sheets |
These conventions supplement the organization-wide standards. A project may deviate when there is a technical reason to do so.
Starting Something New
Creating a new Forgejo organization managed by Xeplosion Technologies has its own baseline setup.
See New Organization for:
- organization setup;
- shared labels;
- managed template repositories;
- inherited conventions;
- repository defaults;
- project-board considerations;
- exceptions and organization-specific requirements.
Xeplosion-managed organizations inherit the shared standards by default.
If a project or organization needs to work differently, make the difference intentional and document the reason.