chore: Strengthen contribution rules and triage infra

.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)

.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'

.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)

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