adding content for maintainer role

maintainerRole.md

@@ -20,25 +20,28 @@ This is okay too. Maintaining the minimum bar helps ensure the consumers of
 the list find value in it and some of them eventually add their own 
 contributions.
 
-
 ## Tasks
 
-Maintainers tasks for this repository are either approving pull requests, 
+Typical maintainer tasks for this repository include approving pull requests, 
 submitting their own contributions like everyone else, and handling 
 questions about new features. 
 
 ### Approving Pull Requests
 
 The bulk of the maintainers task is about approving pull requests. 
 
-#### When to approve
+#### When to approve an item as "Awesome" that has been submitted in a pull request
 
-What to check for is described in the contribuging.md and awesome.md files.
+The characteristics that are required to be an "awesome" open source geoscience
+resource is described in the [contributing.md](/contributing.md) 
+and [awesome.md](/awesome.md) files.
 
 Additionally, there are cases where a maintainer will want to attempt to 
-run the program themselves. This is not always required, but 
+run a program mentioned in a pull request themselves. 
+This is not always required, but 
 sometimes seems appropriate if the "installation" or "how to use" 
-instructions are unusually sparse. In the past, this has caught
+instructions are sparse or suggestive of a single operating system. 
+In the past, this has caught
 issues that prevented new users from using the project who work on a different
 operating system than the contriutor. 
 
@@ -48,43 +51,48 @@ Sometimes there are competing pull requests that conflict with one another.
 This can require a maintainer to resolve the merge conflict. 
 For instructions on how to "fix merge conflict" on the web interface for 
 GitHub see 
-[GitHub's fixing merge conflict instructions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)
+[GitHub's fixing merge conflict guidelines](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)
 
 #### CI/CD Automation test failture
 
 Please read the ["How to fix automation problems"](contributing.md/#how-to-fix-automation-problems) for instructions on how to fix problems
 related to the TravisCI continuous improvement tooling that runs with
 each pull request. 
 
-The most common issue here is just that some link that used to work 
-either 404s or redirects now. To fix these issues, use a search engine
-to find the new link address. 
-If that resource being linked to has disappeared, it may mean its time to 
-delete a previous contribution. It is often easiest to do this using the 
-"edit this file" button as described in the contributing.md file.
+The most common reason for a pull request to not be immediately 
+mergable is a failure in the Travis CI (continuous integration) 
+script related to links in the README.md.
+Links that used to work can 404 or redirect from their original 
+URL to a new URL. In both cases, this will cause the CI to fail.
+
+To fix these issues, use a search engine
+to look for a new link address if it exists. 
+If that resource being linked to has disappeared entirely, it 
+may mean its time to delete a previous contribution that includes the link. 
+
+It is often easiest to do these types of fixes using the 
+"edit this file" button as described in 
+the [contributing.md](/contributing.md) file.
 
 ### Handling new feature requests and vision clarification
 
 Rarely, the maintainers also discuss new feature requests. 
 This has included new sections, like datasets, as well as a request 
 for a DOI for the awesome list repository. 
-
 These conversations mostly take place in issues. For longer conversations 
 or for expanding the scope of who is included, it can also be useful
 to post a question on the "Open Geoscience" channel in the Software Underground mattermost channel. 
 
-## How response do maintainers need to be?
+## How responsive do maintainers need to be?
 
-Faster is always better as it makes people feel more included, 
-but traditionally this repository has been
+Faster is always better as it makes people feel more included to get 
+a fast response, but traditionally this repository has been
 managed in a very asynchronous manner with pull requests often getting 
-responses in 1-2 weeks and sometimes unfortunately longer.
+responses in 1-2 week range and sometimes unfortunately significantly longer.
 We should probably try to reduce this time to first response.
 
-
 ## Who, How, and Why be a maintainer of this repository?
 
-
 ### Who can be a maintainer?
 
 Anyone how has a record of participation in the Software Underground 
@@ -102,17 +110,23 @@ Select the issue template called "maintainer_application"
 and ping all the members of the 
 [awesome GitHub team](https://github.com/orgs/softwareunderground/teams/awesome)
 like ` @justinGOSSES , @leouieda, etc.` after you submit the issue.
+One of them will reach our and/or add you to the
+[awesome GitHub team](https://github.com/orgs/softwareunderground/teams/awesome).
 
 #### Keeping track of new issues and pull requests
 To be a maintainer, you just need to make a good faith effort to 
 respond to new issues and pull requests on this repository.
 Once you are a maintainer, it is recommended, you click the 
 watch button right next to the fork button the main page of the 
 [repository](https://github.com/softwareunderground/awesome-open-geoscience)
+This will put any new issues or pull requests you haven't visited
+in your GitHub noticiations que.
 
 You'll also likely want to make use of the GitHub notification page if you 
 don't already. A direct link to new issues and pull requests limited to 
 this repositories is [https://github.com/notifications?query=repo%3Asoftwareunderground%2Fawesome-open-geoscience](https://github.com/notifications?query=repo%3Asoftwareunderground%2Fawesome-open-geoscience)
+If you don't visit the GitHub notifications page often, you might want
+to set a reminder to double check nothing has been missed.
 
 ### Why be a maintainer?
 
@@ -130,6 +144,7 @@ are low. There is no production service to break or be "down".
 
 #### Put it on your resume
 
+While the stakes are low, the impact is high.
 This repository is one of the most starred repositories on GitHub 
 under the 'geoscience' topic, Being a maintainer on this resume 
 is something that one can list on