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.