Automattic / Automattic/harper
Detecting Passive Voice
- Dominant language
- Rust
- Stars
- 15.4k
- Forks
- 627
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 102
Description
## Description
Add detection for [passive voice](https://en.wikipedia.org/wiki/Passive_voice)
## Resources
Matt Might has a [bash script](https://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/) for detecting passive voice that is pretty comprehensive.
## Examples
```
The passive voice is bad when it hides relevant or explanatory information:
Bad: Termination is guaranteed on any input.
Better: Termination is guaranteed on any input by a finite state-space.
OK: A finite state-space guarantees termination on any input.
In the first sentence, the passive hides relevant information.
The second sentence includes the relevant information, but the passive misplaces the emphasis.
The third sentence contains all the relevant information, and it feels crisp.
```
See the bash script for additional example words to check.
## Potential False Positives
```
There's one case where I think the passive is preferrable in technical writing--when the subject is truly irrelevant:
OK: 4 mL HCl were added to the solution.
Even in this example, I personally don't believe it's egregious to use we:
OK (to me): We added 4 mL HCl to the solution.
In summary, for each use of the passive highlighted by my script, ask the following questions:
Is the agent relevant yet unclear?
Does the text read better with the sentence in the active?
If the answer to both questions is "yes," then change to the active.
If only the answer to the first question is "yes," then specify the agent. ```
Contributor guide
Research direction
No repository files or tests are named in the issue. Start by reading the linked bash script and locating Harper’s existing grammar-detection entry points; use the supplied passive-voice examples and false-positive guidance to define coverage. Done means passive constructions are detected with appropriate tests for the listed acceptable cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100