chore:(docs) Archive the wiki 🎉 (microsoft#31202)

docs/react-wiki-archive/API-Documentation.md

@@ -0,0 +1,136 @@
+# Documenting Fluent UI
+
+This content only applies to [documentation site](https://developer.microsoft.com/en-us/fluentui) for `@fluentui/react` version 7/8 (formerly `office-ui-fabric-react`) and Fluent UI Android/iOS/etc. (`@fluentui/react-northstar` and `@fluentui/web-components` currently have separate documentation sites.)
+
+- [Documenting components](#documenting-components)
+- [Writing Markdown documentation for the website](#writing-markdown-documentation-for-the-website)
+
+## API documentation
+
+`@fluentui/react` 7/8 uses [API Extractor](API-Extractor) and the custom [`@fluentui/api-docs` package](https://github.com/microsoft/fluentui/tree/master/packages/api-docs) (formerly `@uifabric/api-docs`) to generate documentation which shows up in the [Controls section](https://developer.microsoft.com/en-us/fluentui#/controls/web) of our website as well as in the legacy demo app at [aka.ms/fluentdemo](http://aka.ms/fluentdemo).
+
+Note that all the API documentation features described below will only work on doc comments `/** like this */` (multiline is fine).
+
+### Top-level doc comments
+
+For types or components which should be included on the website, be sure to include a `{@docCategory PageName}` tag in the top-level doc comment for each type which should be documented.
+
+If the type is related to a specific component, `PageName` should be the name of the component. Otherwise, you can use either the name of the type or a general category that it falls under, such as `MergeStyles`. If the `PageName` doesn't match any of the known component page names, it will be put under the References section in the website sidebar.
+
+For example, if you wanted `ISliderProps` to show up on the 'Slider' page, it would look like the following ([see it live here](https://developer.microsoft.com/en-us/fabric#/controls/web/slider#ISliderProps)):
+
+```tsx
+/**
+ * {@docCategory Slider}
+ */
+export interface ISliderProps {
+```
+
+This should work automatically for `@fluentui/react` and the packages it consumes. If the API is in a newer package, you should check [this file](https://github.com/microsoft/fluentui/blob/master/packages/api-docs/config/api-docs.js) to verify that the package is included (and add it if not).
+
+Note that top-level doc comments will be rendered as markdown on the website. If it's an especially long/detailed comment which includes headings, **headings must start at level 4** to appropriately nest within the website.
+
+### Limitations
+
+Documenting the following API types on the website is **supported**:
+
+- Interfaces
+- Type aliases
+- Classes
+- Enums
+
+These API types are **not supported** currently:
+
+- Functions (including function components)
+- Constants
+
+### Prop comments
+
+Individual props in interfaces and types have limited support for markdown rendering, due to performance concerns. Currently just inline code blocks (backticks) are supported.
+
+API Extractor has a particular format required for certain types of doc comments and will fail at build time if this format is not followed. There are also a few suggested best practices.
+
+<table>
+<tr>
+<th></th>
+<th>Good</th>
+<th>Bad</th>
+</tr>
+<tr>
+<td><code>@param</code> tags must include a dash and not contain type information</td>
+<!-- KEEP EXAMPLES SHORT - otherwise it makes the page scroll horizontally -->
+<!-- good -->
+<td><pre lang="ts">
+/**
+ * @param myParam - Description here
+ */
+</pre></td>
+<!-- bad -->
+<td><pre lang="ts">
+/**
+ * @param myParam Description here
+ * @param {number} myParam Description here
+ */
+</pre></tr>
+<tr>
+<td>Special characters which have meaning in TSDoc (e.g. <code>@ > { }</code> etc.) must be escaped with backslashes or backticks</td>
+<!-- KEEP EXAMPLES SHORT - otherwise it makes the page scroll horizontally -->
+<!-- good -->
+<td><pre lang="ts">
+/**
+ * Comment about `>` and `{`.
+ * As of version \>= 1.0.0.
+ */
+</pre></td>
+<!-- bad -->
+<td><pre lang="ts">
+/**
+ * Comment about '>' and '{'.
+ * As of version >= 1.0.0.
+ */
+</pre></td>
+</tr>
+<tr>
+<td><code>@deprecated</code> tags must include a deprecation message</td>
+<!-- KEEP EXAMPLES SHORT - otherwise it makes the page scroll horizontally -->
+<!-- good -->
+<td><pre lang="ts">
+/**
+ * @deprecated Use `foo` instead.
+ */
+</pre></td>
+<!-- bad -->
+<td><pre lang="ts">
+/**
+ * Deprecated. Use `foo` instead.
+ * @deprecated
+ */
+</pre></td>
+</tr>
+<tr>
+<td>Default values should be indicated by <code>@defaultvalue</code> tags (<code>@default</code> and <code>@defaultValue</code> also work)</td>
+<!-- KEEP EXAMPLES SHORT - otherwise it makes the page scroll horizontally -->
+<!-- good -->
+<td><pre lang="ts">
+/**
+ * @defaultvalue 'hello world'
+ */
+</pre></td>
+<!-- bad -->
+<td><pre lang="ts">
+/**
+ * Default is 'hello world'
+ */
+</pre></td>
+</tr>
+</table>
+
+### More details about the `@fluentui/api-docs` package
+
+The `@fluentui/api-docs` (previously `@uifabric/api-docs`) package takes the api.json files generated by [API Extractor](API-Extractor) and splits them up into individual page.json files to populate both component pages and (new) references pages. These page.json files live in `@fluentui/api-docs`.
+
+Generally, this tool is used on `@fluentui/react` and its dependencies (`@fluentui/react-northstar` uses a different approach). You can see or update the full list of included packages in [this file](https://github.com/microsoft/fluentui/blob/master/packages/api-docs/config/api-docs.js).
+
+## Writing Markdown documentation for the website
+
+See the [Markdown documentation](Markdown-documentation) page for tips on authoring markdown files such as component overviews/best practices and other website content.

docs/react-wiki-archive/API-Extractor.md

@@ -0,0 +1,17 @@
+### What is API Extractor?
+
+[API Extractor](https://api-extractor.com/) generates an api.md file containing the public API for a package. `@fluentui/react` and related packages as well as `@fluentui/web-components` use API Extractor to ensure that API changes must be reviewed before being merged into master. (`@fluentui/react-northstar` and related packages do not use API Extractor as of writing.)
+
+### Build Tasks
+
+As part of a package's build process, the api-extractor task checks the package's public API with the package's auto-generated .api.md file.
+
+If building locally, the API file will be updated automatically (in `7.0` and `master`). Be sure to commit the updates with your other changes!
+
+In PR builds, the task will fail if it detects missing API file updates.
+
+(Previously it was necessary to run a separate command `yarn update-api` to update the API files, but we decided to streamline this and do the update automatically as part of the build instead.)
+
+### API Extractor code requirements
+
+See the [API Documentation page](API-Documentation#prop-comment-requirements).

docs/react-wiki-archive/Advanced-auto-merge.md

@@ -0,0 +1,58 @@
+You can give the bot commands to customize how the bot assists you with merging your pull request when all merge policies pass.
+
+To customize the auto-merge parameters, @ mention the bot **(e.g. `@msft-fluent-ui-bot`, `@msft-github-bot` or `@msftbot` depending on the bot identity providing auto-merge capabilities)** and provide your instruction in English. Note that for all scenarios below, pre-configured merge policies at the GitHub level must still be satisfied (i.e. the bot will never bypass merge policies for you). Note that you must be a contributor - the bot will ignore all commands given by non-contributors.
+
+---
+
+At this time, the bot supports the following scenarios:
+
+### Requiring a specific, minimum number of approvals
+
+Examples of what to say (illustrative, not prescriptive nor exhaustive):
+
+- > Only merge this pull request if it has 2 approvals.
+- > require 3 sign offs.
+- > Please make sure there are at least two approving reviews.
+
+### Requiring an approval from a specific person
+
+Examples of what to say (illustrative, not prescriptive nor exhaustive):
+
+- > make sure @cliffkoh has a chance to review before you merge
+- > do not merge unless @cliffkoh approves.
+
+### Requiring approvals from multiple people
+
+Examples of what to say (illustrative, not prescriptive nor exhaustive):
+
+- > require sign-offs from @kkjeer and @JasonGore
+- > hold this pr until all of the following approve: @kkjeer, @JasonGore, @dzearing
+
+### Requiring approvals from one of several people
+
+Examples of what to say (illustrative, not prescriptive nor exhaustive):
+
+- > make sure @kkjeer, @dzearing or @JasonGore gets to approve
+- > require approvals from any one of the following: @kkjeer, @JasonGore, @dzearing
+
+### Changing the time the pull-request is held open before the bot merges the pull request on your behalf
+
+Examples of what to say (illustrative, not prescriptive nor exhaustive):
+
+- > hold this pr for the next 2 hours
+- > please wait 1 more day before merging this
+- > delay merging this pull request for 2 hours 30 mins
+
+---
+
+Note that the examples above of what to say are only meant to be illustrative and not definitive.
+
+Additionally, if the bot has misinterpreted you or you have changed your mind, you can express such an intent with a phrase like "nevermind" or "forget what I just told you".
+
+### Enforcement of policies
+
+on April 18th 2023 `auto-merge.config.enforce` started to block all PR's (it never ran/finish).
+
+As we use github automerge funcionatity anyways we removed it from required status checks to unblock contributors and use github build-in features.
+
+~Enforcement of auto-merge comments is handled by the `auto-merge.config.enforce` status check. It's intended to run for each PR and automatically succeed if no AutoMerge policies apply. If this stops working, contact the bot team (check internal wiki for contact info).~

docs/react-wiki-archive/BETA-Release.md

@@ -0,0 +1,81 @@
+# React Components for Beta
+
+### Beta quality controls required (in @fluentui/react-components)
+
+_(Phase 1 & 2)_
+
+- Accordion
+- Avatar
+- Badge
+- Button (and variants MenuButton , ToggleButton`)
+- Icon
+- Link
+- Divider
+- FluentProvider
+- Menu
+- Popover
+- Text
+- Tooltip
+
+**Additional to include in the beta release if ready before release.**
+
+_(Phase 3 - Control candidates to be considered by the team as extra)_
+
+- Label
+- Checkbox
+
+## Browser support matrix for beta
+
+Fluent UI React supports many commonly used web browsers such as Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge. For browsers outside of this matrix, proper behavior of the components may be good but is not guaranteed.
+
+| Browser                             | Supported | Not supported |
+| ----------------------------------- | --------- | ------------- |
+| Microsoft Edge Chromium             | X         |               |
+| Microsoft Edge Legacy               |           | X             |
+| Internet Explorer 11                |           | X             |
+| Internet Explorer 10                |           | X             |
+| Internet Explorer 9                 |           | X             |
+| Google Chrome (latest 2 versions)   | X         |               |
+| Mozilla Firefox (latest 2 versions) | X         |               |
+| Apple Safari (latest 2 versions)    | X         |               |
+| **Mobile**                          |
+| Edge Chromium on Mobile             | X         |               |
+| Google Chrome on Mobile             | X         |
+| iOS Safari (latest version)         | X         |               |
+| Android Safari (latest version)     | X         |               |
+
+Beta packages are the first official version available. This means that the API has not been examined beyond initial implementation. Beta packages may or may not have documentation, however they have had a basic level of testing across a number of different devices.
+
+We will not be fixing bugs in beta unless there is a high priority partner escalation that will cause a legal problem. Follow-up work that include (fixes, tests) is scheduled After Beta.
+
+## Definition of Done for Beta
+
+1. **Design Spec:**
+   - [x] a) Signed Off.
+2. Engineering Spec:
+   - [x] a) Signed Off
+3. **Individual component package is tagged:**
+   - [x] a) Has the "beta" tag on it (or the correct semver thing on it)
+4. **Component must be in the suite package:**
+   - [x] a) i.e. @fluentui/react-components
+5. **Component must have a Storybook story that includes at least the following:**
+   - [x] a) Component name and description
+   - [x] b) At least one code example - Code example should include all a11y/aria props if needed. In the past, our fluent examples didn't set things like aria-label etc. So, if there are a11y patterns, we would want folks to copy and paste from our examples that should be in.
+   - [x] c) Output of the API - Should be easily done with the Control Add-in
+   - [x] b) [Optional] A link that points to known issues or bugs with the component on GitHub.
+6. **Passes all conformance tests:**
+   - [x] a) Passes all the current/required testing: i.e. Regression, bundling, unit tests..
+7. Component has been tested. against our Browser Matrix:
+   - [x] a) See above
+8. **Supports a11y:**
+   - [x] a) High Contrast Mode
+   - [x] b) Narrator - As defined by our AT/Browser Matrix (see above)
+   - [x] c) Keyboarding
+9. **Supports Design Tokens/Theming:**
+   - [x] a) Light Mode
+   - [x] b) Dark Mode
+   - [x] c) Supports all current out of the box Themes
+10. **Supports Build-time CSS optimizations:**
+    - [x] a) Supports the current CSS optimizations we have in place.
+11. **Supports SSR:**
+    - [x] a) Supports the current SSR test we have in place.

docs/react-wiki-archive/BestPractices/Accessibility.md

@@ -0,0 +1,29 @@
+This document describes our policies and methods for supporting accessibility.
+
+## Colors
+
+Default color choices should conform to contrast requirements as laid out in [WCAG 2.0](https://www.w3.org/TR/WCAG20/) level AA recommendations as laid out in section 1.4.3.
+
+## High Contrast
+
+We best support high contrast in Microsoft Edge and Internet Explorer 11. Mozilla Firefox is also supported to the extent possible barring technical constraints. Read on for more details.
+
+The recommended approach is to use the semantically correct elements to match your scenario. For example, use a `<button>` element for a Button and not a `<div>`. Sometimes, you'll have to use a similar, but not exactly right, element. For example, when making a custom checkbox, you can wrap it in a `<button>` element. This will cause it to pick up the correct colors in all three supported browsers.
+
+As a backup approach, high contrast-specific colors can be manually applied in CSS under the `-ms-high-constrast` media query. This approach should ONLY be used in complex scenarios which can't be represented by standard elements, since it only works in Microsoft Edge and Internet Explorer.
+
+In this case, colors should be chosen only from the [system colors](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors) palette, and only applied under the `-ms-high-constrast` media query. System colors should only be used under the media query (rather than unconditionally) because the actual corresponding colors are unlikely to match design specifications when high contrast is off.
+
+Note that background images can disappear in high contrast mode. Any icons or images that are required for functionality must not be background images.
+
+In high contrast mode, color should not be the only means of conveying feedback. A transparent border or outline will appear in high contrast mode, a useful way of denoting focus without affecting non-high contrast visual design.
+
+## Screen Reader
+
+Follow recommended guidelines using [ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) to insure the best support for screen readers. Where necessary, add in extra text only visible to the screen reader for descriptions and directions, by positioning it off screen.
+
+Our primary support scenario is Microsoft Edge with Windows Narrator.
+
+## Keyboard and Focus
+
+@todo

docs/react-wiki-archive/BestPractices/Advanced-Usage.md

@@ -0,0 +1,29 @@
+## Notes on module vs path-based imports
+
+We highly recommend using Webpack 4+. If you use Webpack 4 or Rollup.js, you can take advantage of tree-shaking to create smaller bundles. This allows you to imports the parts you need in a natural way:
+
+```typescript
+import { Button } from '@fluentui/react'; // or office-ui-fabric-react in earlier versions
+```
+
+This import will include the Button, plus the dependent modules. It should not include any modules that are unrelated.
+
+## For Webpack < 4 or Browserify
+
+If you are using a non-tree-shaking bundler, you may accrue larger bundle sizes by importing from the package entry point `@fluentui/react` (or `office-ui-fabric-react` in earlier versions). By default bundlers will include every module referenced from that entry point, even if you don't use them.
+
+To address this friction, we also offer "top level imports" which help scope the graph to only the component and its dependencies.
+
+```typescript
+import { Button } from '@fluentui/react/lib/Button';
+import { Dropdown } from '@fluentui/react/lib/Dropdown';
+import { List } from '@fluentui/react/lib/List';
+```
+
+For a full list of top level imports, see the source here:
+
+https://github.com/microsoft/fluentui/tree/master/packages/@fluentui/react/src
+
+## Using an AMD bundler like r.js
+
+If your project relies on AMD modules, they are dropped in the lib-amd folder. You will need to set up your bundler to handle the imports correctly. This may require you to symlink or copy the folder into your pre-bundle location.