Link to contributing and maintainer guides from README

.github/contributing.md

@@ -36,7 +36,7 @@ Issues labelled `good first contribution`.
 For your contribution to be accepted:
 
 - [x] You must have signed the [Contributor License Agreement (CLA)](https://cla-assistant.io/slackapi/bolt-js).
-- [x] The test suite must be complete and pass.
+- [x] The test suite must be complete and pass (see the [Maintainer's Guide](./maintainers_guide.md) for details on how to run the tests).
 - [x] The changes must be approved by code review.
 - [x] Commits should be atomic and messages must be descriptive. Related issues should be mentioned by Issue number.
 
@@ -57,4 +57,4 @@ If the contribution doesn't meet the above criteria, you may fail our automated
 
 ## Maintainers
 
-There are more details about processes and workflow in the [Maintainer's Guide](./maintainers_guide.md).
+There are more details about processes and workflow in the [Maintainer's Guide](./maintainers_guide.md).

.github/maintainers_guide.md

@@ -13,7 +13,7 @@ All you need to work with this project is a supported version of [Node.js](https
 
 ### Testing
 
-This package has unit tests for most files in the same directory the code is in with the suffix `.spec` (i.e. `exampleFile.spec.ts`). You can run the entire test suite using the npm script `npm test`. This command is also executed by Travis, the continuous integration service, for every Pull Request and branch. The coverage is computed with the `codecode` package. The tests themselves are run using the `mocha` test runner.
+This package has unit tests for most files in the same directory the code is in with the suffix `.spec` (i.e. `exampleFile.spec.ts`). You can run the entire test suite using the npm script `npm test`. This command is also executed by GitHub Actions, the continuous integration service, for every Pull Request and branch. The coverage is computed with the `codecov` package. The tests themselves are run using the `mocha` test runner.
 
 Test code should be written in syntax that runs on the oldest supported Node.js version. This ensures that backwards compatibility is tested and the APIs look reasonable in versions of Node.js that do not support the most modern syntax.
 
@@ -26,7 +26,9 @@ The source files are contained in the `docs` directory. They are broken up into
 
 All documentation contains [front matter](https://jekyllrb.com/docs/front-matter/) that indicates the section's title, slug (for header), respective language, and if it's not a tutorial it contains the order it should appear within its respective section (basic or advanced).
 
-To build the docs locally, navigate to the `docs` folder and run `bundle exec jekyll serve`. Make sure you have run `bundle install` to install necessary gems.
+To build the docs locally, you must have [Ruby](https://www.ruby-lang.org/en/) installed. To easily install and manage different Ruby versions, you can use [`rbenv`](https://github.com/rbenv/rbenv). If you use macOS, you can install it via `brew install rbenv`. Hook it up to your shell by running `rbenv init` and following the instructions. Finally, install the required version for building the docs (this version is stored in the `.ruby-version` file) via `rbenv install <version>`.
+
+To build the docs, navigate to the `docs` folder and run `bundle install` to install necessary gems (Ruby dependencies). Run `bundle exec jekyll serve` to start up a local server which will compile documentation source and serve its contents.
 
 #### Adding beta documentation
 When documentation is in a beta state, it requires a new, distinct collection of docs. The process is a little nuanced, so make sure to build the documentation locally to make sure it appears how you expect. To create a new collection:
@@ -44,7 +46,7 @@ When documentation is in a beta state, it requires a new, distinct collection of
 
 1.  Create the commit for the release:
     *  Bump the version number in adherence to [Semantic Versioning](http://semver.org/) in `package.json`.
-    *  Update any dependency versions 
+    *  Update any dependency versions
     *  Confirm tests pass by running `npm test`
     *  Commit with a message including the new version number. For example `v2.2.0`.
     *  Tag the commit with the version number. For example `git tag @slack/bolt@2.2.0`.
@@ -96,7 +98,7 @@ As a maintainer, the development you do will be almost entirely off of your fork
 
 ### Branches
 
-`main` is where active development occurs. 
+`main` is where active development occurs.
 
 When developing, branches should be created off of your fork and not directly off of this repository. If working on a long-running feature and in collaboration with others, a corresponding branch of the same name is permitted. This makes collaboration on a single branch possible, as contributors working on the same feature cannot push commits to others' open Pull Requests.
 
@@ -128,4 +130,4 @@ relevant once again, reopening is great and better than creating a duplicate iss
 
 ## Everything else
 
-When in doubt, find the other maintainers and ask.
+When in doubt, find the other maintainers and ask.

README.md

@@ -100,7 +100,7 @@ In addition to the [`client` property passed to listeners](#making-things-happen
 
 ### Acknowledging events
 
-Some types of events need to be acknowledged in order to ensure a consistent user experience inside the Slack client (web, mobile, and desktop apps). This includes all action, shortcut, view, command, and options requests. Listeners for these events need to call the `ack()` function, which is passed in as an argument. 
+Some types of events need to be acknowledged in order to ensure a consistent user experience inside the Slack client (web, mobile, and desktop apps). This includes all action, shortcut, view, command, and options requests. Listeners for these events need to call the `ack()` function, which is passed in as an argument.
 
 In general, the Slack platform expects an acknowledgement within 3 seconds, so listeners should call this function as soon as possible.
 
@@ -114,7 +114,7 @@ Depending on the type of incoming event a listener is meant for, `ack()` should
 
 *  Legacy message button clicks, menu selections, and slash commands: Either call `ack()` with no parameters, a `string` to to update the message with a simple message, or an `object` to replace it with a complex message. Replacing the message to remove the interactive elements is a best practice for any action that should only be performed once.
 
-* Events API events **do not** need an `ack()` function since they are automatically acknowledged by your app. 
+* Events API events **do not** need an `ack()` function since they are automatically acknowledged by your app.
 
 ## Getting Help
 
@@ -124,3 +124,8 @@ If you otherwise get stuck, we're here to help. The following are the best ways
 
   * [Issue Tracker](http://github.com/slackapi/bolt-js/issues) for questions, bug reports, feature requests, and general discussion related to Bolt for JavaScript. Try searching for an existing issue before creating a new one.
   * [Email](mailto:support@slack.com) our developer support team: `support@slack.com`
+## Contributing
+
+We welcome contributions from everyone! Please check out our
+[Contributor's Guide](.github/contributing.md) for how to contribute in a
+helpful and collaborative way.