From f2f0b4ee728a7505d2b0556f924686220f857a2a Mon Sep 17 00:00:00 2001 From: "Rene D. Obermueller" Date: Sun, 30 Nov 2025 22:17:02 +0100 Subject: [PATCH 1/2] Contributions: clarify requirements to PRs --- .github/pull_request_template.md | 25 +++++++++++++++++++++++++ CONTRIBUTING.md | 21 +++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 .github/pull_request_template.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 00000000..b7af219e --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,25 @@ + + + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index af7c5c97..7218cfa7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,15 +3,36 @@ CONTRIBUTING Contributions are welcome. Satty is not able to evolve without relying on its contributors and their contributions. +We're always looking for and grateful about help with e.g. documentation/README, PRs, PR reviews, FAQ or other wiki entries. + This documents tries to reduce friction when it comes to contributions by defining some guidelines, some of which may follow a rationale while others are arbitrary determinations. Please note that opening a PR or even just an issue may expose your work to pertinent discussion regarding code quality, Satty's scope and these guidelines, and possibly things we haven't yet thought of. This isn't meant as discouragement, just as a heads-up. +Issues for bugs or feature requests +-- + +Bug reports and ideas for Satty are valuable contributions. But please take the time to search for existing issues. + Issue first, then PR -- The issue should state what is missing from or broken in Satty. All the discussion around whether a feature is in scope, or a behaviour is a bug can take place there. A related PR is then just about correctness of a fix or feature implementation. This ensures that a specific feature or fix is actually wanted. +Commits and PRs +-- + +- We don't squash the commits in a PR. If you feel that some commits are temporary in nature, please squash them yourself, otherwise they will show up in commit history after we merge the PR. +- If github indicates conflicts, please rebase your branch instead of merging upstream changes. We know that having to rebase sucks, so we're doing our best to point out where conflicts may arise even in advance, but sometimes conflicts are inevitable. We're happy to assist with rebasing, just say the word. +- Please make sure that all commits in a non-draft PR compile, this helps `git bisect`. +- The first commit in a PR and the PR itself should use a conventional commit message. +- PRs should not break existing config or disrupt existing user workflows. But if there are potential surprises, please add a "!" for attention, e.g. "fix!", "feat!", and provide a small section that may be included in the release notes. + +Milestones +-- + +We use these to indicate which issues and/or PRs we'd ideally like to include with the next release. This doesn't mean any pressure, or that there's any deadline. + 3rd party crates -- From 3f409fb853136917d01a5102c00b5cdddba0cf6f Mon Sep 17 00:00:00 2001 From: "Rene D. Obermueller" Date: Fri, 13 Mar 2026 20:27:57 +0100 Subject: [PATCH 2/2] pr 351: rephrase LLM usage --- .github/pull_request_template.md | 5 ++++- CONTRIBUTING.md | 17 ++++++++++------- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index b7af219e..c743de00 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -9,11 +9,14 @@ - please make sure all commits compile - please use conventional commit messages at least for the first commit and PR - please avoid breaking configuration or disrupting existing user workflows - - In case of potential surprises, + - in case of potential surprises, - please add a "!" for attention, e.g. "fix!", "feat!" - provide a small section that may be included in the release notes. - if there are conflicts, please rebase your branch onto main rather than merge main into your branch - git rebase /main + - if you used LLM/Generative AI help + - please say that you did + - you vouch for the code - if in doubt, ask us, we're happy to help --> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7218cfa7..c40842c7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -69,12 +69,15 @@ Command line parameters changes Please include anticipated next version in the comment for command line arguments, especially when adding arguments or options. You can use the placeholder `NEXTRELEASE` in `command_line.rs`, `configuration.rs` and `README.md`. -GenAI usage +LLM/Generative AI usage -- -GenAI usage is tempting and can save time, but it's not without pitfalls. At this point in time, full vibe coding mode can and often does lead to bad quality code which we are not going to merge. - -When using GenAI in the context of Satty PRs, please make sure that -- any generated code can actually be licensed under Satty's license, i.e. doesn't violate existing intellectual property -- any generated code actually does what it claims it does -- you have a technical understanding of how the generated code works and you (not the GenAI) can explain it in detail +LLM usage is tempting and can save time, but it's not without pitfalls. Quality of results may depend on the model as well as the prompt, and even then it can go wrong. When using LLM help in the context of +- Satty PRs + - please disclose LLM usage, this can be important for downstream packages as well as for reviewers so they know what to look for + - you vouch for the submitted code, i.e. + - it does what the PR text says it does + - it can be licensed under Satty's license and doesn't violate existing intellectual property + - you have a technical understanding of it +- Satty bug reports + - please make sure the bug actually exists