Code Ownership and Boundaries: Phrases for Navigating Shared Codebases
5 exercises on code ownership phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You need to make a change but aren't sure who is responsible for a module. What do you ask?
FINDING MODULE OWNERS: "Who owns [module]? I'm planning to [change] and want to check in with the right team." is the professional way to ask about ownership. It combines the question with context, so the responder understands why you're asking and can give a useful answer. Examples: "Who owns the rate-limiter middleware? I need to increase the limit for the internal API and want to make sure I'm not breaking something." / "Who owns the onboarding flow components? I'm touching the registration page and want to flag the change." / "Who owns the billing service? I'm adding a new webhook type and need to understand the event schema." Options A/D sound like blame attribution. Option C is too vague to generate a useful response.
2 / 5
You are about to make a change in another team's module. How do you notify them proactively?
PROACTIVE HEADS-UP: "I'm making a change in your area — heads up." followed by what and where, with a link, is the gold standard for cross-team awareness. It gives the owner a chance to review, flag concerns, or simply stay informed. Examples: "Heads up — I'm touching the shared analytics helper. Adding a new event type. PR is up for your review if you want to take a look." / "I'm making a change in your area — I've refactored how the config is loaded in the deployment service. Wanted to flag it before it merges." / "I'm making a small change in the shared UI library — adding a new prop to the Button component. PR is [link]." Options A/B/C are either retroactive, apologetic, or too vague to be useful.
3 / 5
You've left a comment on a PR owned by another team. How do you announce this professionally?
CROSS-TEAM PR COMMENTS: "I left a comment on [PR] — [short context about whether it's blocking or advisory]." is the considerate way to notify another team. It tells them where to look, whether they need to act before merging, and shows collaborative intent. Examples: "I left a comment on the payments PR — flagging a potential race condition in the refund flow. Worth discussing before merge." / "I left a note on the design system PR — it's non-blocking, just a question about naming conventions for the new tokens." / "I left a comment on your migration PR — there's a missing index that might cause a slow query in production at scale." Options B/C/D give no context about what the comment is or how urgent it is.
4 / 5
Your change will break the API contract used by two other teams. How do you coordinate?
COORDINATING BREAKING CHANGES: "This is a breaking change — I'll coordinate the migration." signals ownership and responsibility. The professional standard includes advance notice, documentation, and migration support. Examples: "This is a breaking change — I'm giving four weeks notice. Migration guide is in the PR description, and I'm available for pairing sessions." / "Breaking change: the response shape of /users/me is changing. I'll maintain a compatibility shim for two sprints while teams migrate." / "This is a breaking change — I'll open a tracking issue, tag all affected teams, and run a migration office hour next week." Options A/B/D don't acknowledge the impact on other teams or offer any coordination.
5 / 5
You've submitted a PR that modifies a CODEOWNERS-protected file. How do you request their review?
REQUESTING CODEOWNERS REVIEW: "Can we get a CODEOWNERS review? I've made changes to [file/area] — [context] — and want [team]'s sign-off before merging." is the complete professional request. It names the file, provides context, and explains why you're asking for that specific team. Examples: "Can we get a CODEOWNERS review? I've modified the base Dockerfile — it's a small change, but the infra team should sign off given the blast radius." / "Requesting CODEOWNERS review from the security team — I've updated the CSP headers in the nginx config." / "Can we get a CODEOWNERS review on the API gateway config changes? The network team has context on the rate-limiting rules I've modified." Options A/C/D are either too generic or too informal to trigger the right review.