chore: set up a GitHub Project board with the milestones in §16

[sr-857]

F4. chore: set up a GitHub Project board with the milestones in §16

Labels: repository-hygiene

Priority: Medium

Proposed Solution: Create a Project (v2) board with columns Backlog/In Progress/Review/Done, and add all issues from this document tagged with the milestone they belong to.

Acceptance Criteria: [ ] board created [ ] all issues assigned to a milestone and column

Estimated Difficulty: XS

Estimated Time: 1 hour

---

[purvanshjoshi]

[LEGIT - DECISION & IMPLEMENTATION PLAN]

This is a legitimate management request.

To implement this:

1. Create a GitHub Project board mapping the six milestones (M1: Correctness to M6: Polish).
2. Assign issues matching each milestone to the board.

[purvanshjoshi]

This issue remains valid. No GitHub Project v2 board exists tracking the milestones from the audit document.

Suggested approach:

1. Create a Project v2 board at https://github.com/PxA-Labs/Project-RIPRA/projects with columns: Backlog, Ready, In Progress, Review, Done
2. Add all open issues to the backlog column
3. Define milestone fields corresponding to the audit's phase structure (e.g., Phase 1-8)
4. Document board usage in CONTRIBUTING.md

[Shivamkumar31]

i like to work on this plz assign to me

[Shivamkumar31]

Hi @sr-857, I’d like to take ownership of this issue as well.

I understand that the goal is to create a GitHub Projects (v2) board for Project RIPRA, organize the existing issues according to the six milestones (M1–M6), and track each issue through stages such as Backlog, Ready, In Progress, Review, and Done.

I can set up the board, map the relevant issues to their milestones and workflow status, and document the board usage if needed.

Could you please assign this issue to me? I’d be happy to work on it.

[purvanshjoshi]

Thanks for the interest, @Shivamkumar31. Before assigning, a few quick questions so we're aligned — this looks like an XS/1-hour task on the surface, but a few details determine whether it goes smoothly:

1. Projects v2 is field-based, not column-based. GitHub Projects (v2) doesn't use free-form "columns" like classic projects — it uses a Status single-select field (Backlog/Ready/In Progress/Review/Done) and custom fields. The issue text mentions columns, but the v2 implementation is a Status field. Are you comfortable setting that up via the v2 UI / gh project CLI, and would you encode the milestone as a separate custom field (M1–M6)?

2. Repo state check. There are currently no GitHub Milestones and no Project v2 board in this repo (I checked). So "map issues to milestones M1–M6" means defining those milestone values from scratch. The milestones table in §16 lists which issues belong to which milestone (e.g., M1: A1, A2, A4, A6...). Since those IDs (A1–H3) are audit-document IDs rather than GitHub issue numbers, how would you map them to the actual open issues in this repo?

3. Automation or manual? Would you wire up the add-to-project GitHub Action so newly opened issues auto-enter the Backlog, or keep it purely manual? That changes the "everything stays in sync" story.

4. Documentation. The issue's acceptance criteria include documenting board usage in CONTRIBUTING.md. Any thoughts on what the section should cover (field semantics, triage workflow, who moves items)?

Again — not assigning yet, just want to confirm alignment on the above first.

[Shivamkumar31]

Thanks for the clarification. Yes, I understand the distinction between GitHub Projects v2 fields and the old column-based Projects model.

For the board, I would use:

• Status: Backlog → Ready → In Progress → Review → Done
• Milestone: a separate single-select field with M1–M6
• Keep milestone and workflow status separate, since the milestone represents the project phase while Status represents the current state of the work.

For the audit IDs (A1–H3), I would not assume they correspond directly to GitHub issue numbers. I would first create an explicit mapping between the audit IDs and the actual repository issues using the issue titles/descriptions. If an audit item does not have a corresponding GitHub issue, I would not invent a mapping; I would flag it for maintainer clarification.

For automation, I would prefer newly created issues to be automatically added to the Project in Backlog, while milestone assignment and later status transitions remain manual/maintainer-driven. This avoids automation incorrectly guessing which milestone an issue belongs to.

For CONTRIBUTING.md, I would document:

1. The meaning of each Status value.
2. The meaning of the M1–M6 milestone field.
3. When contributors should move an issue between statuses.
4. That a PR moves the work to Review and a merged/closed issue moves to Done.
5. That milestone assignment should follow the audit mapping rather than being inferred from the issue number.

I would first verify the current repository issues and the audit mapping before creating the fields, so that the board reflects the actual project state rather than making assumptions.

If this matches the intended setup, I'm happy to proceed with the board and documentation.

[Shivamkumar31]

Thanks for confirming the expectations. I’m aligned with the proposed setup and ready to proceed.

I’ll wait for the issue to be assigned to me before making any changes. Once assigned, I’ll first verify the current open issues against the audit IDs, then set up the Projects v2 fields/workflow and update CONTRIBUTING.md accordingly.

Please assign the issue to me when ready. Thanks!