Close #174 Contributing Guide #175
Conversation
Some more changes More updates More changes
CONTRIBUTING.md
Outdated
| [here](https://github.com/openPMD/openPMD-standard/issues). The proposed | ||
| changes/features/question will then be discussed by the members of the | ||
| openPMD community (or anyone interested, really) in the `Comments` section of | ||
| this issue. The openPMD admins will usually add a label specifying the version |
There was a problem hiding this comment.
maybe replace admins with maintainers
There was a problem hiding this comment.
we add labels for:
- scope and
- impact of the change
The versions that will potentially implement a change can be the next matching version we work on or any later, depending on the process of the issue and when consensus is reached. (Documented in "projects").
For some issues we add also a "milestone" which is purely informative, e.g. to document a prior release a question refers to.
CONTRIBUTING.md
Outdated
| emerges, anyone can volunteer to implement it in the text of the standard. This | ||
| is done by creating a pull request (see below for more details on how to | ||
| create a pull request). Pull requests are then reviewed by the community, and | ||
| eventually merged by the openPMD admins (@ax3l and @RemiLehe) into the |
CONTRIBUTING.md
Outdated
| ------------ | ||
| - **New releases:** Once all the issues that have been labeled for the next | ||
| upcoming version have been resolved (e.g. via pull requests), the openPMD | ||
| admins will create a new official version (by merging the `upcoming-*` on top |
CONTRIBUTING.md
Outdated
| lists the upcoming versions that are being considered, and, for each | ||
| upcoming version, tracks the corresponding issues and their status (from | ||
| `proposed` to `accepted` to `implemented`). The Projects tab is important for | ||
| the prioritization and organization of tasks. |
There was a problem hiding this comment.
Mention that issues evolve and can be postponed for later releases (or sometimes even dismissed) , which is not a bad thing.
It just means the solution is not yet fully emerged, there are alternative approaches that might need further investigation, a solution exists that does not benefit from standardization or simply lacks time to implement in some cases.
CONTRIBUTING.md
Outdated
| Update Cycle | ||
| ------------ | ||
| - **Pull requests:** Once an issue is well-understood and a clear solution | ||
| emerges, anyone can volunteer to implement it in the text of the standard. This |
There was a problem hiding this comment.
Maybe let us add a sentence here:
Volunteer means: express in the issue you want to provide the PR to implement the agreed upon changes and the maintainers will publicly "assign" the issue to you, so we only do the work once.
Or just:
... anyone can volunteer via a comment in the issue to implement ...
| properly parse openPMD files that conform to this new official version. | ||
|
|
||
| Note that this 3-step process is reflected in the [Projects | ||
| tab](https://github.com/openPMD/openPMD-standard/projects). The Projects tab is important for the prioritization and organization of tasks. It |
|
@DavidSagan since you will be the first one to depend on this new guide, can you please give it a quick look and tell us if it's clear to you? :) We would then already include it in |
| [here](https://github.com/openPMD/openPMD-standard/issues). The proposed | ||
| changes/features/question will then be discussed by the members of the | ||
| openPMD community (or anyone interested, really) in the `Comments` section of | ||
| this issue. The openPMD maintainers will usually add a label specifying the |
|
Probably the general idea, one idea / topic at a time per issue to avoid off-topic discussions could be added? Also, before opening issues searching for already open issues? Both are generally useful aspects for discussions on the web but might need to be introduced? |
|
In the last teleconference I brought up the idea of having a period between the merging of the |
|
FYI: I followed the pull request documentation and everything went smoothly. |
|
@DavidSagan sure, we can rehearse the releases as a whole! But I think we would do it in a small team since the main reviews are already done during PRs and it does not really affect everyone. Plus: every change we want to make would go through the same review procedure via PRs again anyway :) Speaking of which: do you want to go over the changes in 1.1.0 again? It's really just those PRs:
And we thought let's wrap it tomorrow and put all other changes in 2.0.0. What do you think? |
This improves the
CONTRIBUTING.mdfile, so that new openPMD contributors know what the update cycle is, and how to contribute.Since this does not affect the standard itself, I did not use the PR template that is mentioned in this instructions.
@DavidSagan @ax3l Is this understandable? Please comment if any part is unclear from your point of view.