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