[docs] Contributing guidelines: how to select valid issues

Author: nemesifier

developer/contributing.rst

@@ -5,12 +5,10 @@ We are glad and thankful that you want to contribute to OpenWISP.
 
 .. warning::
 
-    Contributions which shift the burden of understanding, implementation,
-    testing, and review entirely onto maintainers are not acceptable. This
-    includes abusing AI tools to generate pull requests which the
-    contributor does not fully understand, explain, maintain, and test.
-    Please read the :ref:`Anti AI Spam Policy <anti_spam_policy>` before
-    opening a pull request.
+    AI assisted contributions which shift the burden of understanding,
+    implementation, testing, and review entirely onto maintainers are not
+    acceptable. Please read the :ref:`Anti AI Spam Policy
+    <anti_spam_policy>` before opening a pull request.
 
 **Table of Contents:**
 
@@ -29,6 +27,8 @@ use `the development channel
 channels share feedback, share your OpenWISP derivative work, ask
 questions or announce your intentions.
 
+.. _openwisp_look_for_open_issues:
+
 Look for open issues
 --------------------
 
@@ -46,8 +46,22 @@ If there's anything you don't understand regarding the board or a specific
 github issue, don't hesitate to ask questions in our `dev channel
 <https://matrix.to/#/#openwisp_development:gitter.im>`_.
 
-**You don't need to wait for the issue to be assigned to you.** Just check
-if there is anyone else actively working on it (e.g.: an open pull request
+New or occasional contributors must verify that **the issue has been
+validated by maintainers** before opening a pull request.
+
+This also applies to issues you opened yourself: **wait until a maintainer
+has acknowledged and validated the issue before opening a pull request for
+it**.
+
+In OpenWISP, **an issue is considered validated when it has any issue
+label** except ``invalid`` or ``wontfix``.
+
+**Some issues are not suited to beginners**. These are clearly marked with
+a prominent warning at the beginning and must be avoided by beginners.
+
+**If the issue has already been validated by a maintainer, you don't need
+to wait for it to be assigned to you before working on it.** Just check if
+there is anyone else actively working on it (e.g.: an open pull request
 with recent activity). If nobody else is actively working on it, **just
 announce your intention to work on it by leaving a comment in the issue**.
 

general/code-of-conduct.rst

@@ -15,21 +15,33 @@ impact of their changes.
 Contributions which shift the burden of understanding, implementation,
 testing, and review entirely onto maintainers are harmful to the project.
 This includes AI abuse: using AI coding agents, chatbots, or other
-automation to generate pull requests without adequate human understanding,
-verification, and testing.
+automation to generate issues or pull requests without adequate human
+understanding, verification, and testing.
 
 AI tools do not turn an inexperienced person into an experienced software
 developer. Contributors are responsible for understanding the project, the
 issue, and every change they submit. If a contributor cannot explain,
 maintain, and properly test the code they are proposing, they should not
 open a pull request.
 
-Maintainers reserve the right to close pull requests considered spammy or
-harmful to the project, including but not limited to:
-
+The same applies to issues. Opening AI-generated issues based on
+superficial code smells, automated scans, or generic suggestions without
+real project understanding or user impact creates noise and wastes
+maintainer time. Artificial workflows in which a contributor uses AI to
+find a minor or questionable issue, opens it, and immediately opens a pull
+request for it are considered spam when they provide little or no value to
+the project.
+
+Maintainers reserve the right to close issues and pull requests considered
+spammy or harmful to the project, including but not limited to:
+
+- issues generated by AI tools or automation without real user impact,
+  project understanding, or meaningful investigation;
+- artificial issue-to-pull-request workflows created mainly to score
+  contributions rather than solve a validated project need;
 - unsolicited pull requests which do not have a related issue;
 - pull requests targeting issues which have not been opened, acknowledged,
-  validated, or accepted by maintainers;
+  or :ref:`validated by maintainers <openwisp_look_for_open_issues>`;
 - pull requests with poor, incomplete, or untested implementations;
 - pull requests generated by AI tools or automation without enough human
   understanding, review, and testing;
@@ -45,5 +57,5 @@ Maintainers may temporarily limit contributions from contributors who
 violate this policy. Contributors who continue violating this policy after
 a temporary restriction may be banned permanently.
 
-When a pull request or contribution is closed under this policy,
+When an issue, pull request, or contribution is closed under this policy,
 maintainers may provide only a link to this policy as the explanation.