Fixing documentation typo / format

Author: michaelmaillot

CHANGELOG.md

@@ -1,5 +1,15 @@
 # Releases
 
+## 3.20.0
+
+### Fixes
+
+- `PropertyFieldDateTimePicker`: Fixed small typos and a sample in the documentation [#628](https://github.com/pnp/sp-dev-fx-property-controls/pull/628)
+
+### Contributors
+
+Special thanks to our contributor: [Guido Zambarda](https://github.com/GuidoZam).
+
 ## 3.19.0
 
 ## 3.18.0

docs/documentation/docs/about/release-notes.md

@@ -1,5 +1,15 @@
 # Releases
 
+## 3.20.0
+
+### Fixes
+
+- `PropertyFieldDateTimePicker`: Fixed small typos and a sample in the documentation [#628](https://github.com/pnp/sp-dev-fx-property-controls/pull/628)
+
+### Contributors
+
+Special thanks to our contributor: [Guido Zambarda](https://github.com/GuidoZam).
+
 ## 3.19.0
 
 ## 3.18.0

docs/documentation/docs/guides/contributing.md

@@ -27,21 +27,23 @@ Typos are embarrassing! Most PR's that fix typos will be accepted immediately. I
 Before contributing:
 
 - ensure that the **dev** branch on your fork is in sync with the original **sp-dev-fx-property-controls** repository
-    ```sh
-    # assuming you are in the folder of your locally cloned fork....
-    git checkout dev
 
-    # assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo
-    git fetch upstream
+```bash
+# assuming you are in the folder of your locally cloned fork....
+git checkout dev
 
-    # update your local dev to be a mirror of what's in the main repo
-    git pull --rebase upstream dev
-    ```
+# assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo
+git fetch upstream
+
+# update your local dev to be a mirror of what's in the main repo
+git pull --rebase upstream dev
+```
 
 - create a feature branch for your change. If you'll get stuck on an issue or merging your PR will take a while, this will allow you to have a clean dev branch that you can use for contributing other changes
-    ```sh
-    git checkout -b my-contribution
-    ```
+ 
+```bash
+git checkout -b my-contribution
+```
 
 ## DO's & DON'Ts
 

docs/documentation/docs/guides/mpa.md

@@ -4,26 +4,29 @@ The shortest way to prepare your local copy of the project for development and t
 
 ## Install prerequisites
 
-Before you start contributing to this project, you will need Node.js. This project has been tested with the 10.x version of Node.js and the version of NPM that comes with it. You can use [Node Version Manager](https://github.com/nvm-sh/nvm) to switch between different versions of Node.js.
+Before you start contributing to this project, you will need Node.js. This project (current version 3.x) has been tested with the 18.x version of Node.js and the version of NPM that comes with it. You can use [Node Version Manager](https://github.com/nvm-sh/nvm) or [Node Version Switcher](https://github.com/jasongin/nvs) to switch between different versions of Node.js.
 
 ## Get the local version of the project
 
 - fork this repository
 - clone your fork
-- in the command line:
+- in the command line, run the following commands:
   - run `npm install` to restore dependencies
-  - run `gulp serve` to serve your project
-  - Start making your changes
+  - `npm install -g gulp-cli` in order to run `gulp` commands (run `npm list -g gulp-cli` to check if already installed on your machine or not)
+  - `gulp serve` to serve your project (or `npm run serve` if you want to use [`spfx-fast-serve`](https://github.com/s-KaiNet/spfx-fast-serve))
+- Start making your changes
 
 ### Documentation
 
-SharePoint Framework Property Controls uses [MkDocs](http://www.mkdocs.org) to publish documentation pages. See more information about installing MkDocs on your operating system at http://www.mkdocs.org/#installation.
+SharePoint Framework Property Controls uses [MkDocs](http://www.mkdocs.org) to publish documentation pages. See more information about installing MkDocs on your operating system at <http://www.mkdocs.org/#installation>.
 
-Also, documentation uses custom MkDocs theme that should be installed as well. See [Material theme for MkDocs](https://squidfunk.github.io/mkdocs-material/)
+Also, documentation uses custom MkDocs theme that should be installed as well. See [Material theme for MkDocs](https://squidfunk.github.io/mkdocs-material/). Currently, documentation is working with version 3.1.0.
 
 Once you have MkDocs and Material theme installed on your machine, in the command line:
 
 - run `cd ./docs/documentation` to change directory to where the manual pages are stored
 - run `mkdocs serve` to start the local web server with MkDocs and view the documentation in the web browser
 
+For documentation update, we suggest you to use IDE extensions to help you for the writing process. For example, if you're using VS Code, you can install [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) for words spelling and [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) or [learn-markdown](https://marketplace.visualstudio.com/items?itemName=docsmsft.docs-markdown) for Markdown syntax.
+
 ![](https://telemetry.sharepointpnp.com/sp-dev-fx-property-controls/wiki/mpa)

docs/documentation/docs/guides/submitting-pr.md

@@ -2,30 +2,31 @@
 
 We appreciate your initiative and would love to integrate your work with the rest of the project! Here is how you can help us do it as quickly as possible.
 
-- check, that your feature branch is up-to-date. If it's not, there is a risk of merge conflicts or other issues that will complicate merging your changes into the main repository. Refer to these resources for more information on syncing your repo:
+- Check, that your feature branch is up-to-date. If it's not, there is a risk of merge conflicts or other issues that will complicate merging your changes into the main repository. Refer to these resources for more information on syncing your repo:
   - [GitHub Help: Syncing a Fork](https://help.github.com/articles/syncing-a-fork/)
   - [AC: Keep Your Forked Git Repo Updated with Changes from the Original Upstream Repo](http://www.andrewconnell.com/blog/keep-your-forked-git-repo-updated-with-changes-from-the-original-upstream-repo)
   - Looking for a quick cheat sheet? Look no further:
 
-    ```sh
-    # assuming you are in the folder of your locally cloned fork....
-    git checkout dev
+```bash
+# assuming you are in the folder of your locally cloned fork....
+git checkout dev
 
-    # assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo
-    git fetch upstream
+# assuming you have a remote named `upstream` pointing to the official **sp-dev-fx-property-controls** repo
+git fetch upstream
 
-    # update your local dev branch to be a mirror of what's in the main repo
-    git pull --rebase upstream dev
+# update your local dev branch to be a mirror of what's in the main repo
+git pull --rebase upstream dev
 
-    # switch to your branch where you are working, say "issue-xyz"
-    git checkout issue-xyz
+# switch to your branch where you are working, say "issue-xyz"
+git checkout issue-xyz
 
-    # update your branch to update its fork point to the current tip of dev & put your changes on top of it
-    git rebase dev
-    ```
-- submit PR to the **dev** branch of the main repo. PRs submitted to other branches will be declined
-- let us know what's in the PR: is it a new command, bug fix or a minor update in the docs? The clearer the information you provide, the quicker your PR can be verified and merged
-- ideally 1 PR = 1 commit - this makes it easier to keep the log clear for everyone and track what's changed. If you're new to working with git, we'll squash your commits for you when merging your changes into the main repo
-- don't worry about changing the version or adding yourself to the list of contributors in `package.json`. We'll do that for you when merging your changes.
+# update your branch to update its fork point to the current tip of dev & put your changes on top of it
+git rebase dev
+```
+
+- Submit PR to the **dev** branch of the main repo. PRs submitted to other branches will be declined
+- Let us know what's in the PR: is it a new command, bug fix or a minor update in the docs? The clearer the information you provide, the quicker your PR can be verified and merged
+- Ideally 1 PR = 1 commit - this makes it easier to keep the log clear for everyone and track what's changed. If you're new to working with git, we'll squash your commits for you when merging your changes into the main repo
+- Don't worry about changing the version or adding yourself to the list of contributors in `package.json`. We'll do that for you when merging your changes.
 
 ![](https://telemetry.sharepointpnp.com/sp-dev-fx-property-controls/wiki/SubmitPR)

docs/documentation/mkdocs.yml

@@ -1,6 +1,13 @@
 site_name: '@pnp/spfx-property-controls'
 nav:
   - Home: 'index.md'
+  - 'Beta testing': 'beta.md'
+  - Guides:
+    - Overview: 'guides/index.md'
+    - Contributing: 'guides/contributing.md'
+    - 'Minimal Path to Awesome': 'guides/mpa.md'
+    - 'Submitting a PR': 'guides/submitting-pr.md'
+    - 'Migrate v1 to v2': 'guides/migrate-from-v1.md'
   - Controls:
     - PropertyFieldButton: 'controls/PropertyFieldButton.md'
     - PropertyFieldCodeEditor: 'controls/PropertyFieldCodeEditor.md'
@@ -47,11 +54,9 @@ nav:
     - PropertyFieldToggleWithCallout: 'controls/PropertyFieldToggleWithCallout.md'
   - Helpers:
     - PropertyPaneHelpers: 'helpers/PropertyPaneHelpers.md'
-  - 'Beta testing': 'beta.md'
   - About:
     - 'Release notes': 'about/release-notes.md'
     - License: 'about/license.md'
-  - 'Project Guides': 'guides'
 theme:
   name: 'material'
   palette: