XeplosionTechnologies/.forgejo

Watch

Fork 0

Add utility to seed the standard project board #42

New issue

Open

opened 2026-09-07 22:36:50 +00:00 by Xeplosion · 0 comments

Xeplosion commented

2026-09-07 22:36:50 +00:00

Owner

What problem or capability gap does this address?

When a repository needs a project board, Forgejo does not automatically create the Xeplosion Technologies standard board as part of repository creation.

Manually creating the board repeatedly is slower and makes it easy to omit a column, use inconsistent colors, or forget that Triage should be the default column.

Not every repository requires a project board, so the goal is not to make board creation mandatory. The missing capability is a convenient, repeatable bootstrap path when a board is appropriate.

Desired outcome

Provide a supported utility that can create the recommended standard repository project board on demand.

The generated board should use:

Column	Color
Triage	`#eb6420`
Backlog	`#6b7280`
To Do	`#3b82f6`
In Progress	`#f59e0b`
In Review	`#5319e7`
Completed	`#22c55e`

Triage should be created/configured as the default column.

The utility should preserve the principle that these are recommended standards rather than an immutable board design.

Proposed solution

Add a repository/project bootstrap utility to .forgejo, likely a script using the Forgejo API.

Forgejo API research

Confirm API support for repository project creation.
Confirm API support for board/column creation.
Confirm how the default column is configured.
Confirm API support for column colors.
Confirm required token scopes.
Confirm how existing/partial projects can be detected.

Script behavior

Accept the target owner/organization.
Accept the target repository.
Accept authentication securely.
Create the standard project.
Create Triage.
Make Triage the default.
Create Backlog.
Create To Do.
Create In Progress.
Create In Review.
Create Completed.
Apply standard colors.
Prevent accidental duplicate boards.
Handle partially configured existing boards safely.
Provide clear success/failure output.

Flexibility

Decide whether project name/description may be overridden.
Decide whether column names/colors may be overridden.
Ensure customization does not make the standard path difficult.
Do not automatically create boards for every repository.

Validation

Test against a disposable repository.
Test when no project exists.
Test when the standard project already exists.
Test against a partially created project.
Test insufficient API permissions.
Confirm Triage is actually the default column.
Compare generated output against the canonical Project Template.

Documentation

Document usage.
Document token requirements.
Document when a repository should or should not have a project board.
Reference the canonical Project Template.
Add the utility to New Organization / repository bootstrap guidance where appropriate.

Alternatives considered

Manual creation. Acceptable for uncommon/custom boards, but unnecessarily repetitive for the standard case.

Automatically create a board for every repository. Rejected because project boards are intentionally optional depending on repository scope.

One-shot workflow on first push. Possible, but adds automation complexity for a task that may not be needed for every repository.

Risk / compatibility considerations

The utility must be safe to rerun and should not overwrite customized boards.

It should create the standard as a starting point without implying that repositories are forbidden from adapting their board when there is a legitimate use case.

Target / affected branch(es)

main

Additional context

The canonical reference board is the .forgejo Project Template.

This issue is being moved from .profile because repository initialization and Forgejo automation belong in .forgejo, not the organization profile repository.

Request checklist

I searched for an existing issue or discussion covering this request
I described the problem or capability gap, not only a proposed implementation

Workflow lifecycle

Triage

Kind/ classification confirmed
Issue validity reviewed and appropriate Reviewed/ label assigned
Priority/ assigned when appropriate
Implementation branch referenced on the issue through Forgejo when applicable
Information requirements resolved; no Status/Needs More Info remains
Status/Needs Triage removed before leaving Triage

Backlog

Issue is confirmed valid and accepted into the project backlog

To Do

Scope and expected outcome are sufficiently defined
Known prerequisites, dependencies, and required decisions are resolved or understood
Work has been deliberately selected as upcoming work

In Progress

Assignee or active owner identified when appropriate
Forgejo timer started when time tracking provides meaningful value
Relevant implementation, research, or work notes recorded as needed
Forgejo timer stopped when active work ends, pauses, or becomes blocked

Review Gate

Review requirement assessed based on complexity, criticality, reversibility, and impact
If review is required: moved to In Review and appropriate testing / validation performed
If review is required: review comment records what was reviewed, how it was validated, findings, and outcome
If review is not required: rationale is evident from the low-risk nature of the change

Completed

Acceptance criteria / intended outcome satisfied
Related PRs, commits, documentation, or external changes linked where applicable
Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified
Follow-up work split into separate issues where appropriate
Any Forgejo timer is stopped and recorded time is final
Issue moved to Completed and closed

### What problem or capability gap does this address? When a repository needs a project board, Forgejo does not automatically create the Xeplosion Technologies standard board as part of repository creation. Manually creating the board repeatedly is slower and makes it easy to omit a column, use inconsistent colors, or forget that **Triage** should be the default column. Not every repository requires a project board, so the goal is not to make board creation mandatory. The missing capability is a convenient, repeatable bootstrap path when a board is appropriate. ### Desired outcome Provide a supported utility that can create the recommended standard repository project board on demand. The generated board should use: | Column | Color | | ----------- | --------- | | Triage | `#eb6420` | | Backlog | `#6b7280` | | To Do | `#3b82f6` | | In Progress | `#f59e0b` | | In Review | `#5319e7` | | Completed | `#22c55e` | **Triage** should be created/configured as the default column. The utility should preserve the principle that these are recommended standards rather than an immutable board design. ### Proposed solution Add a repository/project bootstrap utility to `.forgejo`, likely a script using the Forgejo API. ### Forgejo API research * [ ] Confirm API support for repository project creation. * [ ] Confirm API support for board/column creation. * [ ] Confirm how the default column is configured. * [ ] Confirm API support for column colors. * [ ] Confirm required token scopes. * [ ] Confirm how existing/partial projects can be detected. ### Script behavior * [ ] Accept the target owner/organization. * [ ] Accept the target repository. * [ ] Accept authentication securely. * [ ] Create the standard project. * [ ] Create **Triage**. * [ ] Make **Triage** the default. * [ ] Create **Backlog**. * [ ] Create **To Do**. * [ ] Create **In Progress**. * [ ] Create **In Review**. * [ ] Create **Completed**. * [ ] Apply standard colors. * [ ] Prevent accidental duplicate boards. * [ ] Handle partially configured existing boards safely. * [ ] Provide clear success/failure output. ### Flexibility * [ ] Decide whether project name/description may be overridden. * [ ] Decide whether column names/colors may be overridden. * [ ] Ensure customization does not make the standard path difficult. * [ ] Do not automatically create boards for every repository. ### Validation * [ ] Test against a disposable repository. * [ ] Test when no project exists. * [ ] Test when the standard project already exists. * [ ] Test against a partially created project. * [ ] Test insufficient API permissions. * [ ] Confirm Triage is actually the default column. * [ ] Compare generated output against the canonical Project Template. ### Documentation * [ ] Document usage. * [ ] Document token requirements. * [ ] Document when a repository should or should not have a project board. * [ ] Reference the canonical Project Template. * [ ] Add the utility to New Organization / repository bootstrap guidance where appropriate. ### Alternatives considered **Manual creation.** Acceptable for uncommon/custom boards, but unnecessarily repetitive for the standard case. **Automatically create a board for every repository.** Rejected because project boards are intentionally optional depending on repository scope. **One-shot workflow on first push.** Possible, but adds automation complexity for a task that may not be needed for every repository. ### Risk / compatibility considerations The utility must be safe to rerun and should not overwrite customized boards. It should create the standard as a starting point without implying that repositories are forbidden from adapting their board when there is a legitimate use case. ### Target / affected branch(es) `main` ### Additional context The canonical reference board is the `.forgejo` **Project Template**. This issue is being moved from `.profile` because repository initialization and Forgejo automation belong in `.forgejo`, not the organization profile repository. ### Request checklist - [x] I searched for an existing issue or discussion covering this request - [x] I described the problem or capability gap, not only a proposed implementation ### Workflow lifecycle ### Triage - [ ] `Kind/` classification confirmed - [ ] Issue validity reviewed and appropriate `Reviewed/` label assigned - [ ] `Priority/` assigned when appropriate - [ ] Implementation branch referenced on the issue through Forgejo when applicable - [ ] Information requirements resolved; no `Status/Needs More Info` remains - [ ] `Status/Needs Triage` removed before leaving Triage ### Backlog - [ ] Issue is confirmed valid and accepted into the project backlog ### To Do - [ ] Scope and expected outcome are sufficiently defined - [ ] Known prerequisites, dependencies, and required decisions are resolved or understood - [ ] Work has been deliberately selected as upcoming work ### In Progress - [ ] Assignee or active owner identified when appropriate - [ ] Forgejo timer started when time tracking provides meaningful value - [ ] Relevant implementation, research, or work notes recorded as needed - [ ] Forgejo timer stopped when active work ends, pauses, or becomes blocked ### Review Gate - [ ] Review requirement assessed based on complexity, criticality, reversibility, and impact - [ ] If review is required: moved to **In Review** and appropriate testing / validation performed - [ ] If review is required: review comment records what was reviewed, how it was validated, findings, and outcome - [ ] If review is not required: rationale is evident from the low-risk nature of the change ### Completed - [ ] Acceptance criteria / intended outcome satisfied - [ ] Related PRs, commits, documentation, or external changes linked where applicable - [ ] Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified - [ ] Follow-up work split into separate issues where appropriate - [ ] Any Forgejo timer is stopped and recorded time is final - [ ] Issue moved to **Completed** and closed

Xeplosion added the

labels

2026-09-07 22:36:50 +00:00

Xeplosion self-assigned this

2026-09-07 22:36:50 +00:00

Xeplosion added this to the Forgejo Automation & CI/CD project

2026-09-07 22:36:50 +00:00