Update best_practices.mdx (#126849)

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

dev_docs/contributing/best_practices.mdx

@@ -9,9 +9,9 @@ tags: ['kibana', 'onboarding', 'dev', 'architecture']
 
 ## General
 
-First things first, be sure to review our <DocLink id="kibDevPrinciples" text="development principles"/> and check out all the available
-platform <DocLink id="kibBuildingBlocks" text="building blocks"/> that can simplify plugin development.
-
+Be sure to follow our <DocLink id="kibDevPrinciples" text="development principles"/>
+and <DocLink id="kibStandards" text="standards and guidelines"/>.
+ 
 ## Documentation
 
 Documentation best practices can be found <DocLink id="kibDocumentation" text="here"/>.
@@ -54,12 +54,28 @@ We use es-lint rules when possible, but please review our [styleguide](https://g
 
 Es-lint overrides on a per-plugin level are discouraged.
 
-## Plugin best practices
+## Using the SavedObjectClient
+
+The <DocLink id="kibCoreSavedObjectsPluginApi" section="def-public.SavedObjectsClient" text="SavedObjectClient" /> should always be used for reading and writing saved objects that you manage. For saved objects managed by other plugins, their plugin APIs should be used instead.
+
+Good:
+```
+const dataView = dataViewStartContract.get(dataViewId);
+```
+
+Bad:
+```
+const dataView = savedObjectsClient.get(dataViewId) as DataView;
+```
+
+## Resusable react components
+
+Use [EUI](https://elastic.github.io/eui) for all your basic UI components to create a consistent UI experience. We also have generic UI components offered from the <DocLink id="kibKibanaReactPluginApi" text="kibana_react" /> plugin and the <DocLink id="kibSharedUXPluginApi" text="shared_ux" /> plugin.
+
+## Don't export code that doesn't need to be public
 
 Don't export <DocLink id="kibPlatformIntro" section="public-plugin-api" text="public APIs"/> without reason. Make your public APIs as small as possible. You will have to maintain them, and consider backward compatibility when making changes.
 
-Add `README.md` to all your plugins and services and include contact information.
-
 ## Re-inventing the wheel
 
 Over-refactoring can be a problem in it's own right, but it's still important to be aware of the existing services that are out there and use them when it makes sense. Check out our <DocLink id="kibBuildingBlocks" text="building blocks"/> to see what high-level services are at your disposal. In addition, our <DocLink id="kibDevDocsApiWelcome" text="API documentation" /> lists additional services.
@@ -120,6 +136,77 @@ There are some exceptions where a separate repo makes sense. However, they are e
 
 It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/main/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
 
+## Licensing
+
+<DocCallOut title="Internal only">
+
+Has there been a discussion about which license this feature should be available under? Open up a license issue in [https://github.com/elastic/dev](https://github.com/elastic/dev) if you are unsure.
+
+</DocCallOut>
+
+## Testing scenarios
+
+Every PR submitted should be accompanied by tests. Read through the <DocLink id="kibDevTutorialTestingPlugins" text="testing plugins tutorial" /> for how to test.
+
+### Browser coverage
+
+Refer to the list of browsers and OS Kibana supports https://www.elastic.co/support/matrix
+
+Does the feature work efficiently on the below listed browsers
+  - chrome
+  - Firefox
+  - Safari
+  - IE11
+
+### Upgrade Scenarios
+  - Migration scenarios- Does the feature affect old indices, saved objects ?
+  - Has the feature been tested with Kibana aliases
+  - Read/Write privileges of the indices before and after the upgrade?
+
+### Test coverage
+  - Does the feature have sufficient unit test coverage? (does it handle storeinSessions?)
+  - Does the feature have sufficient Functional UI  test coverage?
+  - Does the feature have sufficient Rest API coverage test coverage?
+  - Does the feature have sufficient Integration test coverage?
+
+### Environment configurations
+
+- Kibana should be fully [cross cluster search](https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-cross-cluster-search.html) compatible (aside from admin UIs which only work on the local cluster).
+- How does your plugin behave when optional dependencies are disabled?
+- How does your app behave under anonymous access, or with security disabled?
+- Make sure to test your PR in a cloud environment. Read about the <DocLink id="kibDevTutorialCI" section="labels" text="ci:deploy cloud" /> label which makes this very easy.
+
+
+## Backward compatibility
+
+Any time you change state that is part of a Saved Object you will have to write a <DocLink id="kibDevDocsSavedObjectsIntro" section="migrations-and-backward-compatibility" text="migration" />.
+
+Never store state from another plugin in your Saved Objects or URLs unless it implements the <DocLink id="kibDevDocsPersistableStateIntro" text="persistable state interface"/>. Remember to check for migrations when deserializing that state.
+
+If you expose state and you wish to allow other plugins to persist you must ensure it implements the <DocLink id="kibDevDocsPersistableStateIntro" text="persistable state interface"/>. This is very common for `by value` entities, like visualizations that exist on a dashboard but are not part of the visualization library. If you make a breaking change to this state you must remember to register a migration for it.
+
+Saved objects exported from past Kibana versions should always continue to work. Bookmarked URLs should also always work. Check out <DocLink id="kibDevKeyConceptsNavigation" section="specifying-state" text="URL Locators" /> to learn about migrating state in URLs.
+
+## Avoid these common mistakes
+
+### Treating Kibana's filesystem as durable storage
+
+Plugins should rarely, if ever, access Kibana's filesystem directly. Kibana instances are commonly ephemeral and anything written to the filesystem will potentially
+not be there on restart.
+
+### Storing state in server memory
+
+There are generally multiple instances of Kibana all hosted behind a round-robin load-balancer. As a result, storing state in server memory is risky as there is no
+guarantee that a single end-user's HTTP requests will be served by the same Kibana instance.
+
+### Using WebSockets
+
+Kibana has a number of platform services that don't work with WebSockets, for example authentication and authorization. If your use-case would benefit substantially
+from websockets, talk to the Kibana Core team about adding support. Do not hack around this limitation, everytime that someone has, it's created so many problems
+it's been eventually removed.
+
+
+
 ## Security best practices
 
 When writing code for Kibana, be sure to follow these best practices to avoid common vulnerabilities. Refer to the included Open Web