Reading Contributing Guidelines

Option B correctly follows all three explicit requirements in the CONTRIBUTING.md:

Reading requirements as requirements, not suggestions:
The word "must" in "commits must follow Conventional Commits" and "will be closed" for unlinked PRs are not soft language — they are hard gates. Many CI pipelines actually lint commit messages automatically (commitlint) and some bots auto-close PRs without a linked issue. Treating these as optional is the #1 reason first PRs get bounced.

Conventional Commits format:
`type(scope): description` — e.g. `fix: resolve null pointer in parseConfig()`. Common types: fix (bug fix), feat (new feature), docs, chore, refactor, test. This format is machine-readable — many projects auto-generate CHANGELOG.md and determine semantic version bumps (patch/minor/major) directly from commit type.

"PRs without a linked issue will be closed":
This means: open (or find) an issue first, then reference it in the PR — `Closes #142` or `Fixes #142` in the description, which auto-links and auto-closes the issue on merge. Skipping this step, even with a well-written PR, risks an automatic close by a bot before a human even looks at it.

Why "the rules seem like guidelines" is risky:
CONTRIBUTING.md is the project's explicit statement of what they will and won't accept. Ignoring it signals you didn't read it — which is often visible to maintainers even without them saying so (e.g. commit format mismatches are immediately obvious in the PR history).

Option B correctly explains the legal function of this CLA/licensing clause:

Why this clause exists:
Open-source projects need clear legal chains of ownership. If a contributor submits code they copied from a proprietary source, or code their employer legally owns and hasn't authorized for open-source release, the project could face a legal claim later. The CLA (or the lighter-weight DCO — Developer Certificate of Origin, usually satisfied with a `Signed-off-by:` line via `git commit -s`) creates a paper trail confirming the contributor had the right to submit the code.

What contributors should actually check before contributing:
1. Does your employment contract have an IP assignment clause that could cover code you write, even in your own time? Some companies require written permission for employees to contribute to open source.
2. Are you copying code from another codebase with an incompatible license (e.g. copying GPL code into an MIT project)? This can create license contamination.
3. Is there a `CLA-bot` or `DCO check` in the project's CI? If so, your PR will be blocked until you sign electronically or add `Signed-off-by:` to your commits.

Why "it's just boilerplate" is wrong:
It has real legal weight — it's the mechanism that lets projects legally accept and redistribute contributions. Corporate contributors especially should not assume this is irrelevant; many companies require legal sign-off before employees contribute to external projects, precisely because of clauses like this.

DCO vs full CLA:
DCO is lighter — just a sign-off statement per commit, no separate document to sign. Full CLA (used by some larger foundations) may require a one-time signed agreement, sometimes through a bot that comments on your first PR with a link to sign.

Option B is the correct, practical reading of a Code of Conduct (CoC):

Why reading the CoC before engaging matters:
1. Calibrates communication style — a CoC that explicitly bans "personal or political attacks" and "derogatory comments" signals a community where blunt criticism should target the code/idea, never the person. This is useful even in disagreement: "This approach has a race condition" is fine; "this is a lazy implementation" crosses into personal territory.
2. Tells you where to report problems — every Contributor Covenant-based CoC has a contact section (usually an email address of a small enforcement team, kept separate from the general maintainers so reports about a maintainer can still be made safely). Knowing this exists — and where it is — matters if you ever witness harassment.
3. Signals real enforcement authority — most CoCs describe a clear escalation ladder: private warning → temporary ban → permanent ban. This isn't just decoration; large projects (Rust, Python, Kubernetes) have publicly banned contributors under their CoC. Assuming it's "never enforced" is a real risk.

Why "only applies to maintainers" is wrong:
Contributor Covenant explicitly applies to "everyone participating" in project spaces — issues, PRs, Discord/Slack, mailing lists, and often even conference spaces associated with the project. Contributors, first-time posters, and lurkers are all covered.

Practical takeaway:
Reading the CoC for 2 minutes before your first post costs almost nothing and prevents the most common first-timer mistake: overly casual jokes or blunt criticism landing badly in a community whose norms you don't yet know.

Option B correctly applies the explicit exception structure in this CONTRIBUTING.md:

Reading conditional rules precisely:
This clause carves out ONE exception ("small typo fixes and documentation corrections") and explicitly states the general rule ("all other changes, including bug fixes") requires an issue first. Bug fixes are explicitly named as NOT exempt — so confidence in the fix's correctness is irrelevant to the process requirement.

Why "open the issue first" protects your effort:
1. The maintainer might already be aware of the bug and have a fix in progress, or a different root-cause diagnosis than yours
2. The maintainer might have architectural context that changes the "right" fix (as in cases where a quick patch conflicts with planned refactoring)
3. Getting alignment before writing code avoids the frustrating case of a PR being rejected after significant work, because the approach — not the code quality — was wrong

Why skipping straight to a PR is risky even when you're right:
Even a technically correct PR can get closed unreviewed if it violates the stated process, simply because maintainers use "requires an issue" as their triage/spam filter. Following the process is often more decisive for getting merged than the quality of the fix itself.

The general principle:
CONTRIBUTING.md documents often distinguish trivial changes (typos, docs) from substantive changes (logic, behavior, APIs) precisely because substantive changes benefit from a design discussion before implementation — this is the same principle behind RFCs for larger changes.

The key here is recognizing that a 500 error indicates a serious problem. Opening a PR immediately would be premature and potentially misleading. Ignoring it isn't a solution; proper issue tracking is crucial for collaboration. Reporting the error with details allows the backend team to investigate effectively – this aligns perfectly with the guidelines regarding escalating issues.

The CONTRIBUTING.md explicitly requires linking to issues. This is vital for traceability and context within the project. While other details are helpful, connecting the PR back to its originating problem ensures proper workflow and allows reviewers to easily understand the purpose of the change.

TypeScript's 'strict type checking' means that David *must* understand the project's type system. Simply stating 'I fixed a typo!' doesn't demonstrate this understanding. A proper commit message would acknowledge the use of TypeScript and highlight any adjustments made to ensure code adheres to those rules – this is a common misconception.

The CONTRIBUTING.md clearly states that all features require discussion *before* implementation. This ensures alignment with the project's goals and prevents wasted effort. Starting an issue allows for collaborative refinement of the feature's requirements – this is a core principle of open source development.

The CONTRIBUTING.md explicitly outlines the requirements for schema changes – discussion and a migration script. Ignoring this guidance would violate project standards. Option A is correct because it directs Ben to fulfill these documented needs before further review can begin. Options B and D are premature; reviewing code without understanding the context or required steps is inefficient, and option C assumes Ben has already followed protocol.

The CONTRIBUTING.md mandates a concise summary and a link to the issue. Sarah's current description lacks these crucial elements. While brevity is valued, it cannot compromise clarity or traceability. Option A is incorrect because failing to meet the requirements means the PR may be rejected. Options B & D are too prescriptive – Sarah needs guidance on *how* to fulfill the requirement.

The CONTRIBUTING.md stresses proactive communication and issue creation *before* implementation. Creating an issue allows the team to understand the scope of the problem, offer assistance, and track progress effectively. While offering direct help might seem helpful initially, it bypasses the crucial step of formalizing the discussion and establishing a clear plan. Options A and D are inappropriate because they ignore established workflow.

The CONTRIBUTING.md mandates adherence to Conventional Commits, which includes a scope for each commit. This provides context and traceability within the project's history. Reminding David of this requirement ensures consistent commit practices and facilitates effective debugging and understanding of changes. Options A and C disregard the guidelines; D is overly disruptive.

The CONTRIBUTING.md's requirement for discussing features in issues *before* implementation is a core process for collaboration and risk mitigation. While Rohan's change might seem simple, adhering to this guideline ensures proper planning and communication within the team. Requesting he create an issue is the most constructive approach, promoting best practices without unnecessarily delaying progress. Options C and D are overly restrictive.

The CONTRIBUTING.md explicitly requires a link to the issue tracker ticket for all PRs. Option 1 directly addresses this requirement and provides constructive feedback. Options 2 and 3 ignore the guideline, while option 4 requests help that isn't needed – Mark should understand the process.

The CONTRIBUTING.md requires discussion in an issue before implementation. Tom's statement indicates he hasn't followed this process. Option 2 correctly identifies the missing step – initiating an issue allows for tracking progress and collaboration. Options 3 and 4 are irrelevant to the requirement.

The project's CONTRIBUTING.md explicitly requires a link to the issue tracker ticket in all PR descriptions. This ensures traceability and proper workflow management. Failing to adhere to these guidelines demonstrates a lack of understanding of the team's processes; therefore, immediately informing Maria is the correct response.

The CONTRIBUTING.md emphasizes the importance of pull requests for code review and tracking. Directly pushing to the main branch bypasses this process, increasing the risk of introducing bugs or inconsistencies. John's approach is a violation of established workflow best practices; therefore, explaining the benefits of pull requests is the most constructive action.