html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue https://github.com/pydata/xarray/issues/4361#issuecomment-1483122791,https://api.github.com/repos/pydata/xarray/issues/4361,1483122791,IC_kwDOAMm_X85YZqhn,14808389,2023-03-24T16:58:09Z,2023-03-24T20:24:31Z,MEMBER,"that looks like a good start, thanks. I wonder if we should change the structure to start with an overview, then link to in-depth guides (just throwing out ideas): 1. project structure - code - docs - packaging (?) - automation 2. high-level description of a typical workflow (just list the steps and link to relevant documentation): - setup environment - create branch - edit files - run tests / build docs / run doctests (plus point to CI: for small changes no need to build manually) - commit - push to fork - create PR - what to do for very short changes (e.g. typo fixes) 3. set up environments (purpose: code including doctests, docs) - install dependencies (including special things to do for each OS) - install xarray 4. code standards and conventions 5. tests 6. typing 7. docstring conventions - format: numpydoc - examples (doctests) - see also 9. how to run tests 10. how to build docs 11. how to run doctests 12. special stuff when committing - `pre-commit` (and the `pre-commit-ci` bot) - commit message tags for controlling CI 13. PR title and message (short section on what to put into the PR description / title) If that would be easier to follow, we could also split 2) into multiple parts: workflow for code changes (including doctest), workflow for documentation changes. And since we most likely will never be the best source for documentation on general git / github, try to link to other sources like https://docs.github.com or https://git-scm.com Edit: I guess we could also combine 5 and 9, and 7, 10 and 11","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,683142059