Merge branch 'main' into clang-tidy-update

Author: Omotola

.acrolinx-config.edn

@@ -21,7 +21,7 @@
 "
 **More info about Acrolinx**
 
-- [Install Acrolinx locally for VSCode](https://review.docs.microsoft.com/en-us/help/contribute/contribute-acrolinx-vscode)
+- [Install Acrolinx locally for VS Code](https://review.docs.microsoft.com/en-us/help/contribute/contribute-acrolinx-vscode)
 - [Report false positives or issues](https://aka.ms/acrolinxbug)
 
 "}

.github/ISSUE_TEMPLATE/new-c---2017-stl-library-documentation-topic-.md

@@ -0,0 +1,118 @@
+When writing documentation, follow these guidelines:
+
+## General style tips
+
+* Get to the point fast. Be concise and clear.
+* Talk like a person.
+* Simpler is better.
+* Be brief. Give customers just enough information to make decisions confidently. Prune excess words.
+* Break up long sentences.
+* Follow the style of the [Microsoft Writing Style Guide](https://learn.microsoft.com/style-guide/welcome/). If there's a conflict between the following guidelines and the Microsoft Writing Style Guide, ask how to resolve it.
+
+## Grammar
+
+* Use present tense verbs (is, open) instead of past tense (was, opened). For example, "The method returns a value" instead of "The method will return a value."
+* Write factual statements and direct commands. Avoid hypotheticals.
+* Use active voice where the subject performs the action.
+* Write in second person (you) to speak directly to readers.
+* Use gender-neutral language.
+* Avoid multiple -ing words that could create ambiguity.
+* Keep prepositional phrases simple and clear.
+* Place modifiers close to what they modify.
+* Use a conversational tone with contractions.
+* Don't use "we" or "our" to refer to the authors of the documentation.
+* Use the imperative mood for instructions. For example, "Call the method" instead of "You should call the method."
+* Use "might" instead of "may" to indicate possibility. For example, "This method might throw an exception" instead of "This method may throw an exception."
+* Use the Oxford comma in lists of three or more items.
+
+## Capitalization
+
+* Use sentence-style capitalization for everything except proper nouns.
+* Always capitalize proper nouns.
+* Don’t capitalize the spelled-out form of an acronym unless it's a proper noun.
+* Use title-style capitalization for product and service names.
+* Don't use all uppercase for emphasis.
+
+## Numbers
+
+* Spell out numbers for zero through nine, unless space is limited. Use numerals for 10 and above.
+* Spell out numbers at the beginning of a sentence.
+* Spell out ordinal numbers such as first, second, and third. Don't add -ly to form adverbs from ordinal numbers.
+* Number ordered list items all as "1." instead of "1.", "2.", etc. Use bullets for unordered lists.
+
+## Punctuation
+
+* Use short, simple sentences.
+* End all sentences with a period.
+* Use one space after punctuation marks.
+* After a colon, capitalize only proper nouns.
+* Avoid semicolons - use separate sentences instead.
+* Use question marks sparingly.
+* Don't use slashes (/) - use "or" instead.
+
+## Text formatting
+
+* UI elements, like menu items, dialog names, and names of text boxes, should be in **bold** text.
+* Use `code style` for:
+    * Code elements, like method names, property names, and language keywords.
+    * SQL commands.
+    * NuGet package names.
+    * Command-line commands.
+    * Database table and column names.
+    * Resource names (like virtual machine names) that shouldn't be localized.
+    * URLs that you don't want to be selectable.
+    * File names and folders, custom types, and other text that should never be localized.
+* For code placeholders, if you want users to replace part of an input string with their own values, use angle brackets (less than < and greater than > characters) on that placeholder text.
+
+## Headings
+
+* Headings should be in sentence case, not title case. Don't use gerunds in titles.
+* Don't apply an inline style like italic, or bold to headings. But do use inline code style for headings that are code elements, like method names or property names.
+
+## Alerts
+
+* Alerts are a Markdown extension to create block quotes that render with colors and icons that indicate the significance of the content. The following alert types are supported:
+
+    * `[!NOTE]` Information the user should notice even if skimming.
+    * `[!TIP]` Optional information to help a user be more successful.
+    * `[!IMPORTANT]` Essential information required for user success.
+    * `[!CAUTION]` Negative potential consequences of an action.
+    * `[!WARNING]` Dangerous certain consequences of an action.
+
+## Adding links
+
+* Add links to related topics and resources where appropriate. 
+* Links to other documentation articles should be relative, not absolute. Start relative links with `/docs/` and include the `.md` suffix. If you add a link to another page on learn.microsoft.com that's not in this repo, remove https://learn.microsoft.com/en-us from the link.
+* Links to bookmarks within the same article should be relative and start with `#`.
+* Link descriptions should be descriptive and make sense on their own. Don't use "click here" or "this link" or "here".
+* When you are going to refer to another file or an article on the web, use this format: "For more information, see [descriptive name of link](link path)." The exception to this is the See Also links at the end of an article. Those should be markdown links and contain the title of the article you link to as the descriptive portion of the link.
+
+## Adding new files
+
+* If you add a new Markdown file, it should be named in all lowercase with hyphens separating words. Also, omit any filler words such as "the" or "a" from the file name.
+* If you're adding a new Markdown file, the following indicates where it should go the folder structure. If you aren't sure, ask.
+    If the new file is about Linux, put it in the docs/linux folder.
+    If the new file is about the C++ Standard Template Library (STL), put it in the docs/standard-library folder.
+    If the new file is about the C runtime, put it in the docs/c-runtime-library folder.
+    If the new file is about the C++ language, put it in the docs/cpp folder.
+    If the new file is about a C++ feature specific to the Visual Studio IDE, put it in the docs/ide folder.
+    If the new file is about the build process or modules, put it in the docs/build\reference folder.
+    If the new file is about Build Insights, put it in the docs/build-insights folder.
+
+## Images
+
+* Use images only when they add value.
+* Images have a descriptive and meaningful alt text that starts with "Screenshot showing" and ends with ".".
+* Videos have a descriptive and meaningful alt text or title that starts with "Video showing" and ends with ".".
+
+## Numbered steps
+
+* Write complete sentences with capitalization and periods
+* Use imperative verbs
+* Clearly indicate where actions take place (UI location)
+* For single steps, use a bullet instead of a number
+* When allowed, use angle brackets for menu sequences (File > Open)
+
+## Terminology
+
+* Use "Select" instead of "Click" for UI elements like buttons, menu items, links, dropdowns, and checkboxes.

.github/ISSUE_TEMPLATE/new-c---2020-stl-library-documentation-topic-.md

@@ -7,7 +7,7 @@ _themes.MSDN.Modern/
 _themes.VS.Modern/
 
 # Ignore local configuration changes
-.github/
+#.github/
 .openpublishing.buildcore.ps1
 .vscode/