docs: use the new [!NOTE] syntax (#10959)

* style-guide: use the new note syntax
* MAINTAINERS: use the new note syntax, use full month names
* CONTRIBUTING: use the new note syntax
* maintainers-guide: use the new note syntax
* CLIENT-SPECIFICATION: use the new note syntax
* COMMUNITY-ROLES: use the new note syntax
* git-terminal: use the new note syntax

---------

Co-authored-by: K.B.Dharun Krishna <kbdharunkrishna@gmail.com>
This commit is contained in:
Lena
2023-10-13 01:26:58 +02:00
committed by GitHub
parent ecee31e62a
commit 7856124245
7 changed files with 33 additions and 23 deletions

View File

@@ -14,7 +14,8 @@ The overall process should look somewhat like this:
3. Create a feature branch, e.g. named after the command you plan to edit:
`git checkout -b {{branch_name}}`
> :warning: It is bad practice to submit a PR from the `main` branch of your forked repository. Please create pull requests from a well named feature branch.
> [!WARNING]
> It is bad practice to submit a PR from the `main` branch of your forked repository. Please create pull requests from a well named feature branch.
4. Make your changes (edit existing files or create new ones)
@@ -24,7 +25,8 @@ The overall process should look somewhat like this:
6. Push the commit(s) to your fork:
`git push origin {{branch_name}}`
> :warning: Please avoid force-pushing since it makes the review process harder.
> [!WARNING]
> Please avoid force-pushing since it makes the review process harder.
7. Go to the GitHub page for your fork and click the green "Compare & pull request" button.

View File

@@ -3,14 +3,15 @@
The following guidelines are meant to provide a general basis
for the behavior expected of tldr-pages maintainers.
*Note:* This text is a living standard;
that is, it is meant to *describe* the project's maintenance practices,
rather than *prescribe* them.
As a maintainer, you're expected to refer to it for clarification
about the collaborative workflows of the project,
but also to propose changes to it
that you feel would make it more useful
as a guideline for current and future maintainers.
> [!NOTE]
> This text is a living standard;
> that is, it is meant to *describe* the project's maintenance practices,
> rather than *prescribe* them.
> As a maintainer, you're expected to refer to it for clarification
> about the collaborative workflows of the project,
> but also to propose changes to it
> that you feel would make it more useful
> as a guideline for current and future maintainers.
## I. Responding to contributions

View File

@@ -54,7 +54,8 @@ Example:
`krita --fullscreen`
```
> :bulb: The help page can be any documentation/project/tutorial page, not just a man page,
> [!NOTE]
> The help page can be any documentation/project/tutorial page, not just a man page,
> but documentation pages are preferred.
There is a linter that enforces the format above.