How is the developer experience on this repo?

[nikhilwoodruff]

This repo has a lot more developers on it recently! Which is great, but I wonder if we could round up common frictions/repo patterns that make it difficult or unfamiliar to use.

I'll go ahead:

• Lack of a clear repeated pattern with tests (when I add a new variable, how should I test it?)

[baogorek]

I was hesitant to merge my changes, so even after I got approvals I stalled because I was not quite sureif I should merge, and now I have a hanging PR that's lower in priority. Some of that is my own propensity to hesitate, but establishing exactly when is merge-time might be helpful.

Like, you get this stamp, you merge right away.

[anth-volk]

A few ideas:

• Tacking onto your testing points, adding some sort of test coverage metric and tracker would be great
• It'd be great if, where possible, stages that don't need to be rebuilt could be cached between builds in order to save time
• I'd love documentation explaining not only how calibration works, but also what calibration is for those of us from a non-data science background
• There are certain tests that run only post-merge; ideally, those should be pre-merge

[PavelMakarchuk]

I think enforcements of documentation would make development for people who are new to the repo a lot more approachable. To use one specific example: for administrative targets which are used - it would be great to have the relevant information such as reference links and dates attached to each target so devs from the -us package can assess whether those seem sensible or if we need updating

[baogorek]

I owe some documentation as part of my contract, so I'll make sure to reference this issue when I get back to it. Definitely don't hesitate to drop documentation TODOs below. The targets are a must.