From d1d33d0268d086711460417bc666666e8952853d Mon Sep 17 00:00:00 2001 From: Anastassios Nanos Date: Sun, 19 Jul 2026 18:20:41 +0300 Subject: [PATCH 1/3] docs: Strengthen contribution rules for issues and PRs Following an increase of drive-by issues and PRs, mostly around mentorship program cycles, we should make the contribution rules more explicit: - Bug reports must come with actual logs and command output. Issues that only describe code the reporter has read get the needs-repro label and are closed if the information is not provided. - PRs are expected to reference an issue that a maintainer has labeled as accepted, except for trivial fixes. - Please do not @-mention maintainers right after opening an issue. - Mentorship-related work only counts on issues explicitly marked with the mentorship label. Signed-off-by: Anastassios Nanos --- docs/developer-guide/contribute.md | 41 +++++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) diff --git a/docs/developer-guide/contribute.md b/docs/developer-guide/contribute.md index 795c81b4e..ecd149c89 100644 --- a/docs/developer-guide/contribute.md +++ b/docs/developer-guide/contribute.md @@ -59,6 +59,18 @@ welcome to open a new issue, which is either related to a bug or a request for a new feature. Please make sure to read the [LLM policy](../developer-guide/llm-policy.md) in cases where an LLM has been used. +Please keep in mind that `urunc` is a community-led open-source project, not +backed by a specific company. Maintainers review issues on a best-effort basis. +Therefore, please refrain from @-mentioning maintainers when opening an issue +or shortly after opening it. The maintainers will get to the issue as soon as +they can. + +When a maintainer reviews an issue, they will label it accordingly. In +particular, issues that describe an actual, reproduced problem or an agreed +change get the `accepted` label. Issues that lack the necessary information to +reproduce or verify the reported problem get the `needs-repro` label and will +be closed if the information is not provided. + ### Reporting bugs In order to report a bug or misbehavior in `urunc`, a user can open a new issue explaining the problem. @@ -76,6 +88,16 @@ In that context, when opening a new issue regarding a bug, we kindly ask you to: 5. Any particular steps to reproduce the issue. - Keep an eye on the issue for possible questions from the maintainers. +Bug reports must describe a problem that the reporter has actually run into +and reproduced. In that context, the logs and the output of the failing +commands are required, not optional -- they are the evidence that the problem +is real. Issues that only describe code the reporter has read, without +executing it and without the respective output, will be labeled `needs-repro` +and closed if the missing information is not provided. Observations from +reading the code (eg. dead code, TODOs, style issues) are better suited for a +comment in a relevant issue or a discussion, rather than a standalone bug +report. + A template for an issue could be the following one: ``` ## Description @@ -90,6 +112,10 @@ An explanation of the issue ## Steps to reproduce A list of steps that can reproduce the issue. + +## Logs / output +The actual output of the failing commands and the relevant logs +(eg. containerd logs, urunc debug logs). ``` ### Requesting new features @@ -105,7 +131,10 @@ Anyone should feel free to submit a change or an addition to the codebase of `ur Currently, we use GitHub's Pull Requests (PRs) to submit changes to `urunc`'s codebase. Before creating a new PR, please follow the rules below: -- Avoid opening PRs for non-existent issues. Please create an issue first. +- Open PRs only for issues that a maintainer has labeled as `accepted`. If + there is no issue for the change you have in mind, please open one first and + wait for the maintainers to review it. Trivial fixes (eg. typos in the + documentation) are exempt from this rule. - Complete the PR template. - In case LLMs have been used, please read the [LLM policy](../developer-guide/llm-policy.md). @@ -124,6 +153,16 @@ The maintainers and admins of the `urunc` project reserve the right to close PRs that do not comply with the above rules, with reference to this contribution guide. +### A note on mentorship programs + +We are always happy to see new contributors, including people who want to get +involved through mentorship programs (eg. LFX). However, opening issues or PRs +does not confer any standing in mentorship applications. If `urunc` +participates in a mentorship term, the relevant issues will be explicitly +marked with a `mentorship` label. Please avoid opening issues or PRs with the +sole purpose of increasing your contribution count -- it takes time away from +the maintainers and does not help your application either. + A new (draft) PR triggers the following process: 1. A maintainer will check the PR and apply the `ok-to-test` label. This will From 8c9effc24113db0066d0f662e18f980102d2c455 Mon Sep 17 00:00:00 2001 From: Anastassios Nanos Date: Sun, 19 Jul 2026 18:20:55 +0300 Subject: [PATCH 2/3] ci: Exempt maintainer-triaged items from the stale bot At the moment the stale bot marks and closes issues that maintainers have already confirmed, while unverified reports sit in the queue unaffected. Exempt the accepted, confirmed and mentorship labels for issues, and PRs that a maintainer has engaged with (ok-to-test, takeover, accepted). Unlabeled items, eg. reports pending the needs-repro information, keep the current 60+15 day cycle. Signed-off-by: Anastassios Nanos --- .github/workflows/stale.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 7f94329ba..cff2a97bd 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -29,4 +29,5 @@ jobs: days-before-pr-stale: 60 days-before-issue-close: 15 days-before-pr-close: 15 - exempt-issue-labels: 'design,dev,enhancement,documentation,bug,feature' + exempt-issue-labels: 'design,dev,enhancement,documentation,bug,feature,accepted,confirmed,mentorship' + exempt-pr-labels: 'ok-to-test,takeover,accepted' From a4c778e59c5f3f4583f2fd8af6d9bf183b847191 Mon Sep 17 00:00:00 2001 From: Anastassios Nanos Date: Sun, 19 Jul 2026 18:21:18 +0300 Subject: [PATCH 3/3] ci: Fail the build and unit test workflows on errors The build and unit-test jobs run with a job-level continue-on-error, so a PR shows a green check even when it does not compile or its tests fail. For instance, the branch of an open PR currently fails to build, while its checks appear green. Remove the flag so that CI failures are visible in the PR checks. The build-latest and upload_s3 workflows are left untouched, as they do not gate PRs. Fixes: #729 Signed-off-by: Anastassios Nanos --- .github/workflows/build.yml | 1 - .github/workflows/unit_test.yml | 1 - 2 files changed, 2 deletions(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 318740b59..a7a187a41 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -31,7 +31,6 @@ jobs: runner: ubuntu-22.04 - arch: arm64 runner: ubuntu-22.04-arm - continue-on-error: true steps: - name: Harden the runner (Audit all outbound calls) diff --git a/.github/workflows/unit_test.yml b/.github/workflows/unit_test.yml index 20381282c..b40aa24fe 100644 --- a/.github/workflows/unit_test.yml +++ b/.github/workflows/unit_test.yml @@ -28,7 +28,6 @@ jobs: runner: ubuntu-22.04-arm fail-fast: false - continue-on-error: true steps: - name: Harden the runner (Audit all outbound calls)