updated release steps in maintainers guide

.github/maintainers_guide.md

@@ -19,7 +19,7 @@ You should also make sure you have the latest versions of `pip`, `setuptools`, `
 
 On macOS, the easiest way to install these tools is by using [Homebrew](https://brew.sh/) and installing the `python`
 and `python3` packages. Some of the above packages are preinstalled and you can install the remaining on your own:
-`pip install virtualenv wheel twine tox && pip3 install virtualenv twine tox`.
+`pip install virtualenv wheel twine tox sphinx && pip3 install virtualenv twine tox sphinx`.
 
 ## Tasks
 
@@ -40,15 +40,21 @@ You can generate the documentation by running `tox -e docs`.
 ### Releasing
 
 1.  Create the commit for the release:
-    *  Bump the version number in adherence to [Semantic Versioning](http://semver.org/) in `slackclient/version.py`.
-    *  Commit with a message including the new version number. For example `1.0.6`.
+
+    - Bump the version number in adherence to [Semantic Versioning](http://semver.org/) in `slackclient/version.py`.
+    - Add a description of changes to the Changelog in `docs-src/changelog.rst`
+    - Build the docs with `./docs.sh`.
+    - Commit with a message including the new version number. For example `2.5.0`.
+    - Push the commit to a branch and create a PR to sanity check.
+    - Merge in release PR.
+    - Create a git tag for the release. For example `git tag 2.5.0`.
+    - Push the tag up to github with `git push origin --tags`
 
 2.  Distribute the release
-    *  Build the distribtuions: `python setup.py sdist bdist_wheel`. This will create artifacts in the `dist` directory.
-    *  Publish to PyPI: `twine upload dist/*`. You must have access to the credentials to publish.
-    *  Create a GitHub Release. You will select the commit with updated version number (e.g. `1.0.6`) to assiociate with
-       the tag, and name the tag after this version (e.g. `1.0.6`). This will also serve as a Changelog for the project.
-       Add a description of changes to the Release. Mention Issue and PR #'s and @-mention contributors.
+
+    - Build the distribtuions: `python setup.py sdist bdist_wheel --universal`. This will create artifacts in the `dist` directory.
+    - Publish to PyPI: `twine upload dist/*`. You must have access to the credentials to publish.
+    - Create a GitHub Release. You will select the commit with updated version number (e.g. `2.5.0`) to assiociate with the tag, and name the tag after this version (e.g. `2.5.0`). This will also serve as a Changelog for the project. Add a description of changes to the Release. Mention Issue and PR #'s and @-mention contributors.
 
 3.  (Slack Internal) Communicate the release internally. Include a link to the GitHub Release.
 
@@ -75,18 +81,18 @@ versions.
 
 Labels are used to run issues through an organized workflow. Here are the basic definitions:
 
-*  `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been
-   documented and the issue has been reproduced.
-*  `enhancement`: A feature request for something this package might not already do.
-*  `docs`: An issue that is purely about documentation work.
-*  `tests`: An issue that is purely about testing work.
-*  `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information.
-*  `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues.
-*  `question`: An issue that is like a support request because the user's usage was not correct.
-*  `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number.
-*  `security`: An issue that has special consideration for security reasons.
-*  `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known.
-*  `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number.
+- `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been
+  documented and the issue has been reproduced.
+- `enhancement`: A feature request for something this package might not already do.
+- `docs`: An issue that is purely about documentation work.
+- `tests`: An issue that is purely about testing work.
+- `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information.
+- `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues.
+- `question`: An issue that is like a support request because the user's usage was not correct.
+- `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number.
+- `security`: An issue that has special consideration for security reasons.
+- `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known.
+- `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number.
 
 **Triage** is the process of taking new issues that aren't yet "seen" and marking them with a basic level of information
 with labels. An issue should have **one** of the following labels applied: `bug`, `enhancement`, `question`,
@@ -97,4 +103,4 @@ reopening is great and better than creating a duplicate issue.
 
 ## Everything else
 
-When in doubt, find the other maintainers and ask.
+When in doubt, find the other maintainers and ask.