Ask candidates to hand back a fork, not a branch or PR - #2
Merged
Conversation
"A branch or PR with your work" points at this repository, which is the wrong place for it twice over. A branch pushed here is readable by everyone with access to the repo, and a PR opened against this repo is too -- so as soon as more than one candidate is in flight, each can read the others' solutions. It also means candidates need push access to the repo that holds the exercise. A fork fixes both: the work lives in the candidate's own private fork, and because private forks inherit *team* permissions from upstream, the teams with access here get access to every fork without anyone being invited. Candidates added individually are not in those teams, so they cannot see each other's work. The PR is specified against their own fork rather than back to this one, so the diff is reviewable without being published to the other candidates. Note this needs forking enabled to be actionable: the org currently sets members_can_fork_private_repositories to false and this repo sets allow_forking to false. Both need turning on before this wording is true.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One-line change to
TASK.md's What to hand back.Why
Both point at this repository, which is the wrong place for a candidate's solution:
What it says now
A fork fixes both problems, and there's a detail that makes it fit this case neatly: private forks inherit team permissions from upstream, but not individual ones. This repo's access comes entirely from three teams (
Devs,agent-experience,Onboarding Experience— 0 direct and 0 outside collaborators today), so:The PR is specified against their own fork, not back to this one, so we still get a reviewable diff without it being published to the other candidates.
This wording isn't actionable until forking is enabled — right now a candidate following it would hit a wall:
AgentSoftwaremembers_can_fork_private_repositoriesfalseallow_forkingfalseFor a private repo GitHub needs both. Worth knowing the org one is org-wide: it makes every private repo in
AgentSoftwareforkable, not just this one. Flagging rather than changing — @cgrice is handling the permissions separately.If that org-wide change turns out to be unwanted, the alternative that needs no org setting is making this a template repository (
is_template: true): candidates click "Use this template" and get a clean private repo with no fork relationship. The trade is that template copies don't inherit team permissions, so candidates would have to invite reviewers themselves. Happy to switch the wording to that instead.Context
Found while doing the exercise — I hit this on the first step and had to work around it by copying the repo rather than forking. See also #1, which fixes the Tests workflow failing on a fresh clone.