Automattic / Automattic/harper

Detecting Passive Voice

Open
#1,500 7 comments 8 reactions 0 assignees View on GitHub
enhancement grammar harper-core linting
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.