4 of the 4 questions we have for this objective, shown with the answer and the reasoning.
Design and implement traceability and flow of work
Quillon Software tracks work for three repositories, quillon/api, quillon/web, and quillon/mobile, entirely in GitHub and must stay in GitHub. The product owner wants one planning surface that shows issues and pull requests from all three repositories, records an Estimate number and a Target Sprint for each item, and offers both a board view grouped by status and a table view sorted by estimate.
What should you use?
- AA separate repository-level milestone in each of the three repositoriesMilestones group issues inside a single repository and track a due date and progress percentage, but they cannot combine three repositories or hold custom number and iteration fields.
- BAn organization-level GitHub project with a Number custom field, an Iteration field, and separate board and table viewsGitHub Projects can hold issues and pull requests from many repositories in the organization, support custom fields such as Number and Iteration, and offer multiple saved views including board and table layouts.
- CLabels named estimate-1 through estimate-13 and sprint-1 through sprint-26 applied in each repositoryLabels are repository-scoped text tags; they cannot be summed or sorted as numbers and would need to be duplicated in every repository, which is error-prone.
- DAn Azure Boards project connected to the three repositories by using the Azure Boards app for GitHubAzure Boards could track the work, but it moves planning out of GitHub, which the scenario explicitly forbids.
Why: GitHub Projects is the GitHub-native planning tool that spans repositories. A project lives at the organization or user level, accepts issues and pull requests from any repository there, and adds custom fields such as text, number, date, single select, and iteration. Each project can have multiple views with table, board, or roadmap layouts, each with its own grouping, sorting, and filtering. The must-stay-in-GitHub constraint eliminates Azure Boards, while milestones and labels lack cross-repository scope and typed fields.
Design and implement traceability and flow of work
Harrowgate Health uses an Azure DevOps organization named harrowgate with a project named ClaimsHub and an Azure Repos Git repository named claims-api. Auditors require traceability from every change merged into main back to an approved User Story or Bug work item. Developers sometimes forget to link work items, and the team wants the requirement enforced automatically with minimal administrative effort.
What should you configure on the main branch?
- AA branch policy that requires a minimum of two reviewersRequired reviewers improve quality but do not check whether the pull request is linked to a work item, so traceability gaps remain.
- BA build validation policy that runs a script to search commit messages for work item numbersA custom script could approximate the check, but it adds code to maintain and duplicates a built-in policy, which conflicts with minimal administrative effort.
- CA branch policy that requires linked work items set to RequiredThe Check for linked work items policy, set to Required, blocks completion of any pull request into main that is not linked to at least one work item, which enforces the audit requirement natively.
- DA service hook that creates a Bug work item whenever a pull request is completedAuto-creating work items after the merge produces meaningless links and does not tie the change to the approved story or bug that justified it.
Why: Azure Repos branch policies are the native way to enforce rules on pull requests that target a protected branch. The Check for linked work items policy can be Optional, which only warns, or Required, which blocks completion until a work item is linked. Because the pull request is linked to the work item, its commits and the eventual build are traceable from the work item's Development section. Reviewer counts and custom scripts address different concerns or add effort, and generating work items after the fact defeats the purpose of traceability.
Design and implement traceability and flow of work
Larkspur Analytics keeps a web application in a GitHub repository named larkspur-analytics/portal. The team deploys to production several times a day from the main branch and wants a single lightweight workflow with no long-lived develop or release branches. Every change must be reviewed before it reaches main.
Which workflow should the team adopt?
- AGitHub Flow: create a short-lived branch from main, open a pull request, get a review, merge to main, and deployGitHub Flow uses only main plus short-lived topic branches, with pull requests as the review point, which matches frequent deployment from main and the no-long-lived-branches requirement.
- BGit Flow with develop, release, and hotfix branches alongside mainGit Flow adds long-lived develop and release branches, which the team explicitly wants to avoid and which slows down multiple daily deployments.
- CA release branch per sprint that is merged back to main at the end of each sprintSprint release branches batch changes for days or weeks, which conflicts with deploying several times a day from main.
- DDirect commits to main by all developers with a weekly review of the commit historyCommitting directly to main skips the pre-merge review that the scenario requires; reviewing history after the fact does not gate changes.
Why: GitHub Flow is a branch-based workflow built around a single deployable main branch. Developers create a descriptive branch, commit, open a pull request, address review feedback, and merge, after which main is deployed. The deciding constraints are frequent deployment from main and no long-lived branches, which rule out Git Flow and sprint release branches. Direct commits to main are fast but remove the review gate the team requires.
Design and implement traceability and flow of work
Ferncliff Labs maintains an open-source SDK in the GitHub repository ferncliff/sdk-dotnet. Bug reports arrive as free-text issues that often lack the SDK version, runtime, and reproduction steps, so maintainers spend days asking follow-up questions. The maintainers want every new bug report to collect those fields as required inputs and to be labeled automatically for triage, while keeping all feedback in GitHub Issues and minimizing administrative effort.
What should you configure?
- AAn issue form YAML file in .github/ISSUE_TEMPLATE with required input fields and a default bug labelIssue forms define structured inputs with validations such as required: true and can apply labels automatically, so every bug report arrives complete and pre-labeled for triage.
- BA CONTRIBUTING.md file in the repository root that lists the information to include in bug reportsCONTRIBUTING.md is guidance that GitHub links to, but it cannot enforce required fields or apply labels, so incomplete reports would continue.
- CA GitHub Discussions category named Bugs with a pinned post that describes the required detailsDiscussions moves feedback out of GitHub Issues, and a pinned post does not enforce any fields or labels.
- DA repository webhook that sends each new issue to an Azure Function, which comments when fields are missingA custom webhook handler could nag reporters after the fact, but it requires building and running code and still does not prevent incomplete submissions, which violates the minimal-effort constraint.
Why: A fast feedback cycle depends on receiving actionable information the first time. GitHub issue forms, stored as YAML files under .github/ISSUE_TEMPLATE, render a web form with typed inputs, dropdowns, and required validations, and they can assign labels, assignees, and projects automatically. The deciding factors are required inputs, automatic labels, staying in GitHub Issues, and minimal effort. Documentation files and Discussions only suggest behavior, and a webhook-based bot is custom code that reacts after the incomplete report already exists.