odoo-forge-bundle 0.1.0

package/payload/skills/odoo18-docs/references/docs/contributing/development/git_guidelines.md

@@ -0,0 +1,142 @@
+---
+title: "Git guidelines"
+source_url: "https://docs.odoo.sbggai.top/contributing/development/git_guidelines.html"
+---
+
+==============
+# Git guidelines
+
+## Configure your git
+
+Based on ancestral experience and oral tradition, the following things go a long
+way towards making your commits more helpful:
+
+- Be sure to define both the user.email and user.name in your local git config
+
+  ```text
+
+     git config --global <var> <value>
+
+- Be sure to add your full name to your Github profile here. Please feel fancy
+  and add your team, avatar, your favorite quote, and whatnot ;-)
+
+## Commit message structure
+
+Commit message has four parts: tag, module, short description and full
+description. Try to follow the preferred structure for your commit messages
+
+```text
+
+  [TAG] module: describe your change in a short sentence (ideally < 50 chars)
+
+  Long version of the change description, including the rationale for the change,
+  or a summary of the feature being introduced.
+
+  Please spend a lot more time describing WHY the change is being done rather
+  than WHAT is being changed. This is usually easy to grasp by actually reading
+  the diff. WHAT should be explained only if there are technical choices
+  or decision involved. In that case explain WHY this decision was taken.
+
+  End the message with references, such as task or bug numbers, PR numbers, and
+  OPW tickets, following the suggested format:
+  task-123 (related to task)
+  Fixes #123  (close related issue on Github)
+  Closes #123  (close related PR on Github)
+  opw-123 (related to ticket)
+
+## Tag and module name
+
+Tags are used to prefix your commit. They should be one of the following
+
+- **[FIX]** for bug fixes: mostly used in stable version but also valid if you
+  are fixing a recent bug in development version;
+- **[REF]** for refactoring: when a feature is heavily rewritten;
+- **[ADD]** for adding new modules;
+- **[REM]** for removing resources: removing dead code, removing views,
+  removing modules, ...;
+- **[REV]** for reverting commits: if a commit causes issues or is not wanted
+  reverting it is done using this tag;
+- **[MOV]** for moving files: use git move and do not change content of moved file
+  otherwise Git may loose track and history of the file; also used when moving
+  code from one file to another;
+- **[REL]** for release commits: new major or minor stable versions;
+- **[IMP]** for improvements: most of the changes done in development version
+  are incremental improvements not related to another tag;
+- **[MERGE]** for merge commits: used in forward port of bug fixes but also as
+  main commit for feature involving several separated commits;
+- **[CLA]** for signing the Odoo Individual Contributor License;
+- **[I18N]** for changes in translation files;
+- **[PERF]** for performance patches;
+
+After tag comes the modified module name. Use the technical name as functional
+name may change with time. If several modules are modified, list them or use
+various to tell it is cross-modules. Unless really required or easier avoid
+modifying code across several modules in the same commit. Understanding module
+history may become difficult.
+
+## Commit message header
+
+After tag and module name comes a meaningful commit message header. It should be
+self explanatory and include the reason behind the change. Do not use single words
+like "bugfix" or "improvements". Try to limit the header length to about 50 characters
+for readability.
+
+Commit message header should make a valid sentence once concatenated with
+`if applied, this commit will <header>`. For example ``[IMP] base: prevent to
+archive users linked to active partners`` is correct as it makes a valid sentence
+`if applied, this commit will prevent users to archive...`.
+
+## Commit message full description
+
+In the message description specify the part of the code impacted by your changes
+(module name, lib, transversal object, ...) and a description of the changes.
+
+First explain WHY you are modifying code. What is important if someone goes back
+to your commit in about 4 decades (or 3 days) is why you did it. It is the
+purpose of the change.
+
+What you did can be found in the commit itself. If there was some technical choices
+involved it is a good idea to explain it also in the commit message after the why.
+For Odoo R&D developers "PO team asked me to do it" is not a valid why, by the way.
+
+Please avoid commits which simultaneously impact multiple modules. Try to split
+into different commits where impacted modules are different. It will be helpful
+if we need to revert changes in a given module separately.
+
+Don't hesitate to be a bit verbose. Most people will only see your commit message
+and judge everything you did in your life just based on those few sentences.
+No pressure at all.
+
+**You spend several hours, days or weeks working on meaningful features. Take
+some time to calm down and write clear and understandable commit messages.**
+
+If you are an Odoo R&D developer the WHY should be the purpose of the task you
+are working on. Full specifications make the core of the commit message.
+**If you are working on a task that lacks purpose and specifications please
+consider making them clear before continuing.**
+
+Finally here are some examples of correct commit messages :
+
+```text
+
+ [REF] models: use `parent_path` to implement parent_store
+
+  This replaces the former modified preorder tree traversal (MPTT) with the
+  fields `parent_left`/`parent_right`[...]
+
+ [FIX] account: remove frenglish
+
+  [...]
+
+  Closes #22793
+  Fixes #22769
+
+ [FIX] website: remove unused alert div, fixes look of input-group-btn
+
+  Bootstrap's CSS depends on the input-group-btn
+  element being the first/last child of its parent.
+  This was not the case because of the invisible
+  and useless alert.
+
+.. note:: Use the long description to explain the *why* not the
+          *what*, the *what* can be seen in the diff

package/payload/skills/odoo18-docs/references/docs/contributing/development.md

@@ -0,0 +1,175 @@
+---
+title: ""
+source_url: "https://docs.odoo.sbggai.top/contributing/development.html"
+---
+
+:show-content:
+# 
+# Development
+
+.. toctree::
+   :titlesonly:
+
+   development/coding_guidelines
+   development/git_guidelines
+
+If you are reading this, chances are that you are interested in learning how to contribute to the
+codebase of Odoo. Whether that's the case or you landed here by accident, we've got you covered!
+
+.. seealso::
+   :doc:`Discover other ways to contribute to Odoo <../contributing>`
+
+When you feel ready, jump to the :ref:`contributing/development/setup` section to begin your journey
+in contributing to the development of Odoo.
+
+.. _contributing/development/setup:
+
+# Environment setup
+
+The instructions below help you prepare your environment for making local changes to the codebase
+and then push them to GitHub. Skip this section and go to
+:ref:`contributing/development/first-contribution` if you have already completed this step.
+
+#. First, you need to [create a GitHub account ](https://github.com/join). Odoo uses GitHub to
+   manage the source code of its products, and this is where you will make your changes and submit
+   them for review.
+#. [Generate a new SSH key and register it on your GitHub account
+   ](https://docs.github.com/en/authentication/connecting-to-github-with-ssh).
+#. Go to [github.com/odoo/odoo ](https://github.com/odoo/odoo) and click on the :guilabel:`Fork`
+   button in the top right corner to create a fork (:dfn:`your own copy`) of the repository on your
+   account. Do the same with [github.com/odoo/enterprise ](https://github.com/odoo/enterprise) if
+   you have access to it. This creates a copy of the codebase to which you can make changes without
+   affecting the main codebase. Skip this step if you work at Odoo.
+#. .. include:: install_git.rst
+#. Configure Git to identify yourself as the author of your future contributions. Enter the same
+   email address you used to register on GitHub.
+
+   ```console
+
+      $ git config --global user.name "Your Name"
+      $ git config --global user.email "youremail@example.com"
+
+#. :doc:`Install Odoo from the sources <../administration/on_premise/source>`. Make sure to fetch
+   the sources through Git with SSH.
+#. Configure Git to push changes to your fork(s) rather than to the main codebase. If you work at
+   Odoo, configure Git to push changes to the shared forks created on the account **odoo-dev**.
+
+   .. tabs::
+
+      .. tab:: Link Git with your fork(s)
+
+         In the command below, replace `<your_github_account>` with the name of the GitHub account
+         on which you created the fork(s).
+
+         ```console
+
+            $ cd /CommunityPath
+            $ git remote add dev git@github.com:<your_github_account>/odoo.git
+
+         If you have access to `odoo/enterprise`, configure the related remote too.
+
+         ```console
+
+            $ cd /EnterprisePath
+            $ git remote add dev git@github.com:<your_github_account>/enterprise.git
+
+      .. tab:: Link Git with odoo-dev
+
+         ```console
+
+            $ cd /CommunityPath
+            $ git remote add dev git@github.com:odoo-dev/odoo.git
+            $ git remote set-url --push origin you_should_not_push_on_this_repository
+
+            $ cd /EnterprisePath
+            $ git remote add dev git@github.com:odoo-dev/enterprise.git
+            $ git remote set-url --push origin you_should_not_push_on_this_repository
+
+#. That's it! You are ready to :ref:`make your first contribution
+   <contributing/development/first-contribution>`.
+
+.. _contributing/development/first-contribution:
+
+# Make your first contribution
+
+> **important**:
+>    - Odoo development can be challenging for beginners. We recommend you to be knowledgeable enough
+     to code a small module before contributing. If that is not the case, take some time to go
+     through the :doc:`developer tutorials </developer/tutorials>` to fill in the gaps.
+   - Some steps of this guide require to be comfortable with Git. Here are some [tutorials
+     ](https://www.atlassian.com/git/tutorials) and an [interactive training
+     ](https://learngitbranching.js.org/) if you are stuck at some point.
+
+Now that your environment is set up, you can start contributing to the codebase. In a terminal,
+navigate to the directory where you installed Odoo from sources and follow the guide below.
+
+#. Choose the version of Odoo to which you want to make changes. Keep in mind that contributions
+   targeting an :doc:`unsupported version of Odoo </administration/supported_versions>` are not
+   accepted. This guide assumes that the changes target Odoo {CURRENT_VERSION}, which corresponds to
+   branch `{CURRENT_BRANCH}`.
+#. Create a new branch starting from branch {CURRENT_BRANCH}. Prefix the branch name with the base
+   branch: `{CURRENT_BRANCH}-...`. If you work at Odoo, suffix the branch name with your Odoo
+   handle: `{CURRENT_BRANCH}-...-xyz`.
+
+   .. example::
+
+      ```console
+
+         $ git switch -c {CURRENT_BRANCH}-fix-invoices
+
+      ```console
+
+         $ git switch -c {CURRENT_BRANCH}-fix-invoices-xyz
+
+#. [Sign the Odoo CLA ]({GITHUB_PATH}/doc/cla/sign-cla.md) if not already done. Skip this step if
+   you work at Odoo.
+#. Make the desired changes to the codebase. When working on the codebase, follow these rules:
+
+   - Keep your changes focused and specific. It is best to work on one particular feature or bug fix
+     at a time rather than tackle multiple unrelated changes simultaneously.
+   - Respect the [stable policy
+     ](https://github.com/odoo/odoo/wiki/Contributing#what-does-stable-mean) when working in
+     another branch than `master`.
+   - Follow the :doc:`coding guidelines <development/coding_guidelines>`.
+   - Test your changes thoroughly and :doc:`write tests </developer/reference/backend/testing>` to
+     ensure that everything is working as expected and that there are no regressions or unintended
+     consequences.
+
+#. Commit your changes. Write a clear commit message as instructed in the :doc:`Git guidelines
+   <development/git_guidelines>`.
+
+   ```console
+
+      $ git add .
+      $ git commit
+
+#. Push your change to your fork, for which we added the remote alias `dev`.
+
+   .. example::
+
+      ```console
+
+         $ git push -u dev {CURRENT_BRANCH}-fix-invoices-xyz
+
+#. Open a :abbr:`PR (Pull Request)` on GitHub to submit your changes for review.
+
+   #. Go to the [compare page of the odoo/odoo codebase ](https://github.com/odoo/odoo/compare), or
+      the [compare page of the odoo/enterprise codebase
+      ](https://github.com/odoo/enterprise/compare), depending on which codebase your changes
+      target.
+   #. Select **{CURRENT_BRANCH}** for the base.
+   #. Click on :guilabel:`compare across forks`.
+   #. Select **<your_github_account>/odoo** or **<your_github_account>/enterprise** for the head
+      repository. Replace `<your_github_account>` with the name of the GitHub account on which you
+      created the fork or by **odoo-dev** if you work at Odoo.
+   #. Review your changes and click on the :guilabel:`Create pull request` button.
+   #. Tick the :guilabel:`Allow edits from maintainer` checkbox. Skip this step if you work at Odoo.
+   #. Complete the description and click on the :guilabel:`Create pull request` button again.
+
+#. At the bottom of the page, check the mergeability status and address any issues.
+#. As soon as your :abbr:`PR (Pull Request)` is ready for merging, a member of the Odoo team
+   is automatically assigned for review. If the reviewer has questions or remarks, they will
+   post them as comments and you will be notified by email. Those comments must be resolved
+   for the contribution to go forward.
+#. Once your changes are approved, the review merges them and they become available for all Odoo
+   users after the next code update!

package/payload/skills/odoo18-docs/references/docs/contributing/documentation/content_guidelines.md

@@ -0,0 +1,329 @@
+---
+title: "Content guidelines"
+source_url: "https://docs.odoo.sbggai.top/contributing/documentation/content_guidelines.html"
+---
+
+==================
+# Content guidelines
+
+While we encourage you to adopt your own writing style, some rules still apply to maintain clarity
+and ensure readers can easily understand the content.
+
+> **important**:
+>    We strongly recommend to read the :doc:`rst_guidelines` and the main :doc:`../documentation`
+   pages before contributing.
+
+.. _contributing/content/organization:
+
+# Documentation organization
+
+When writing documentation about a given topic, keep pages within the same folder organized.
+
+For most topics, a single page should do the job. Place it in the appropriate section of the
+documentation (e.g., content related to the CRM app goes under :menuselection:`User Docs --> Sales
+--> CRM`) and follow the :ref:`document structure <contributing/content/structure>` guidelines.
+
+For more complex topics, several pages may be needed to cover all their aspects. Usually, you will
+find yourself adding documentation to a topic that is already partially covered. In that case,
+either create a new page and place it at the same level as other related pages or add new sections
+to an existing page. When documenting a complex topic from scratch, organize the content across
+several child pages that are referenced on that directory's parent page (the :abbr:`TOC (Table Of
+Contents)` page); whenever possible, write content on the parent page and not only on the child
+pages. Make the parent page accessible from the navigation menu by using the
+:ref:`show-content <contributing/rst/document-metadata>` metadata directive.
+
+> **note**:
+>    Avoid duplicating content whenever possible; if a topic is already documented on another page,
+   :ref:`reference <contributing/rst/hyperlinks>` that existing information instead of repeating it.
+
+> **important**:
+>    When deleting or moving a `.rst` file, update the corresponding text file in the
+   :file:`redirects` folder based on your branch's version (e.g., :file:`17.0.txt`). To do so, add a
+   new line at the bottom of the relevant section (e.g., `# applications/sales`). On this line,
+   first, add the redirection entry point with the old file location, followed by a space, and then
+   add the exit point with the new or relevant file location. For example, if moving the file
+   :file:`unsplash.rst` from :file:`applications/websites/website/configuration` to
+   :file:`applications/general/integrations`, add the following entry under the section
+   `# applications/websites`:
+
+   ```text
+
+      applications/websites/website/configuration/unsplash.rst applications/general/integrations/unsplash.rst
+
+.. _contributing/content/structure:
+
+# Document structure
+
+Use different **heading levels** to organize text by sections and sub-sections. Headings are not
+only displayed in the document but also on the navigation menu (only the H1) and on the "On this
+page" sidebar (all H2 to H6).
+
++---------------------------------------------------------------------------------------+
+| | **H1: Page title**                                                                  |
+| | The *page title* gives readers a quick and clear understanding of what the content  |
+|   is about.                                                                           |
+|                                                                                       |
+| The *content* in this section describes the upcoming content from a **business point  |
+| of view**, and should not put the emphasis on Odoo, as this is documentation and not  |
+| marketing.                                                                            |
+|                                                                                       |
+| Under the page title (H1), start with a **lead paragraph**, which helps the reader    |
+| make sure that they've found the right page, then explain the **business aspects of   |
+| this topic** in the following paragraphs.                                             |
++-----+---------------------------------------------------------------------------------+
+|     | | **H2: Section title (configuration)**                                         |
+|     | | This first H2 section is about the configuration of the feature, or the       |
+|     |   prerequisites to achieve a specific goal.                                     |
++-----+---------------------------------------------------------------------------------+
+|     | | **H2: Section title (main sections)**                                         |
+|     | | Create as many main sections as you have actions or features to distinguish.  |
++-----+-----+---------------------------------------------------------------------------+
+|     |     | | **H3: Subsection**                                                      |
+|     |     | | Subsections are perfect for assessing very specific points.             |
++-----+-----+---------------------------------------------------------------------------+
+|     | **H2: Next Section**                                                            |
++-----+---------------------------------------------------------------------------------+
+
+To write good titles and headings:
+
+- **Be concise**: **avoid sentences**, questions, and titles starting with "how to".
+- **Do not use pronouns** in your titles, especially 2nd person (*you/your*).
+- Use **sentence case**. This means you capitalize only:
+
+  - the first word of the title or heading;
+  - the first word after a colon;
+  - proper nouns (brands, product and service names, etc.).
+
+> **note**:
+>    - Most titles and headings generally refer to a concept and do *not* represent the name of a
+     feature or a model.
+   - Do not capitalize the words of an acronym if they do not entail a proper noun.
+   - Verbs in headings are fine since they often describe an action.
+
+.. seealso::
+   - :ref:`RST cheat sheet: headings <contributing/rst/headings>`
+   - :ref:`RST cheat sheet: markups <contributing/rst/markups>`
+
+.. _contributing/content/writing-style:
+
+# Writing style
+
+Writing for documentation is not the same as writing for a blog or another medium. Readers are
+more likely to skim through content to find the information they need. Keep in mind that the
+documentation is a place to **inform and describe**, not to convince and promote.
+
+> **tip**:
+>    Avoid using *you* as much as possible by opting for the imperative mood where appropriate.
+   However, do not complicate sentences just to avoid addressing the reader directly.
+
+   .. example::
+      | **Good example:**
+      | Select the appropriate option from the dropdown menu.
+
+      | **Bad example:**
+      | You can select the appropriate option from the dropdown menu.
+
+.. _contributing/content/spelling:
+
+## Spelling
+
+Use American English spelling and grammar throughout the documentation.
+
+.. _contributing/content/consistency:
+
+## Consistency
+
+*Consistency is key to everything.*
+
+Make sure that the writing style remains **consistent**. When modifying existing content, try to
+match the existing tone and presentation or rewrite it to match your own style.
+
+.. _contributing/content/capitalization:
+
+## Capitalization
+
+- Use sentence case in :ref:`titles <contributing/content/structure>`.
+- Capitalize app names, e.g., **Odoo Sales**, the **Sales** app, etc.
+- Capitalize labels (such as fields and buttons) as they appear in Odoo. If a label is in all caps,
+  convert it to sentence case.
+- Capitalize the first letter after a colon if it is a complete sentence.
+- Avoid capitalizing common nouns, such as "sales order" and "bill of materials", unless you
+  reference a label or a model.
+
+.. _contributing/content/grammatical-tenses:
+
+## Grammatical tenses
+
+In English, descriptions and instructions usually require the use of the **present tense**, while
+the *future tense* is appropriate only when a specific event is to happen ulteriorly.
+
+.. example::
+
+  | **Good example (present):**
+  | Screenshots are automatically resized to fit the content block's width.
+
+  | **Bad example (future):**
+  | When you take a screenshot, remember that it will be automatically resized to fit the content
+    block's width.
+
+.. _contributing/content/lists:
+
+# Lists
+
+Lists help organize information in a clear and concise manner and improve readability. They are
+used to highlight important details, guide the reader through steps in a systematic way, etc.
+
+Use numbered lists when the sequence matters, e.g., instructions, procedures, or steps that must be
+performed in a particular order.
+
+Use bulleted lists when the sequence of items does not matter, e.g., lists of features, fields,
+options, etc.
+
+> **tip**:
+>    - Use inline text for explanations or when there are three or fewer list items.
+   - Combine bulleted and numbered lists using :ref:`nested lists <contributing/rst/nested-list>`
+     where appropriate.
+   - Consider grouping simple steps within the same list item, e.g.: Go to :menuselection:`Website
+     --> Site --> Pages` and click :guilabel:`New`.
+   - Only use a period at the end of the list item if it forms a complete sentence.
+
+.. example::
+   **Bulleted list**
+
+   The following fields are available on the :guilabel:`Replenishment` report:
+
+   - :guilabel:`Product`: the product that requires a replenishment
+   - :guilabel:`Location`: the specific location where the product is stored
+   - :guilabel:`Warehouse`: the warehouse where the product is stored
+   - :guilabel:`On Hand`: the amount of product currently available
+
+   **Numbered list**
+
+   To create a new website page, proceed as follows:
+
+   #. - Either open the **Website** app, click :guilabel:`+ New` in the top-right corner, then
+        select :guilabel:`Page`;
+      - Or go to :menuselection:`Website --> Site --> Pages` and click :guilabel:`New`.
+
+   #. Enter a :guilabel:`Page Title`; this title is used in the menu and the page's URL.
+   #. Click :guilabel:`Create`.
+   #. Customize the page's content and appearance using the website builder, then click
+      :guilabel:`Save`.
+
+.. seealso::
+   :ref:`RST cheat sheet: lists <contributing/rst/lists>`
+
+# Icons
+
+Use :ref:`icons <contributing/rst/icons>` in instructions to help readers identify user interface
+elements and reduce the need for lengthy explanations. Accompany every icon with a descriptor
+in brackets.
+
+.. example::
+   Once the developer mode is activated, the developer tools can be accessed by clicking the
+   :icon:`fa-bug` (:guilabel:`bug`) icon.
+
+.. seealso::
+   :ref:`RST cheat sheet: icons <contributing/rst/icons>`
+
+.. _contributing/content/images:
+
+# Images
+
+Adding a few images to illustrate text helps the readers understand and memorize the content.
+However, images should never replace text: written instructions should be complete and clear on
+their own, without relying on visual aids. Use images sparingly, for example, to highlight a
+particular point or clarify an example.
+
+> **important**:
+>    Do not forget to [compress your PNG files with pngquant ](https://pngquant.org).
+
+.. _contributing/content/screenshots:
+
+## Screenshots
+
+Screenshots are automatically resized to fit the content block's width. This implies that if they
+are too wide, they are not readable on lower-resolution screens. We recommend avoiding full-screen
+screenshots of the app unless absolutely necessary and making sure images are no wider than a range
+of 768-933 pixels.
+
+Here are a few tips to improve your screenshots:
+
+#. **Resize** your browser's width, either by *resizing the window* itself or by opening the
+   *browser's developer tools* and resizing the width.
+#. **Select** the relevant area rather than keeping the entire window.
+#. **Remove** unnecessary information and **resize** columns when applicable.
+
+> **important**:
+>    Do not use markups such as rectangles or arrows on screenshots. Instead, crop the image to
+   highlight the most relevant information, and ensure that text instructions are clear and
+   self-explanatory without relying on images.
+
+.. example::
+   **Good example (resized browser, no unnecessary columns, adjusted columns' width, cropped):**
+
+   .. image:: content_guidelines/quotations-list-reduced.png
+      :alt: Cropped screenshot
+
+   **Bad example (full-width screenshot):**
+
+   .. image:: content_guidelines/quotations-list-full.png
+      :alt: Full-width screenshot
+
+.. _contributing/content/media-files:
+
+## Media files
+
+A **media filename**:
+
+- is written in **lower-case letters**;
+- is **relevant** to the media's content. (e.g., :file:`screenshot-tips.gif`);
+- separates its words with a **hyphen** `-` (e.g., :file:`awesome-filename.png`).
+
+Each RST file has its own folder for storing media files. The folder's name must be the same as the
+RST file's name.
+
+For example, the document :file:`doc_filename.rst` refers to two images that are placed in the
+folder `doc_filename`.
+
+::
+
+  ├── section
+  │   └── doc_filename
+  │   │   └── screenshot-tips.gif
+  │   │   └── awesome-filename.png
+  │   └── doc_filename.rst
+
+> **note**:
+>    Previously, image filenames would mostly be named with numbers (e.g., :file:`feature01.png`) and
+   placed in a single :file:`media` folder. While it is advised not to name your *new* images in
+   that fashion, it is also essential **not to rename unchanged files**, as doing this would double
+   the weight of renamed image files on the repository. They will eventually all be replaced as the
+   content referencing those images is updated.
+
+.. _contributing/content/alt-tags:
+
+## ALT tags
+
+An **ALT tag** is a *text alternative* to an image. This text is displayed if the browser fails to
+render the image. It is also helpful for users who are visually impaired. Finally, it helps
+search engines, such as Google, to understand what the image is about and index it correctly, which
+improves :abbr:`SEO (Search Engine Optimization)`.
+
+Good ALT tags are:
+
+- **Short** (one line maximum);
+- **Not a repetition** of a previous sentence or title;
+- A **good description** of the action happening in the image;
+- Easily **understandable** if read aloud.
+
+.. example::
+
+   An appropriate ALT tag for the following screenshot would be *Activating the developer mode in
+   the Settings app*.
+
+   .. image:: content_guidelines/settings.png
+      :alt: Activating the developer mode in the Settings app
+
+.. seealso::
+   :ref:`RST cheat sheet: images <contributing/rst/images>`