Improve documentation for contribution guidelines

- Improve `CONTRIBUTING.md` with clearer, more structured guidelines.
- Introduce a centralized 'Script Guidelines' document for consistent
  reference.
- Remove repetitive information across documents, providing links to the
  primary source.
- Simplify language across related documentation for better
  accessibility and readability.

.github/ISSUE_TEMPLATE/4-new-script-suggestion.md

@@ -5,71 +5,56 @@ labels: enhancement
 ---
 
 <!--
-Thank you for suggesting an script to make privacy better. 🤗 
+Thank you for contributing to privacy.sexy! 🌟
-Please fill in as much of the template below as you're able.
+For guidance, see our script guidelines: https://github.com/undergroundwires/privacy.sexy/blob/master/docs/script-guidelines.md.
-You could alternatively send a PR directly (see CONTRIBUTING.md).
+Consider submitting a PR for faster implementation: https://github.com/undergroundwires/privacy.sexy/blob/master/CONTRIBUTING.md#extend-scripts.
 -->
 
-### OS
+### Operating system
 
 <!--
-Which OS will the new script configure?
+  Specify the OS: Windows, macOS, or Linux.
-One of the supported OSes: "Windows", "macOS" or "Linux".
 -->
 
 ### Name
 
 <!--
-The name of the script.
+  Suggest a name for the script.
-It should start with an imperative noun such as "disable", "turn off" , "clear"...
+  Naming conventions: https://github.com/undergroundwires/privacy.sexy/blob/master/docs/script-guidelines.md#name.
-E.g. "Disable webcam telemetry"
 -->
 
-### Script code
+### Code
 
 <!--
-Code that will be executed when script is selected.
+  Provide or explain the code to execute when the script runs.
-Try to keep it as simple and backwards-compatible as possible.
+  Code guidelines: https://github.com/undergroundwires/privacy.sexy/blob/master/docs/script-guidelines.md#code.
-Allowed languages:
-  - Windows: PowerShell (ps1) or batchfile
-    - 💡 Prioritize the one that's simpler, batchfile if similar.
-  - macOS: bash (sh)
-  - Linux: bash (sh) or Python 3
-    - 💡 Prioritize the one that's simpler, bash if similar.
 -->
 
 ### Revert code
 
 <!--
-If applicable, add code that will revert the script code to its original (OS default) state.
+  Include code to revert changes to the default state.
-It may require additional time, but it's much appreciated by the community.
+  Leave blank for non-reversible scripts.
-Leave blank if the script is nonreversible (e.g. when clearing data without backup).
 -->
 
-### Suggested category
+### Category
 
 <!--
-If applicable, suggest one more multiple suitable parent category of script.
+  Suggest a category for the script.
-A category is the item where the script will be presented under.
+  If unsure, leave blank for maintainers to decide.
-Most likely there already is a category for the script, so check the existing categories.
-If you're unsure, leave blank and maintainer(s) will choose one.
 -->
 
-### Suggested recommendation level
+### Recommendation level
 
 <!--
-If applicable, suggest recommending the script or not recommending at all.
+  Suggest a recommendation level: STANDARD (non-breaking), STRICT (limits functionality), or NONE (for advanced users).
-A script should be only recommended if it'll be safe for your grandmother to run.
+  If unsure, leave blank for maintainers to decide.
-So you have three options here:
-  STANDARD: Non-breaking scripts that does not limit any functionality.
-  STRICT: Scripts that can break certain functionality but not intrusive to common daily OS usage.
-  NONE: Script is not recommended for newbies at all, only those who knows what's going on should select it.
-If you're unsure, leave blank and maintainer(s) will choose one.
 -->
 
-### Additional documentation/references
+### Documentation/References
 
-<!-- 
+<!--
-If applicable, refer to documentation that should show up on the script description.
+  Provide any relevant documentation or references.
-Sources (URLs) should be as high quality as possible e.g. vendor documentation is favored over user forums.
+  Prefer high-quality sources such as vendor documentation.
+  Documentation guidelines: https://github.com/undergroundwires/privacy.sexy/blob/master/docs/script-guidelines.md#documentation.
 -->

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contributing
 
-Love your input! Contributing to this project should be as easy and transparent as possible, whether it's:
+Love your input ❤️! Contributing to this project should be as easy and transparent as possible, whether it's:
 
 - reporting a bug,
 - discussing the current state of the code,
@@ -16,7 +16,7 @@ Your pull requests are actively welcomed. We collaborate using [GitHub flow](htt
 
 The steps:
 
-1. Fork the repo and create your branch from master.
+1. Fork the repository and create your branch from `master`.
 2. If you've added code that requires testing, add tests. See [tests.md](./docs/tests.md).
 3. If you've done a major change, update the documentation. See [docs/](./docs/).
 4. Ensure the test suite passes. See [development.md | Testing](./docs/development.md#testing) for commands.
@@ -37,16 +37,44 @@ Automated pipelines will run to control your PR and they will publish your code
 
 ## Extend scripts
 
-Here's quick information for you who want to add more scripts.
+If you're interested in adding new scripts to privacy.sexy:
 
-You have two alternatives:
+1. Read [guidelines for a good script](./docs/script-guidelines.md)
+2. Choose one of two ways to contribute:
+   1. [Create an issue](https://github.com/undergroundwires/privacy.sexy/issues/new/choose) requesting the addition of a new script. This allows other contributors to develop and add it for you. This will take longer time.
+   2. Submit a pull request with your script. This is the faster route to seeing your script included in the project. Add your scripts to the appropriate OS directory in the [collections](src/application/collections/) (for syntax guidance, see [collection-files.md](docs/collection-files.md)) folder, and follow the [pull request process](#pull-request-process).
 
-1. [Create an issue](https://github.com/undergroundwires/privacy.sexy/issues/new/choose) and ask for someone else to add the script for you.
+## Commit conventions
-2. Or send a PR yourself. This would make it faster to get your code into the project. You need to add scripts to related OS in [collections](src/application/collections/) folder. Then you'd sent a pull request, see [pull request process](#pull-request-process).
+
-   - 💡 You should use existing shared functions for most of the operations, like `DisableService` for disabling services, to maintain code consistency and efficiency.
+- Adhere to the 50/72 rule:
-   - 📖 If you're unsure about the syntax, check [collection-files.md](docs/collection-files.md).
+  - Commit titles should not exceed 50 characters.
-   - 📖 If you wish to use templates, use [templating.md](./docs/templating.md).
+  - Limit description lines to 72 characters, except for code blocks or inline codes.
+- Avoid including delta (such as `git diff` information) or a list of changed files in the commit message. This information is redundant as it's already part of the commit.
+- Focus on explaining the WHY and HOW of the changes, rather than WHAT changes are.
+- Begin the commit message with a concise summary of what the commit accomplishes.
+- Use imperative language in the commit title. For example, use "add" instead of "added".
+- Commit prefixes:
+  - Prefix bug fixes with `fix:` or `Fix ...`.
+  - For commits affecting scripts of specific operating systems:
+    - Prefix the commit title with an OS-specific tag such as `win:` for Windows scripts, `mac:` for macOS scripts, and `linux:` for Linux scripts.
+    - Combine prefixes for commits affecting more than one operating system, e.g., `win, mac: ...`.
+
+## Versioning
+
+We base versioning on the release's content rather than strictly following semantic versioning.
+
+There are two main types of releases:
+
+1. **Patch Releases:** These focus on minor UI improvements, bug fixes, refactorings, dependency updates, and documentation updates. For scripts, they involve adjusting recommendation levels, enhancing functionality, and dividing scripts for more precise control. Patch releases may ship minor feature additions if they are essential for fixing a bug. For these updates, we increment the patch number in the `MAJOR.MINOR.PATCH`.
+
+2. **Feature Releases:** These releases bring significant updates that change how users interact with privacy.sexy. They include major UI enhancements, the introduction of new scripts, and features. For these updates, we increment the minor number in the `MAJOR.MINOR.PATCH`.
+
+Maintainers tag specific commits with a version number to trigger a release, and [bump-everywhere](https://github.com/undergroundwires/bump-everywhere) automates the release process including updating version numbers throughout the project.
+
+## Refactoring
+
+Opportunistic refactoring is welcome. If you're adding a feature or fixing a bug, feel free to also clean up and optimize the related code. Your contributions should leave the code in a better state than when you found it.
 
 ## License
 
-By contributing, you agree that your [GNU General Public License v3.0](./LICENSE) will be the license for your contributions.
+By contributing to this project, you agree that your contributions are licensed under the [GNU Affero General Public License](./LICENSE) as currently specified. Additionally, you expressly consent to the project maintainers having full authority to modify the licensing terms or relicense your contributions under different terms in the future.

docs/collection-files.md

@@ -1,192 +1,164 @@
 # Collection files
 
-- privacy.sexy is a data-driven application where it reads the necessary OS-specific logic from yaml files in [`application/collections`](./../src/application/collections/)
+privacy.sexy is a data-driven application that reads YAML files.
-- 💡 Best practices
+This document details the structure and syntax of the YAML files located in [`application/collections`](./../src/application/collections/), which form the backbone of the application's data model.
-  - If you repeat yourself, try to utilize [YAML-defined functions](#function)
+
-  - Always try to add documentation and a way to revert a tweak in [scripts](#script)
+Related documentation:
-- 📖 Types in code: [`collection.yaml.d.ts`](./../src/application/collections/collection.yaml.d.ts)
+
+- 📖 [`collection.yaml.d.ts`](./../src/application/collections/collection.yaml.d.ts) outlines code types.
+- 📖 [Script Guidelines](./script-guidelines.md) provide guidance on script creation including best-practices.
 
 ## Objects
 
 ### `Collection`
 
-- A collection simply defines:
+- Defines categories, scripts, and OS-specific details in a tree structure.
-  - different categories and their scripts in a tree structure
+- Allows defining common [functions](#function) for code reuse.
-  - OS specific details
-- Also allows defining common [function](#function)s to be used throughout the collection if you'd like different scripts to share same code.
 
 #### `Collection` syntax
 
-- `os:` *`string`*  (**required**)
+- `os:` *`string`* **(required)**
-  - Operating system that the [Collection](#collection) is written for.
+  - Operating system for the collection.
-  - 📖 See [OperatingSystem.ts](./../src/domain/OperatingSystem.ts) enumeration for allowed values.
+  - 📖 See [`OperatingSystem.ts`](./../src/domain/OperatingSystem.ts) for possible values.
 - `actions: [` ***[`Category`](#category)*** `, ... ]` **(required)**
-  - Each [category](#category) is rendered as different cards in card presentation.
+  - Renders each parent category as cards in the user interface.
   - ❗ A [Collection](#collection) must consist of at least one category.
 - `functions: [` ***[`Function`](#function)*** `, ... ]`
-  - Functions are optionally defined to re-use the same code throughout different scripts.
+  - Optional for code reuse.
 - `scripting:` ***[`ScriptingDefinition`](#scriptingdefinition)*** **(required)**
-  - Defines the scripting language that the code of other action uses.
+  - Sets the scripting language for all inline code used within the collection.
 
 ### `Category`
 
-- Category has a parent that has tree-like structure where it can have subcategories or subscripts.
+Represents a logical group of scripts and subcategories.
-- It's a logical grouping of different scripts and other categories.
 
 #### `Category` syntax
 
-- `category:` *`string`*  (**required**)
+- `category:` *`string`*  **(required)**
-  - Name of the category
+  - Name of the category.
-  - ❗ Must be unique throughout the [Collection](#collection)
+  - ❗ Must be unique throughout the [collection](#collection).
-- `children: [` ***[`Category`](#category)*** `|` [***`Script`***](#script) `, ... ]`  (**required**)
+- `children: [` ***[`Category`](#category)*** `|` [***`Script`***](#script) `, ... ]` **(required)**
   - ❗ Category must consist of at least one subcategory or script.
   - Children can be combination of scripts and subcategories.
 - `docs`: *`string`* | `[`*`string`*`, ... ]`
-  - Documentation pieces related to the category.
+  - Markdown-formatted documentation related to the category.
-  - Rendered as markdown.
 
 ### `Script`
 
-- Script represents a single tweak.
+Represents an individual tweak.
-- A script can be of two different types (just like [functions](#function)):
+
-  1. Inline script; a script with an inline code
+Types (like [functions](#function)):
-     - Must define `code` property and optionally `revertCode` but not `call`
+
-  2. Caller script; a script that calls other functions
+1. Inline script:
-     - Must define `call` property but not `code` or `revertCode`
+   - Direct code.
-- 🙏 For any new script, please add `revertCode` and `docs` values if possible.
+   - ❗ Requires `code` and optional `revertCode`.
+2. Caller script:
+   - Calls other [functions](#function).
+   - ❗ Requires `call`, but not `code` or `revertCode`.
+
+📖 For detailed guidelines, see [Script Guidelines](./script-guidelines.md).
 
 #### `Script` syntax
 
-- `name`: *`string`* (**required**)
+- `name`: *`string`* **(required)**
-  - Name of the script
+  - Script name.
-  - ❗ Must be unique throughout the [Collection](#collection)
+  - ❗ Must be unique throughout the [Collection](#collection).
-  - E.g. `Disable targeted ads`
+- `code`: *`string`* **(conditionally required)**
-- `code`: *`string`* (may be **required**)
+  - Code to execute when the user selects the script.
-  - Batch file commands that will be executed
+  - 💡 If defined, it's best practice to also define `revertCode`.
-  - 💡 If defined, best practice to also define `revertCode`
+  - ❗ Cannot co-exist with `call`, define either `code` with optional `revertCode` or `call`.
-  - ❗ If not defined `call` must be defined, do not define if `call` is defined.
+- `revertCode`: *`string`*
-- `revertCode`: `string`
+  - Reverts changes made by `code`.
-  - Code that'll undo the change done by `code` property.
+  - ❗ Cannot co-exist with `call`, define `revertCode` with `code` or `call`.
-  - E.g. let's say `code` sets an environment variable as `setx POWERSHELL_TELEMETRY_OPTOUT 1`
+- `call`: ***[`FunctionCall`](#functioncall)*** | `[` ***[`FunctionCall`](#functioncall)*** `, ... ]` **(conditionally required)**
-    - then `revertCode` should be doing `setx POWERSHELL_TELEMETRY_OPTOUT 0`
+  - A shared function or sequence of functions to call (called in order).
-  - ❗ Do not define if `call` is defined.
+  - ❗ Cannot co-exist with `code` or `revertCode`, define `code` with optional `revertCode` or `call`.
-- `call`: ***[`FunctionCall`](#functioncall)*** | `[` ***[`FunctionCall`](#functioncall)*** `, ... ]` (may be **required**)
-  - A shared function or sequence of functions to call (called in order)
-  - ❗ If not defined `code` must be defined
 - `docs`: *`string`* | `[`*`string`*`, ... ]`
-  - Documentation pieces related to the script.
+  - Markdown-formatted documentation related to the script.
-  - Rendered as markdown.
+- `recommend`: *`"standard"`* | *`"strict"`* | *`undefined`* (default: `undefined`)
-- `recommend`: `"standard"` | `"strict"` | `undefined` (default)
+  - Sets recommendation level.
-  - If not defined then the script will not be recommended
+  - Application will not recommend the script if `undefined`.
-  - If defined it can be either
+
-    - `standard`: Only non-breaking scripts without limiting OS functionality
+📖 For detailed guidelines, see [Script Guidelines](./script-guidelines.md).
-    - `strict`: Scripts that can break certain functionality in favor of privacy and security
 
 ### `FunctionCall`
 
-- Describes a single call to a function by optionally providing values to its parameters.
+Specifies a function call. It may require providing argument values to its parameters.
-- 👀 See [parameter substitution](./templating.md#parameter-substitution) for an example usage
 
 #### `FunctionCall` syntax
 
-- `function`: *`string`* (**required**)
+- `function`: *`string`* **(required)**
   - Name of the function to call.
-  - ❗ Function with same name must defined in `functions` property of [Collection](#collection)
+  - ❗ Function with same name must defined in `functions` property of [Collection](#collection).
-- `parameters`: `[ parameterName:` *`parameterValue`*`, ... ]`
+- `parameters`: `[` *`parameterName: parameterValue`* `, ... ]`
-  - Defines key value dictionary for each parameter and its value
+  - Key-value pairs representing function parameters and their corresponding argument values.
-  - E.g.
+  - 📖 See [parameter substitution](./templating.md#parameter-substitution) for an example usage.
-
+  - 💡 You can use [expressions (templating)](./templating.md#expressions) when providing argument values for parameters.
-    ```yaml
-      parameters:
-        userDefinedParameterName: parameterValue
-        # ...
-        appName: Microsoft.WindowsFeedbackHub
-    ```
-
-  - 💡 [Expressions (templating)](./templating.md#expressions) can be used as parameter value
 
 ### `Function`
 
-- Functions allow re-usable code throughout the defined scripts.
+- Enables reusable code in scripts.
 - Functions are templates compiled by privacy.sexy and uses special expression expressions.
-- A function can be of two different types (just like [scripts](#script)):
+- A function can be of two different types (like [scripts](#script)):
   1. Inline function: a function with an inline code.
-     - Must define `code` property and optionally `revertCode` but not `call`.
+     - ❗ Requires `code` and optionally `revertCode`, but not `call`.
   2. Caller function: a function that calls other functions.
-     - Must define `call` property but not `code` or `revertCode`.
+     - ❗ Requires `call`, but not `code` or `revertCode`.
-- 👀 Read more on [Templating](./templating.md) for function expressions and [example usages](./templating.md#parameter-substitution).
+- 📖 Read about function expressions in [Templating](./templating.md) with [example usages](./templating.md#parameter-substitution).
 
 #### `Function` syntax
 
-- `name`: *`string`* (**required**)
+- `name`: *`string`* **(required)**
   - Name of the function that scripts will use.
-  - Convention is to use camelCase, and be verbs.
+  - ❗ Function names must be unique.
-  - E.g. `uninstallStoreApp`
+  - ❗ Function names must follow camelCase and start with verbs (e.g., `uninstallStoreApp`).
-  - ❗ Function names must be unique
+- `parameters`: `[` ***[`FunctionParameter`](#functionparameter)*** `, ... ]` **(conditionally required)**
-- `parameters`: `[` ***[`FunctionParameter`](#functionparameter)*** `, ... ]`
+  - Lists parameters used.
-  - List of parameters that function code refers to.
+  - ❗ Required to be able use in [`FunctionCall`](#functioncall) or [expressions (templating)](./templating.md#expressions).
-  - ❗ Must be defined to be able use in [`FunctionCall`](#functioncall) or [expressions (templating)](./templating.md#expressions)
+- `code`: *`string`* **(conditionally required)**
- `code`: *`string`* (**required** if `call` is undefined)
+  - Code to execute when the user selects the script.
-  - Batch file commands that will be executed
+  - 💡 You can use [expressions (templating)](./templating.md#expressions) in its value.
-  - 💡 [Expressions (templating)](./templating.md#expressions) can be used in its value
+  - 💡 If defined, it's best practice to also define `revertCode`.
-  - 💡 If defined, best practice to also define `revertCode`
+  - ❗ Cannot co-exist with `call`, define either `code` with optional `revertCode` or `call`.
-  - ❗ If not defined `call` must be defined
 - `revertCode`: *`string`*
-  - Code that'll undo the change done by `code` property.
+  - Reverts changes made by `code`.
-  - E.g. let's say `code` sets an environment variable as `setx POWERSHELL_TELEMETRY_OPTOUT 1`
+  - 💡 You can use [expressions (templating)](./templating.md#expressions) in its value.
-    - then `revertCode` should be doing `setx POWERSHELL_TELEMETRY_OPTOUT 0`
+  - ❗ Cannot co-exist with `call`, define `revertCode` with `code` or `call`.
-  - 💡 [Expressions (templating)](./templating.md#expressions) can be used in code
+- `call`: ***[`FunctionCall`](#functioncall)*** | `[` ***[`FunctionCall`](#functioncall)*** `, ... ]` **(conditionally required)**
-- `call`: ***[`FunctionCall`](#functioncall)*** | `[` ***[`FunctionCall`](#functioncall)*** `, ... ]` (may be **required**)
+  - A shared function or sequence of functions to call (called in order).
-  - A shared function or sequence of functions to call (called in order)
+  - 💡 You can use [expressions (templating)](./templating.md#expressions) in argument values provided for parameters.
-  - The parameter values that are sent can use [expressions (templating)](./templating.md#expressions)
+  - ❗ Cannot co-exist with `code` or `revertCode`, define `code` with optional `revertCode` or `call`.
-  - ❗ If not defined `code` must be defined
 
 ### `FunctionParameter`
 
-- Defines a parameter that function requires optionally or mandatory.
+- Defines a single parameter that may require an argument value optionally or mandatory.
-- Its arguments are provided by a [Script](#script) through a [FunctionCall](#functioncall).
+- A [`FunctionCall`](#functioncall) provides argument values by a caller.
+  - A caller can be a [Script](#script) or [Function](#function).
 
 #### `FunctionParameter` syntax
 
-- `name`: *`string`* (**required**)
+- `name`: *`string`* **(required)**
-  - Name of the parameters that the function has.
+  - Name of the parameter that the function has.
-  - Parameter names must be defined to be used in [expressions (templating)](./templating.md#expressions).
+  - ❗ Required for [expressions (templating)](./templating.md#expressions).
-  - ❗ Parameter names must be unique and include alphanumeric characters only.
+  - ❗ Must be unique and consists of alphanumeric characters.
 - `optional`: *`boolean`* (default: `false`)
-  - Specifies whether the caller [Script](#script) must provide any value for the parameter.
+  - Indicates the caller must provide and argument value for the parameter.
-  - If set to `false` i.e. an argument value is not optional then it expects a non-empty value for the variable;
+  - 💡 If set to `false` i.e. an argument value is not optional then it expects a non-empty value for the variable.
-    - Otherwise it throws.
+    - E.g., in a [`with` expression](./templating.md#with).
-  - 💡 Set it to `true` if a parameter is used conditionally;
+  - 💡 Set it to `true` if you will use its argument value conditionally;
     - Or else set it to `false` for verbosity or do not define it as default value is `false` anyway.
-  - 💡 Can be used in conjunction with [`with` expression](./templating.md#with).
 
 ### `ScriptingDefinition`
 
-- Defines global properties for scripting that's used throughout its parent [Collection](#collection).
+Sets global scripting properties for a [Collection](#collection).
 
 #### `ScriptingDefinition` syntax
 
-- `language:` *`string`* (**required**)
+- `language:` *`string`* **(required)**
-  - 📖 See [ScriptingLanguage.ts](./../src/domain/ScriptingLanguage.ts) enumeration for allowed values.
+  - 📖 See [`ScriptingLanguage.ts`](./../src/domain/ScriptingLanguage.ts) enumeration for allowed values.
-- `startCode:` *`string`* (**required**)
+- `startCode:` *`string`* **(required)**
-  - Code that'll be inserted on top of user created script.
+  - Prepends the given code to the generated script file.
-  - Global variables such as `$homepage`, `$version`, `$date` can be used using [parameter substitution](./templating.md#parameter-substitution) code syntax such as `Welcome to {{ $homepage }}!`
+  - 💡 You can use global variables such as `$homepage`, `$version`, `$date` via [parameter substitution](./templating.md#parameter-substitution) code syntax such as `Welcome to {{ $homepage }}!`.
-- `endCode:` *`string`* (**required**)
+- `endCode:` *`string`* **(required)**
-  - Code that'll be inserted at the end of user created script.
+  - Appends to the given code to the generated script file.
-  - Global variables such as `$homepage`, `$version`, `$date` can be used using [parameter substitution](./templating.md#parameter-substitution) code syntax such as `Welcome to {{ $homepage }}!`
+  - 💡 You can use global variables such as `$homepage`, `$version`, `$date` via [parameter substitution](./templating.md#parameter-substitution) code syntax such as `Welcome to {{ $homepage }}!`.
-
-## Naming guidelines
-
-- Prioritize consistency throughout all names.
-- Use an instruction format like "do this, do that" for clear, direct guidance. This approach reduces potential confusion and offers easy-to-follow steps. It provides specific, unambiguous instructions.
-- Ensure brand names adhere to their official casing.
-- Choose clear and uncomplicated language.
-- Favor the terms:
-  - "Disable" over "Turn off"
-  - "Configure" over "Set up"
-  - "Clear" over "Erase" or "Clean"
-  - "Minimize" over "Limit" or "Reduce" (when it enhances clarity)
-  - "Remove" over "Uninstall"
-- Structure your phrases for clarity.
-  - For instance, "Disable XX telemetry" or "Clear XX data" are preferred over "Clear data from XX", "Disable telemetry in XX", or "Clear data of XX".
-- Use sentence case rather than Title Case.

docs/script-guidelines.md

@@ -0,0 +1,56 @@
+# privacy.sexy Script Guidelines
+
+Create a script for privacy.sexy by submitting a PR or creating an issue (details in [Extend Scripts](./../CONTRIBUTING.md#extend-scripts)).
+As scripts are central to privacy.sexy and reach a global audience, their design is critical.
+
+Key attributes of a good script:
+
+- ✅ Well-referenced [documentation](#documentation).
+- ✅ Utilizes [shared functions](#shared-functions).
+- ✅ Has a [simple name](#name).
+
+## Name
+
+- Choose a title that is easy to understand for all users, regardless of technical skill, yet remains technically accurate.
+- Focus on privacy implications, avoiding complex or overly technical jargon.
+- Maintain consistency in naming, avoiding linguistic variations.
+- Use action-oriented language for clarity and directness. Use an instruction format like "do this, do that" for clear, direct guidance.
+- Respect the official casing of brand names.
+- Choose clear and uncomplicated language.
+- It should start with an imperative noun.
+- Start with action verbs like `Clear`, `Disable`, `Remove`, `Configure`, `Minimize`, `Maximize`. While exceptions exist, these prefixes help maintain naming consistency.
+- Favor the terms:
+  - `Disable` over `Turn off`, `Stop`, `Prevent`
+  - `Configure` over `Set up`
+  - `Clear` over `Erase`, `Clean`
+  - `Minimize` over `Limit`, `Reduce`
+  - `Maximize` over `Extend`, `Delay`, `Postpone`, `Prolong`
+  - `Remove` over `Uninstall`
+- Structure your phrases for clarity, examples:
+  - Prefer `Disable XX telemetry` over `Disable telemetry in XX`
+  - Prefer `Clear XX data` over `Clear data from XX`, or `Clear data of XX`.
+- Use sentence case rather than Title Case.
+
+## Documentation
+
+- Use credible and reputable sources for references.
+- Use archived links by using [archive.org](https://archive.org) or [archive.today](https://archive.today).
+  - Format archive.today links fully, for example: `https://archive.today/YYYYMMDDhhmmss/https://privacy.sexy`.
+- Explain the default behavior if the script is not executed.
+
+## Shared functions
+
+Use existing shared functions when possible, like `DisableService` for disabling services,.
+
+- 📖 Learn about templates in [templating.md](./templating.md).
+- 📖 For syntax, see [collection-files.md](collection-files.md).
+
+## Code
+
+- Prefer [shared functions](#shared-functions); avoid custom code unless necessary.
+- Keep code simple and compatible with older systems.
+- Focus on reliability, ensuring the script is error-resistant, works on different locales and handles unexpected situations.
+- Language selection:
+  - Windows: Use batch when simpler, otherwise PowerShell.
+  - macOS/Linux: Use bash when simpler, otherwise Python.
+- Provide revert code to restore original/default settings when applicable.