Dangling Modifiers

What went wrong: "Having reviewed the pull request" is a participial phrase — it must describe the subject of the main clause. In the original, that subject is "the bug," which cannot review a pull request. The modifier is "dangling" because its implied subject (whoever reviewed the PR) is absent. Fix rule: make the implied actor the subject of the main clause. Option B: "we found" — the subject "we" is the entity that reviewed the PR. The modifier now correctly attaches to a subject capable of the described action. Option A (passive rewrite): avoids the dangling modifier but creates a different sentence structure where the timing relationship is less explicit. Both A and B are grammatically correct; B is the more precise fix because it uses active voice and makes the reviewing agent explicit. Option C creates a new error: "having been reviewed" makes the bug the thing that was reviewed — which makes no sense in context. Option D is a sentence fragment (no main clause). Pattern to remember: The subject immediately after the participial phrase must be able to perform the action in the phrase. "Having deployed the patch, the server was restarted" → "Having deployed the patch, the team restarted the server." "Using the API, the data is fetched" → "Using the API, the client fetches the data."

What went wrong: "After testing the new feature" implies that someone tested it — and the subject of the main clause should be that someone. In the original, the subject is "several edge cases," which cannot test a feature. The QA team is buried in a passive by-phrase at the end. Fix (Option A): move "the QA team" to subject position directly after the introductory phrase. Now the modifier correctly modifies "the QA team." This also converts the passive ("were discovered by the QA team") to active ("the QA team discovered"), which is more direct. Option B is grammatically correct but uses passive voice and loses the explicit agent (QA team). This is acceptable in technical writing where the agent is unimportant, but Option A is stronger. Option C attaches the introductory modifier to "the QA team" correctly, but the phrase "after having been tested" makes the QA team the thing that was tested — wrong. Option D still has the dangling modifier: "Testing the new feature" still cannot modify "several edge cases." Release note writing tip: in technical documentation, identify the agent of each action. If you use passive voice, be deliberate: passive is appropriate when the agent is unknown or unimportant. When the agent is known (the QA team), active voice is clearer: "The QA team discovered..."

What went wrong: "While monitoring the system logs" is a participial phrase that should describe the subject of the main clause. "An unexpected memory spike" cannot monitor logs — the implied actor is the team or engineer. Fix (Option A): introduce "we" as the subject, which is the entity doing the monitoring. Active and clear. Option B: a grammatically correct passive construction that avoids the dangling modifier. Both A and B are acceptable in technical writing; A is preferred for postmortems because it is more direct and assigns clear ownership. Option C is a sentence fragment — "observed" without an auxiliary verb ("was observed") makes it ungrammatical. Option D: "having been observed" makes the memory spike the thing observing — circular and incorrect. Postmortem writing principle: postmortem reports should be written in clear, active first-person plural ("we," "the team") to establish shared ownership and avoid implicit blame. "We observed," "We identified," "We escalated" are all stronger than passive equivalents in this context. Passive voice is appropriate for process descriptions ("logs were archived at midnight") but less so for incident timelines where agency matters.

What went wrong: "By analysing the sprint velocity" requires a human agent as the subject — someone or a team performed the analysis. "The delivery date" cannot analyse velocity. The modifier dangles. Fix (Option A): "we revised" — a human subject who can perform the analysis. Option B: "the end of Q3 became the revised delivery date" — still lacks an explicit human agent after the modifier, though "the end of Q3" is at least a logical result. Grammatically awkward and less precise. Option C: rearranges the sentence so the modifier is no longer introductory, avoiding the dangling issue, but the sentence is harder to read and the agent (who did the analysis?) is still absent. This is acceptable in contexts where the agent is understood, but weaker in a status update. Option D: "Analysing the sprint velocity revised the date" — this personifies an action (analysing) as the agent, which reads unnaturally. Management writing tip: in status updates and business correspondence, use "we" or name the team explicitly. This makes accountability clear and reads as confident rather than evasive. "We revised the delivery date" is clearer and more professional than "the delivery date was revised."

What went wrong: "To authenticate successfully" is an infinitive phrase that functions as a modifier — it implies an agent who wants to authenticate. "A valid API key" cannot authenticate. The modifier is dangling. Fix (Option A): "the client must include" — the client is the entity trying to authenticate. The infinitive phrase now correctly modifies "the client." Option B: "including a valid API key...is required" — the gerund phrase introduces a new structural issue (the infinitive phrase "to authenticate" now modifies the gerund "including," which is awkward) and adds a weak passive ("is required"). Option C: "every request must include" — this is a common shorthand in API docs and avoids naming a specific actor. It's grammatically acceptable in technical documentation where brevity is valued. However, Option A is more precise: the request is the vehicle, but the client is the agent authenticating. Option D: incorrect — the original is a dangling modifier. API documentation style note: in technical docs, you have a choice of subject: "the client," "you," or the technical noun ("the request"). The convention varies by style guide. Google Developer Documentation Style Guide uses second person ("you must include"). Microsoft Writing Style Guide also prefers "you." For developer-facing docs, "Include a valid API key in every request" (imperative) is the most direct form.

Analysis: "Once deployed to production" is a participial phrase. Its implied subject is the entity being deployed — the service or application, not the engineers. However, the grammatical subject of the main clause is "engineers," who cannot be deployed to production. This is a dangling modifier. Fix (Option A): convert the participial phrase to a full subordinate clause: "Once the service is deployed to production." The subordinate clause has its own explicit subject ("the service"), so no dangling modifier is possible. The main clause ("engineers should monitor...") now has a clear, independent subject. This is a clean and readable fix. Option B restructures using passive voice — "error rates should be monitored by engineers" — which is grammatically correct but weaker (passive, agent buried at the end). Option C is wrong: "deployed" cannot correctly modify "engineers" unless the engineers are the ones being deployed, which is not the meaning. Option D: "Deployed to production, engineers should monitor..." — removes "once" without fixing the core issue. Runbook writing principle: in operational documentation (runbooks, playbooks, incident response guides), use precise subjects. Replace "Once deployed" with "Once the service is deployed" or "After the deployment completes." The reader — often under pressure during an incident — should never have to infer what the modifier refers to.