Automattic / Automattic/harper
Need to (carefully) flag "after fact" instead of "after the fact"
- Dominant language
- Rust
- Stars
- 15.4k
- Forks
- 627
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 106
Description
I just read this on Hacker News:
> While on UNIX they were added **after fact**, and to this day there are gotchas mixing posix threads with signals, fork and exec.
"after fact" should be "after the fact"
But the potential for false positives is quite high.
Real mistakes that should be flagged:
- Their whole reasoning just feels like justification **after fact**.
- Modifying them **after fact** doesn't sound like a good idea.
- If you want to change the grid options **after fact**, you can do that via the grid
- How add another field to Translated model **after fact**?
- Anyway, the suggested code verifies **after fact** if the connection is getting ...
- I edited this **after fact** and it was recently accepted.
Legitimate uses that should not be flagged:
- Add negative tests **after fact** deletion
- This is after the whole catalog has been built, and long **after fact** evaluation.
- Graph persistence happens in a separate transaction **after fact** writes complete.
- Rerun rules **after fact** is updated
- A Java exception occurs **after fact** gathering.
- Triggered daily **after fact** extraction
Contributor guide
Research direction
Start by locating the existing grammar rules and their tests for phrase-level corrections. Compare the reported mistaken and legitimate uses, then verify that the rule flags the standalone "after fact" cases without matching the listed contexts. Done means the intended examples are covered and the false-positive examples remain accepted.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100