search

monarch-initiative / monarch-documentation

Technical documentation for all Monarch applications, packages, services and related projects.
https://monarch-initiative.github.io/monarch-documentation/
GNU General Public License v3.0
6 stars 0 forks source link

Shall we try to establish, and enforce, a set of standard practice across all Monarch development products? #48

Open matentzn opened 12 months ago

matentzn commented 12 months ago

We have a very diverse set of developers across all orgs involved in Monarch. I am wondering if we can get buy-in from leadership to establish some mandatory rules that apply to all developers funded on Monarch grants for software development. This issue is not about voting on specific issues, the following list is just a sample of the things we could and should be standardising:

  1. Any new python project must use the Monarch Cookiecutter template (which comes with QC etc)
  2. No python project may implement logic to convert between uris and curies outside of the curies package
  3. No code SHOULD enter a PR unless strictly towards solving the issue. Unrelated issues uncovered along the way should be addressed in a separate issue+pr combination
  4. No PR pertaining to a core, support or flagship product should ever go unreviewed (except for HPO :P)
  5. Changes to dosdp pattern files or makefile should be reviewed by a technical person

etc etc. Again, I am not debating the points up there now, just whether it is worth my time to build up a Monarch style guide towards these issues and have all of leadership signing off on it.

cmungall commented 12 months ago

I support this. I think most of the items will be SHOULDs and not MUSTs. The basic idea is that deviations should be intentional (e.g "I need this PR merged now as it it's a fix for a critical bug and the only people able to review it meaningfully are on holiday") rather than accidental (e.g. "I'm using this weird bespoke 3rd party library because I had no idea my colleagues in Monarch had spend 100s of hours thinking about this problem and have come up with a standard solution")

matentzn commented 12 months ago

For sure, mostly SHOULD! And we can really make the intentional deviations part of the document, no problem.