Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions .github/ISSUE_TEMPLATE/rule_request.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
name: Rules database entry
about: Tell us about a cache or artifact directory Diskern doesn't know yet
labels: rules, enhancement
---

<!-- Diskern only knows what its rules tell it. If you know where an app
on your platform keeps its regenerable files, that's a rule nobody
else can write as well as you — and it needs no Rust.
Format and reasoning: docs/RULES.md -->

**Which application, and on which OS?**

<!-- e.g. "VS Code on macOS", "Docker on Linux" -->


**Where does it keep the files?**

<!-- The full path, with the user-specific parts marked:
~/Library/Application Support/Code/CachedData
C:\Users\<user>\AppData\Local\<app>\Cache -->


**What's in there, and what happens after it's removed?**

<!-- What regenerates it, and what the user loses in the meantime —
"rebuilt on next launch, first launch is slower" is exactly right. -->


**Proposed verdict**

<!-- safe = regenerable, removal affects nothing
review = probably reclaimable, but the user should look first
Prefer review when unsure. A wrong `safe` offers to move real data. -->

- [ ] `safe`
- [ ] `review`
- [ ] not sure

**Is there anything nearby that must NOT match?**

<!-- The trap this database exists to avoid: a Firefox profile holds
cache2/ next to logins.json and cookies.sqlite, so the rule has to
name the cache directory, not the profile. Anything similar here? -->


**Would you like to open the PR yourself?**

<!-- Happy either way. The rules are JSON in
crates/diskern-core/rules/base.json and adding one is a few lines. -->
29 changes: 26 additions & 3 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,13 +46,36 @@ verdict levels and the safety reasoning are in
[`crates/diskern-core/rules/base.json`](crates/diskern-core/rules/base.json),
and adding one needs no Rust.

**Issues labelled `good first issue`** are scoped to a single file with
the reasoning already worked out.

**Documentation.** If something here or in `docs/` was wrong or missing
when you followed it, that is a bug report worth filing even if you
don't fix it.

### Picking an issue

Open issues carry a difficulty label, so you can choose by how much of
the codebase you need to hold in your head at once:

| Label | What it means |
| --- | --- |
| [`level: beginner`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+beginner%22) | Scoped to one file, with the reasoning already worked out — a rule, a flag, a formatting fix. |
| [`level: intermediate`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+intermediate%22) | Sits inside one crate and has to be tested against it — a stage in the report pipeline, a test harness. |
| [`level: advanced`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+advanced%22) | Cross-cutting, or lands on a safety guarantee. Say what you're planning on the issue before you start. |

Most `level: beginner` issues are also labelled
[`good first issue`](https://github.com/Coding-Moves/diskern/labels/good%20first%20issue);
[`help wanted`](https://github.com/Coding-Moves/diskern/labels/help%20wanted)
means we'd particularly like someone to take it.

The rest of the labels say where a change lands rather than how hard it
is. `engine`, `cli` and `app` name the crate; `backend` and `frontend`
are the same split in broader terms; `rules`, `safety`, `ui/ux`, `ci`,
`testing`, `performance` and `documentation` name the concern.
`priority: high` means correctness or safety, not a deadline.

Comment on the issue before you start, so two people don't write the
same patch. If nothing fits, opening an issue to describe what you want
to change is a fine first contribution on its own.

## The loop

1. Fork, and branch from `main`. Branch names follow the commit prefixes
Expand Down
6 changes: 6 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,12 @@ Contributions are welcome — see [CONTRIBUTING.md](CONTRIBUTING.md) for
setup and guidelines, and [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md)
for how the pieces fit together.

Looking for somewhere to start? Issues are labelled by difficulty:
[`level: beginner`](https://github.com/Coding-Moves/diskern/issues?q=is%3Aopen+label%3A%22level%3A+beginner%22)
is scoped to a single file with the reasoning worked out, and teaching
Diskern about a cache on your platform is a
[rules change](docs/RULES.md) that needs no Rust at all.

## License

[MIT](LICENSE). Unless you explicitly state otherwise, any contribution
Expand Down
5 changes: 5 additions & 0 deletions docs/RULES.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,3 +95,8 @@ rules PRs are very welcome. Guidelines:
not), what happens after removal.
4. Add a test in [`rules.rs`](../crates/diskern-core/src/rules.rs) if the
rule protects something critical.

Don't want to write the JSON? Filing a
[rules database entry](https://github.com/Coding-Moves/diskern/issues/new?template=rule_request.md)
with the path and what regenerates it is just as useful — someone else
can turn it into a rule from there.
Loading