docs: add maintainer onboarding and publish docs

Signed-off-by: dhmlau <dhmlau@ca.ibm.com>

Author: dhmlau

docs/onboard-maintainer/README.md

@@ -0,0 +1,5 @@
+# Maintainer onboarding
+
+- If you identify a community member who fits to be a LoopBack maintainer, go through the [nomination process](maintainer-nomination.md)
+- Once approved, send an email to invite the community member to the maintainer team. [This email template for maintainer invitation](maintainer-invitation-template.md) can be used as a reference
+- Once accepted, follow the steps in the [maintainer onboarding document](maintainer-onboarding.md) 

docs/onboard-maintainer/maintainer-invitation-template.md

@@ -0,0 +1,40 @@
+# Email template to invite potential maintainer
+
+
+### Email subject
+
+Invitation to join the team of LoopBack maintainers
+
+### Email body
+
+Hi _name_,
+
+We really appreciate the work you have contributed to _repo_ and would like to invite you to join our team of LoopBack maintainers.
+
+
+What would that mean for you:
+
+- Greater influence on LoopBack's future direction
+
+- Commit (write) rights to _repo_
+
+- Ability to review and land pull requests, edit/categorize/close issues
+
+- Access to a private Slack channel for LoopBack maintainers
+
+If there is anything else that would make you a more successful maintainer, then let me know and I'll do my best to arrange it for you.
+
+ 
+In return we ask you to follow the existing processes, see http://loopback.io/doc/en/contrib/Governance.html. This means mostly:
+
+- Be nice to others
+
+- Try to reach consensus with other maintainers before making a decision
+
+- Always use pull requests to make code changes
+
+- Honour our current conventions, see http://loopback.io/doc/en/contrib/triaging-pull-requests.html and http://loopback.io/doc/en/contrib/style-guide.html (but feel free to propose changes to these conventions!)
+
+- To avoid possible confusion, we don't have any specific requirements about the amount of time you should spend on the project - just keep working on things that you find important to you, in a pace that suits you. We may ask you to take a look at issues and pull requests related to code you contributed yourself. This is primarily to make sure we don't accidentally break your stuff because of our lack of knowledge, and you can always excuse yourself :)
+
+What do you think?

docs/maintainer-nomination.md …oard-maintainer/maintainer-nomination.mddocs/maintainer-nomination.md renamed to docs/onboard-maintainer/maintainer-nomination.md docs/maintainer-nomination.md renamed to docs/onboard-maintainer/maintainer-nomination.md

@@ -0,0 +1,7 @@
+# Maintainer onboarding checklist
+
+Once a new maintainer accepted to join the maintainers team
+- add them to the private `#loopback-maintainers` Slack channel
+- add them to the [loopback-maintainers team](https://github.com/orgs/loopbackio/teams/loopback-maintainers) in GitHub. If they are part of Technical Steering Committee as well, add them to [loopback-tsc team](https://github.com/orgs/loopbackio/teams/loopback-tsc).
+- add them to the [loopback-openjsf team](https://www.npmjs.com/settings/loopback-openjsf/members) on npmjs.com for publishing npm modules.
+- update the [README](https://github.com/loopbackio/loopback-next/blob/master/README.md#team) with the new member

docs/onboard-maintainer/maintainer-onboarding.md

@@ -1,4 +1,4 @@
-# Publish LoopBack Modules
+# Publish LoopBack Modules in loopback-next repos
 
 ## Pre-requisite
 

docs/publish-modules/README.md

@@ -0,0 +1,53 @@
+# Publish other LoopBack modules 
+
+## Pre-requisite
+
+1. You need to be on the [`loopback-openjsf` organization on npmjs](https://www.npmjs.com/settings/loopback-openjsf/teams), and part of the `developers` team. Contact the TSC memebers for access.
+
+2. Install [`strong-tools`](https://www.npmjs.com/package/strong-tools), we'll be using the `slt-release` command to publish.
+
+## Steps to publish
+
+1. git clone the repo
+2. log into npmjs using `npm login` command
+3. run `slt-release -up <major/minor/patch>`. To determine which of major/minor/patch to choose, see https://semver.org/
+4. after the release, you can run `npm view <module-name>` to check.
+5. when you're done, as best practice, logout of NPM using `npm logout` to mitigate against accidental publishing and token stealing.
+
+
+
+## How to revert the release
+In case you want to revert the release, e.g. release the wrong semver-major/minor/patch, here are the steps:
+
+1. Unpublish from npmjs 
+
+   _Originated from https://www.npmjs.com/policies/unpublish_
+   
+   Run:
+   `npm unpublish <package_name>@<version> to remove a specific version`
+
+   Note: Once package@version has been used, you can never use it again. You must publish a new version even if you unpublished the old one
+   
+   You can verify the package is unpublished by running `npm view <package_name>`. 
+   
+2. Remove git tag
+   
+   _Originated from https://stackoverflow.com/questions/5480258/how-to-delete-a-git-remote-tag_
+   
+   After you've released, a new git tag is created. You can find that out from the repo page > Releases, for example, https://github.com/strongloop/loopback-datasource-juggler/releases.
+   
+   `git push --delete origin <tagname>`
+   If you also need to delete the local tag, use:
+
+   `git tag --delete <tagname>`
+
+3. Revert the changes in `CHANGES.md`
+   
+   - You can check the latest changes by running `git show`. 
+   
+   - To revert, run `git revert HEAD`.
+   
+     Note: you might want to edit the commit message stating that it was released accidentally so that maintainers/users know why we're reverting it.  
+    
+   - Push changes, `git push`. 
+