Docs on CONTRIBUTING

[YeungOnion]

Not sure how many others we'll be reaching who'll contribute, but I think it would be a good exercise for me to ensure I'm using the same dev environment (or as much as possible) and that I'm on the same page by writing some contribution documentation.

I see to use hatch, and I'll get that via pipx, but what's your development workflow look like and how does that connect to the user workflow - I ask since most contributors will be both.

I imagine that unit testing at this point won't need full workflows, but do we want to use the CMS public example as the "tracer bullet" for a newcomer into interact with the major parts of the workflow (and file links to current implementations) for onboarding?

[kreczko]

You are right, the current docs are a bit vague:
https://fasthep-flow.readthedocs.io/en/latest/installation.html

I've started to draft something, but it never saw the light of day - I will try to put some effort here

My workflow is

• install in a conda environment
• install precommit
• create and run tests via pytest/nox
• commit (runs all other checks)

but do we want to use the CMS public example as the "tracer bullet" for a newcomer into interact with the major parts of the workflow (and file links to current implementations) for onboarding?

No, CMS public example is the first "full" example, but it should not remain the only one:

• hello world
• something in between: simple numpy based analysis, pre-stage for ML (e.g. cleaning up images)
• one simple example per experiment (ideally with public data)
• one advanced example per experiment (end-to-end)

Jim Pivarski had always some good non-HEP examples that are suitable for the "in between" examples:

• NASA's Earth Meteorite Landings dataset
• NASA's Exoplanet dataset
• other open data examples

That said, for the purpose of "phase 0-2", the first list is more than enough.
If you have any other ideas for "in between", please let me know.

@seriksen @m-glowacki Do you have any preferences?