Proposal to get more maintainers

[JustinGOSSES]

Summary of our potential maintainer sustainability problem:

Looking at the contributions graph data: https://github.com/softwareunderground/awesome-open-geoscience/graphs/contributors confirms that I've become the main source of pull request approvals, though @amoodie and @banesullivan have also done some approvals. For a couple reasons, I would like to see more diverse pull request approvals. One is the bus factor. The term bus factor refers to what happens if someone gets hit by a bus tomorrow.

Hypothesized Social Dynamics:

I suspect there's a couple things going on to cause this pattern.

• I can sometimes be quick to jump on easy pull-request approvals as I'm on github for work and non-work reasons most days. This unfortunately takes away opportunities from others to make quick approvals.
• It can be less than obvious whether to approve inclusion on the list for early projects that lack a long record of community engagement as shown by stars, forks, etc. To figure out whether to approve those projects often takes installing them and going through an example or two to make sure they work and do what they say they do.
  • For newbies, they might think doing this work requires someone more experienced?
  • For more experienced folks, they can sometimes be less interested in messing with code they're not going to use?

Maintainer Tasks Before Pull Request Approval:

For clarity, I'll summarize the typical maintainer tasks related to pull requests.

• Go through the checklist as the user fills it out in the pull-request and see if there is anything not-checked there that is critical.
• Go to the README or project page of the project and see if there is pre-existing high levels of engagement as demonstrated by forks, stars, issues, and pull-requests that seem to come from outside the core owners group. If so, probably can go ahead and approve.
• If the project is new and lacks an existing community, it might still be awesome, but this requires more work. At a minimum, the maintainer should (1) make sure the code is installable (2) run a few examples (3) determine if there's a reasonable chance the functionality of the code is elegant and broad enough to be useful to others.

Rough Proposed Solution:

• Move to have at least 3 listed "Current Maintainers" on the README.
• Add a "How to be a Maintainer" markdown file linked to from the CONTRIBUTING.md file that explains the tasks of the maintainers and sets some base expectations in terms of:
  • X days after a pull-request is submitted, there should be some response in the thread.
  • Maintainers can let each other know they're going to be "off" for a month or quarter due to other responsibilities.
  • Any maintainer who responds to more than 75% of the pull requests, should perhaps consider making space for others and how to to about doing that.
  • Plus some suggestions on setting up GitHub notifications such that PRs on the awesome-open-geoscience repository do not get lost in the shuffle.
• Pitch being a listed maintainer as:
  • Ideal for newbie and intermediate coders.
  • A learning opportunity where you get to try out new code.
  • A learning opportunity for what is involved in being a project maintainer, but with relatively low stakes and low complexity.
  • Something people can list on their resume if they'd like.
• Source listed maintainers from:
  • Mention the need in CONTRIBUTING file and README.
  • SoftwareUnderground Slack.
  • Ping previous contributors in last 3 years in an announcement issue.

NOTE: This is a quick proposal. Fee free to offer modifications, additions, or completely different takes.

[JustinGOSSES]

I'm going to risk being rude and ping a few people who have spent some time on this repository who I would expect may have thoughts just as a I know otherwise the onslaught of GitHub notifications can hide things. @amoodie @EvanBianco @prisae @JesperDramsch @banesullivan @mycarta

[prisae]

Thanks for writing this down @JustinGOSSES. I am hardly active at all I have to admit. Would a #AwesomeOpenGeoscience chanel in the Swung-Slack help to ping/push people, or just be yet another distraction? I am not sure myself.

Either way, I think to post it in #general or in #open-geoscience trying to find additional maintainers would definitely be a good idea!

[JustinGOSSES]

Having a separate Slack channel is an interesting idea. It might help as back channel where maintainers can say "can't take this one" or we need someone with experience in X?

On one hand, I like to keep all discussion in one place. On other hand, a Slack channel is going to encourage certain discussion that will not happen in issues, which tend to be more formal & controlled.

There's a channel in SoftwareUnderground for welly & lasio things. I'll ask in there for feedback.

[JustinGOSSES]

It occurred to me during a recent PR that I figured out where to go to figure out what links have broken a PR, which can be not at all obvious for a new maintainer. As part of this issue, it might help to have documentation for (1) how to fix merge conflicts and (2) where to find out what links are the problems when links breaking stops the PR.

This is what I put in a PR today and could be used as a starting point for documentation:

I clicked on the area that says DETAILS next to .github/workflows/link_checker.yml / linkChecker (pull_request) Failing after 27s then clicked on Lychee Link Checker then looked at the bottom of that output, where I found the message below:

[README.md]: ✗ [404] http://fuzzylas.appspot.com/ | Network error: Not Found ✗ [404] https://www.equinor.com/en/what-we-do/digitalisation-in-our-dna/volve-field-data-village-download.html | Network error: Not Found