diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..95ea177 --- /dev/null +++ b/.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 + + + diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index 6c382da..ea98fa8 100644 --- a/.github/workflows/lint.yml +++ b/.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 diff --git a/AI_POLICY.md b/AI_POLICY.md new file mode 100644 index 0000000..cc75b54 --- /dev/null +++ b/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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 50246dc..ddfffb5 100644 --- a/CONTRIBUTING.md +++ b/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// - # Navigate to the newly cloned directory - cd - # Assign the original repo to a remote called "upstream" - git remote add upstream https://github.com// - ``` - -2. If you cloned a while ago, get the latest changes from upstream. - - ```bash - git checkout - git pull upstream - ``` - -3. Create a new topic branch (off the main project development branch) to - contain your feature, change, or fix. - - ```bash - git checkout -b - ``` - -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 - ``` +## 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 - ``` -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! \ No newline at end of file