Proposal for an AI policy

.github/pull_request_template.md

@@ -0,0 +1,10 @@
+## Pre-requisites
+
+- [ ] I have read the [Contributing Guidelines](https://github.com/YOURLS/.github/blob/main/CONTRIBUTING.md)
+- [ ] I am using AI and have read the [AI Policy](https://github.com/YOURLS/.github/blob/main/AI_POLICY.md)
+
+
+## Change Description
+<!--- Describe IN YOUR OWN WORDS your changes in detail. Why is this change required? What problem does it solve? --->
+
+

.github/workflows/lint.yml

@@ -40,3 +40,5 @@ jobs:
           GITHUB_TOKEN: ${{ github.token }}
           FILTER_REGEX_EXCLUDE: ${{ inputs.exclude }}
           VALIDATE_JSCPD: false
+          VALIDATE_BIOME_FORMAT: false
+          VALIDATE_GITHUB_ACTIONS_ZIZMOR: false

AI_POLICY.md

@@ -0,0 +1,45 @@
+# AI Usage Policy
+
+The YOURLS project and organization have strict rules regarding AI usage.
+
+- **All AI usage in any form must be disclosed.** You must state
+  the AI model you used along with the extent to which the work was AI-assisted.
+
+- **The human-in-the-loop must fully understand all code.** If you can't explain
+  without AI what your changes do and how they interact with existing code, please
+  do not contribute to this project.
+
+- **Any content generated with AI must have been reviewed _and edited_
+  by a human before submission.** AI is very good at being overly verbose and
+  including noise that distracts from the main point.
+
+- **The human-in-the-loop must communicate with maintainers.** This follows from
+  the preceding points: AI models are verbose and unfocused. Don't have your AI
+  tool describe to us what you've found or changed; say it in your own words.
+
+- **Pull Requests must be focused.** If you want to submit a pull request that fixes a
+  problem, enhances or introduces a new feature, make sure your patch does only
+  that. Pull requests that change whitespace, reword comments, or contain multiple
+  unrelated sets of changes will be rejected.
+
+- **Pull Requests must originate from a real human need.** A valid pull request addresses
+  a bug you actually encountered, or a feature you genuinely need. We do not
+  accept pull requests where the origin is an AI agent that scanned the codebase and
+  decided something could be "improved" — refactored, renamed, reworded, or
+  otherwise touched. If you cannot point to a concrete problem you faced as a user,
+  there is no pull request to submit.\
+  **Exception:** Security-related findings from a code scanner are welcome,
+  provided the submission still follows all other rules above.
+
+## There are Humans Here
+
+Please remember that YOURLS is maintained by humans.
+
+Every discussion, issue, and pull request is read and reviewed by humans.
+It is a boundary point at which people interact with each other and guide
+the work. It is rude and disrespectful to approach this boundary with
+low-effort, unqualified contributions that put the burden of validation
+on the maintainers.
+
+**This AI Policy is not an anti AI stance.** It's our way to preserve our
+limited time and resources devoted to this community project.

CONTRIBUTING.md

@@ -1,127 +1,34 @@
-# Contributing to YOURLS Projects
+# Contributing to YOURLS
 
-Please take a moment to review this document in order to make the contribution
-process easy and effective for everyone involved.
+## Issue tracker
 
-Submitting an issue that is improperly or incompletely written is a waste of time for everybody.
-
-Following these guidelines helps to communicate that you respect the time of
-the developers managing and developing this open source project. In return,
-they should reciprocate that respect in addressing your issue or assessing
-patches and features.
-
-## Using the issue tracker
-
-The issue tracker is the preferred channel for [bug reports](#bug-reports),
-[feature requests](#feature-requests) and [submitting pull
-requests](#pull-requests), but please respect the following restrictions:
-
-- Please **do not** use the issue tracker for personal support requests.  
-  Use [discussions](https://github.com/YOURLS/YOURLS/discussions) instead to ask the community for help.
-
-- Please **do not** derail or troll issues.  
-  Keep the discussion on topic and respect the opinions of others.
+Use the issue tracker for bug reports, feature requests, and pull requests.
+Personal support must be discussed using [discussions space](https://github.com/orgs/YOURLS/discussions).
 
 ## Bug reports
 
-A bug is a _demonstrable problem_ that is caused by the code in the repository.
-Good bug reports are extremely helpful - thank you!
-
-Guidelines for bug reports:
-
-1. **Use the GitHub issue search**  
-   Check if the issue has already been reported. Reporting duplicates is a waste of
-   time for everyone. Search in **all issues**, open and closed.
-2. **Check if the issue has been fixed**  
-   Try to reproduce it using the latest `master` or development branch in the repository.
-   Maybe it has been fixed since the last stable release.
-3. **Give details**  
-   A good bug report shouldn't leave others needing to chase you up for more
-   information. Please try to be as detailed as possible in your report.
-   Give any information that is relevant to the bug:
-
-   - YOURLS & MySQL & PHP versions
-   - Server Software
-   - Browser name & version
-
-   What is the expected output? What do you see instead? See the report example below.
-
-4. **Isolate the problem**  
-   Isolate the problem as much as you can, reduce to the bare minimum required to reproduce the issue.
-   Don't describe a general situation that doesn't work as expected and just count on us to pin
-   point the problem.
+Search existing issues (open and closed) before reporting.
+Ensure the alleged behavior is observed on the latest version.
+A good report includes YOURLS/MySQL/PHP versions, expected and actual behavior, and steps to reproduce the problem.
 
 ## Feature requests
 
-Feature requests are welcome. But take a moment to find out whether your idea
-fits with the scope and aims of the project. It's up to _you_ to make a strong
-case to convince the YOURLS developers of the merits of this feature. Please
-provide as much detail and context as possible.
-
-## Pull requests
+YOURLS aims to stay lean and cover the needs of the vast majority of users.
+If a feature wouldn't be useful to nearly everyone, it probably belongs in a plugin rather than core.
+The [plugin architecture](https://yourls.org/docs/development/plugins) is designed to extend core behavior for the custom use cases.
 
-Good pull requests - patches, improvements, new features - are a fantastic
-help. They should remain focused in scope and avoid containing unrelated
-commits.
+Make sure your idea fits the project's scope, and provide context to make a strong case.
 
-1. **Please ask first**  
-   Before embarking on any significant pull request (e.g. implementing features,
-   refactoring code), otherwise you risk spending a lot of time working on
-   something that the developers might not want to merge into the project.
-2. **Licensing**  
-   By submitting a patch, you agree that your code will be licensed under the
-   [MIT License](https://github.com/YOURLS/YOURLS/blob/master/LICENSE) terms.
-3. **Coding Standards**  
-   Please adhere to the coding conventions used throughout the project (indentation,
-   comments, etc.). Make sure you've tested your patch under
-   different scenarios (various browsers, non default installation path, etc.).
-
-Adhering to the following this process is the best way to get your work
-merged:
-
-1. [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo), clone your fork,
-   and configure the remotes.
-
-   ```bash
-   # Clone your fork of the repo into the current directory
-   git clone https://github.com/<your-username>/<repo-name>
-   # Navigate to the newly cloned directory
-   cd <repo-name>
-   # Assign the original repo to a remote called "upstream"
-   git remote add upstream https://github.com/<upsteam-owner>/<repo-name>
-   ```
-
-2. If you cloned a while ago, get the latest changes from upstream.
-
-   ```bash
-   git checkout <dev-branch>
-   git pull upstream <dev-branch>
-   ```
-
-3. Create a new topic branch (off the main project development branch) to
-   contain your feature, change, or fix.
-
-   ```bash
-   git checkout -b <topic-branch-name>
-   ```
-
-4. Commit your changes in logical chunks. Please adhere to these [git commit
-   message guidelines](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
-   or your code is unlikely be merged into the main project. Use Git's
-   [interactive rebase](https://docs.github.com/en/github/using-git/about-git-rebase)
-   feature to tidy up your commits before making them public.
-
-5. Locally merge (or rebase) the upstream development branch into your topic branch:
-
-   ```bash
-   git pull [--rebase] upstream <dev-branch>
-   ```
+## Pull requests
 
-6. Push your topic branch up to your fork:
+- It's better to ask before starting any significant work.
+- AI use must follow our [AI Policy](AI_POLICY.md).
+- Keep pull requests focused. 
+- Limit pull requests to a single concern.
+- Avoid unrelated changes such as whitespace fixes or rewording comments elsewhere in the codebase.
+- Follow existing coding conventions.
+- Unit tests are very welcome.
+- Your code will be licensed under the [MIT License](https://github.com/YOURLS/YOURLS/blob/master/LICENSE).
 
-   ```bash
-   git push origin <topic-branch-name>
-   ```
 
-7. [Open a Pull Request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)
-   with a clear title and description.
+❤️ Thank you!