Board, cross-project closure, and epic rollup before OKR review
Group checkout contains projects web, api, and infra. Product managers maintain 18 epics at the group level and 120 open issues across the projects. The group issue board lists stage::deployed, but infra uses stage::deploy; those issues sit in No stage. A cross-project merge request from web to api includes Closes api#42, but api#42 remains open after merge. Epic rollup shows 0% complete even though many child issues are closed, and the roadmap shows epics with no dates. The quarterly OKR review is in five days. The team uses labels for stage but not for epic linkage; some issues are linked to epics via the epic sidebar, others only mention the epic in the description. The PM wants a five-day plan to make the board, epic progress, and roadmap trustworthy for the review.
1. Why do `infra` issues land in No stage, and how do you fix the board without breaking other projects?
Read the worked answer
Issue board columns are label-driven. The board column is configured for stage::deployed; an infra issue carries stage::deploy, which does not match, so it falls into the default No stage list. Fix either by relabeling the infra issues to stage::deployed if that is the true stage, or by adding a board column for stage::deploy and mapping it to the same logical position. Because this is a group board, changes affect all projects; prefer standardizing on one scoped label taxonomy, for example stage::deploy and stage::deployed as distinct stages, and document it. Use scoped labels so an issue cannot have both. Bulk-edit the infra issues with the correct label, then verify the board filter. Do not create a separate board for infra unless the team genuinely has a different workflow; that would hide the issue from the group view. Check that lists are not filtered by project or milestone.
2. Why did Closes api#42 not close the issue, and what should be done for cross-project traceability?
Read the worked answer
GitLab automatic issue closing from a merge request works for issues in the same project as the MR. A cross-project reference such as api#42 in a web MR is a link or reference, not an auto-close instruction, so the issue stays open. For this MR, manually close api#42 after verifying the merge, and add a comment linking the MR. For traceability, use the MR description to reference the issue (api#42) and add a related issue link; if the work must auto-close, put the closing keyword in an MR in the api project, or use a small api MR that references the web MR. Standardize: every MR states the issue it delivers, and the issue is closed by the project that owns it. For cross-project epics, link the issue to the epic from the epic sidebar. This avoids false closed states and gives the OKR review a reliable issue-to-MR chain.
3. How would you make epic rollup and the roadmap trustworthy in five days? What do you prioritize?
Read the worked answer
First, fix linkage: epic progress only counts issues that are actually added to the epic, not issues that mention the epic in their description. Use the epic Issues section to add child issues from web, api, and infra; bulk-link the high-priority issues for the review. Second, fix dates: the roadmap needs start and due dates on epics; set them from the quarterly plan, even if approximate, and mark confidence. Third, reconcile status: closed issues count as complete, so close duplicates and done work, and move not-started issues out of the current epic if they are next quarter. Prioritize the 18 epics over all 120 issues: link and date the epics that appear in the OKR review, and leave the rest for later. Use a saved board filter for each epic to verify. In five days you cannot clean everything; produce a known-gaps list and state that rollup is now based on linked issues only. That is more trustworthy than a 0% number.