Quiz — Chapter 23: Collaborative Writing

Target: 70%+ before moving on. Answers are hidden — commit to yours before expanding.

Section 1 — Multiple Choice

1. A "Frankenstein document" is best described as:

  • A) A document that is too long for its audience
  • B) A multi-author document stitched from mismatched parts, with visible seams
  • C) A document written entirely by one person under deadline pressure
  • D) Any document that uses track changes
Answer **B.** A Frankenstein document is assembled from sections that each work alone but were never integrated — mismatched voice, inconsistent terms, structural seams, contradictions, redundancy (§23.1). It's specifically a *collaborative* failure. (A) is an audience problem, (C) is solo writing, (D) is a tool. The defining feature is the visible seam between parts that no one fused.

2. What is the single most reliable predictor of whether a multi-author document turns out well?

  • A) The number of reviewers
  • B) Whether the team used premium collaboration software
  • C) Whether one person was unambiguously accountable for the whole
  • D) How early the team started
Answer **C.** A document owned by everyone is owned by no one (§23.2). The single document owner runs the integration pass, enforces the style guide, and arbitrates conflicts. (A) more reviewers without an owner makes things *worse*; (B) the tool is the stage, not the performance (§23.8); (D) helps but doesn't substitute for ownership.

3. The correct grain for dividing collaborative writing is:

  • A) By sentence — two people co-write each paragraph
  • B) By section — each section has one accountable author
  • C) By word count — split the page count evenly regardless of expertise
  • D) There is no good way to divide writing
Answer **B.** Split by section, not finer (§23.2). A section is a coherent chunk with a single job; below that, writing is a solo act and shared authorship produces mush no one owns. Match each section to the person who knows the content, not to seniority or availability.

4. When does "git for docs" (Markdown in a repository) become the wrong choice?

  • A) When the documentation lives alongside code
  • B) When you want a full attributed history
  • C) When non-technical people must contribute to the document
  • D) When contributors are comfortable with branches and pull requests
Answer **C.** Git for docs requires fluency with git and plain-text formats, which excludes most non-technical collaborators — you wouldn't ask a VP of Marketing to open a pull request (§23.3, §23.8). (A), (B), and (D) are all situations where git *shines*: docs-with-code, attributed history, technical contributors. The trade-off is sharp and is about *who* must contribute.

5. The shared parts of a multi-author document — the executive summary, the intro, the transitions — should be written:

  • A) First, so they set direction for the section authors
  • B) By committee, so everyone has input
  • C) Last, by the document owner, after the sections exist
  • D) By whoever finishes their section first
Answer **C.** Anything that depends on the *whole* must wait for the whole (§23.2). The chapter's opening disaster was an executive summary written first that summarized a plan which then changed. The owner writes the seams and summaries last, after the sections land. (A) guarantees the summary describes a plan that no longer exists.

6. During the review phase of a document, everyone should:

  • A) Edit the document directly to save time
  • B) Use suggesting mode / track changes so edits are visible and approvable
  • C) Email their changes as separate attachments
  • D) Wait for the owner to ask before commenting
Answer **B.** Once a document enters review, all edits should be visible, attributed, and approvable one by one (§23.3). Editing directly during review is a classic sin: the owner can't see what changed and either re-reads everything or accepts blind. This applies to *everyone*, including senior people who "just fixed a couple of things."

7. The "integration pass" is:

  • A) The step where each author edits their own section one more time
  • B) One person reading the whole document to make it read as one voice
  • C) The automated merge a tool performs when sections are submitted
  • D) A meeting where the team reads the document aloud together
Answer **B.** The integration pass is a single reader-editor unifying voice and terminology, smoothing seams, hunting contradictions, and cutting redundancy across the whole document (§23.5). It's the multi-author cousin of [Chapter 12](../../part-02-building-blocks/chapter-12-editing-and-revision/index.md)'s editing hierarchy. No tool can do it (it requires judgment about meaning and voice), and it's not the same as each author self-editing in isolation.

8. The right response to conflicting feedback from multiple reviewers is to:

  • A) Apply every reviewer's changes to satisfy everyone
  • B) Apply changes live as each reviewer submits them
  • C) Average opposite notes to find a compromise
  • D) Decide by judgment — classify each conflict and resolve by evidence, audience, or role
Answer **D.** Conflicting feedback is decisions to make, not commands to obey (§23.7). Collect all of it first; classify each conflict (fact → evidence, judgment → audience/purpose, authority → role); decide and log it. (A) is impossible when notes are mutually exclusive; (B) causes ping-pong; (C) averaging produces self-canceling mush ("strongly recommend tentatively considering").

9. A "conflict of judgment" between two reviewers (e.g., softer vs. stronger recommendation) is best resolved by:

  • A) Finding which reviewer has the most seniority
  • B) The document's audience and purpose
  • C) Counting how many other reviewers agree with each
  • D) Keeping both versions in the document
Answer **B.** A judgment conflict is decided by *who the document is for and what it's trying to do* — [Chapter 2](../../part-01-writing-is-thinking/chapter-02-audience/index.md)'s question (§23.7). A softer recommendation may serve a skeptical board; a stronger one serves an action-oriented exec. The audience breaks the tie. Contrast: a conflict of *fact* is decided by evidence; a conflict of *authority* is decided by role.

10. A short style guide for a collaborative document should primarily contain:

  • A) Every grammar rule in the language, for completeness
  • B) The handful of choices that actually diverge across authors — terms, voice, person/tense, numbers, dates
  • C) Only the company logo and color palette
  • D) A detailed history of past style decisions
Answer **B.** A useful style guide is short — one or two pages — and answers only the questions that actually come up (§23.4). A 38-page guide is one nobody reads, and an unread guide enforces nothing. The goal isn't completeness; it's *adherence*, which scales inversely with length.

11. "Review" and "approval" differ in that:

  • A) They are two words for the same step
  • B) Review is feedback (advisory, many people); approval is authority (a yes/no gate, few named people)
  • C) Approval happens before review
  • D) Only the document owner can do either
Answer **B.** Review is advisory — reviewers suggest, they don't decide what ships. Approval is a formal yes/no gate, often required by role (legal approves external claims; a director approves a budget) (§23.6). Confusing them produces the document where fifteen people think they have veto power. A lightweight RACI keeps them straight.

Section 2 — True/False with Justification

State true or false and explain why in one sentence.

T1. "Everyone's section is in, so the document is done."

Answer **False.** That means *drafting* is done; the hardest, most valuable work — the integration pass that makes the sections read as one document — hasn't started (§23.1, §23.5). A pile of sections is raw material, not a finished document.

T2. When two reviewers give you directly opposite feedback, you have failed to communicate the document's goal clearly enough, and the fix is to satisfy both.

Answer **False.** Opposite feedback is normal and often unavoidable — reasonable people prefer different things — and satisfying both is literally impossible when the notes are mutually exclusive; the job is to *decide* by judgment, not to obey both (§23.7).

T3. The document owner should be the most senior person on the team.

Answer **False.** Seniority makes a slow, conflicted integrator — too busy for the line-by-line work, too political to overrule peers' prose (§23.2). The owner should be the cleanest writer with the time and the detail-orientation, given explicit authority by the senior sponsor.

T4. A merge conflict in git is a flaw in the tool that better software would resolve automatically.

Answer **False.** When two people change the same line to say incompatible things, no algorithm can know which is correct — the conflict is *semantic*, and git's refusal to guess (forcing a human to decide) is a feature, not a bug (§23.3). Tools can display conflicts; they can't resolve disagreements about meaning.

T5. In the integration pass, "find-and-replace" can help enforce one term per concept across all authors' sections.

Answer **True** (used carefully) — replacing "user" → "customer" and "the system" → "the platform" throughout is exactly integration move 2, enforcing [Chapter 7](../../part-02-building-blocks/chapter-07-word-choice-tone-voice/index.md)'s one-term-per-concept rule across a team (§23.5); the caution is to review each replacement so you don't change a term inside a quotation or a different meaning.

Section 3 — Short Answer

S1. Name the five failures that characterize a Frankenstein document.

Model answer + rubric Voice/tone mismatch; terminology inconsistency; structural seams (sections that don't connect, overlap, or leave gaps); contradiction (incompatible facts across sections); redundancy (the same background/term/caveat repeated by multiple authors). *Rubric:* all five named = full marks; the most-missed one is usually "redundancy" or "structural seams."

S2. List the five moves of the integration pass and the Frankenstein failure each one cures.

Model answer + rubric (1) Unify the voice → cures voice/tone mismatch; (2) unify the terminology → cures terminology inconsistency; (3) smooth the seams → cures structural seams; (4) hunt contradictions → cures contradiction; (5) cut redundancy → cures redundancy (§23.5). *Rubric:* each move correctly paired with its failure = full marks.

S3. A document is stalling in review: it's been out to twelve people for eleven days with no deadline, edits arriving by email, Slack, and direct editing. Name three process fixes from §23.6.

Model answer + rubric Any three of: separate reviewers from approvers (one-line RACI); set a deadline and a default ("comments by Wednesday EOD; silence is assent"); use one shared doc with suggesting mode (not email/Slack/direct edits); review big things before small things; collect all comments then reconcile in one pass; send a clean version to named approvers with an explicit yes/no ask. *Rubric:* three valid, distinct fixes = full marks.

Section 4 — Applied Scenario

AS1. Three authors submitted these raw sentences for a one-paragraph status update. Integrate them into a single, one-voice paragraph (3–5 sentences), keeping every real fact, reconciling the apparent contradiction, and calibrating the certainty:

Author A (eng): "Backend migration is done ahead of schedule." Author B (QA, over-hedged): "It would perhaps be premature to assert with confidence that the system is fully ready, as some additional verification may conceivably be warranted." Author C (PM, breezy): "We're 100% good to launch Tuesday. Zero issues. Ship it."

Model answer + rubric *Model (one good version):* "The backend migration is complete, ahead of schedule. The system passed our verification so far with no issues found, and one final check is scheduled before Tuesday's launch. Pending that check, we expect to launch on schedule." *Rubric (0–2 each):* **one voice** (no audible seam between A, B, C); **contradiction reconciled** (B's "more verification needed" + C's "zero issues, ready" become "passed so far, one check pending" — both true); **certainty calibrated** (confident about what's done, honest about the pending check — neither fog nor breeziness); **filler cut** ("100%", "zero issues", the hedge-stack removed); **fact kept** (Tuesday launch, migration done, ahead of schedule). 8–10 = strong integration; below 6 = you smoothed the prose but left a seam or a contradiction.

Scoring & Next Steps

Score What it means Do this
< 50% Core ideas not yet solid Re-read §23.1 (Frankenstein failures), §23.2 (ownership/division), and §23.5 (integration pass). Redo Section 1.
50–70% Mechanics understood, application shaky Redo Exercises Part B and the C1 harmonization task; focus on §23.5 and §23.7.
70–85% Solid working grasp Proceed to Chapter 24. Skim the FAQ once more.
> 85% Strong command Try Exercises Part E (run a real collaboration end to end) and the Deep Dive.