Collaborate and document best practices for GH actions, automated testing, etc.

[sierra-moxon]

@turbomam @sujaypatil96 @jfy133 - would you all be interested in working on a style guide with me for the software stacks and control mechanisms we use to maintain this repository?

This PR is great: #898 in adding linting to our automated actions! I want to document the best practices used here as a first step.

Some possible discussion topics:

• Do we favor Make, GH actions, poetry/python control mechanisms to trigger continuous integration checks.
• Where are the boundaries that we can provide to new developers in terms of the distribution of tasks between these mechanisms? e.g. should we use bash code within GH actions when we need to extend an existing task? Or do we use a script in the repo itself?
• Where do automated tests (in python) fit in?
• How does development proceed locally to test things automated in GH Actions before we open PRs?

I'm sure there are other topics :).

I can share a couple of resources in other projects, but happy for other ones to review as well:

1. best practices/style that our group uses in other repos (this is an evolving standard b/c software always evolves but it gives us a place to start): https://berkeleybop.github.io/best_practice/
2. LinkML cookiecutter (has its own issues/challenges but sets up a boilerplate with some handy conventions): https://github.com/linkml/linkml-project-cookiecutter

[jfy133]

I would be happy and motivated to participate!
It would help a lot with the development of the MInAS related extensions

I half started sort of a tutorial along those lines (or at least where the styleguide would be referred to) here: #897, where essentially I want to run MInAS as a parallel 'MIxS' project so it is extremely easy to merge into the main project when approved.