-
Notifications
You must be signed in to change notification settings - Fork 25
Add Maintainer Version Update process description to wiki #2840
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Changes from all commits
ce5c670
518c279
461247f
4d5a4ab
1d1f349
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| Maintainer Team Workflow and Communication during a Version Update | ||
| =================================================================== | ||
|
|
||
| This page describes the process that RuFaS Maintainers will use to communicate | ||
| and execute a version update. | ||
|
|
||
| In addition to the updated model and scientific documentation in the repository | ||
| codebase, additional deliverables of this process for **Major** and **Minor** | ||
| updates are: | ||
|
|
||
| - A detailed technical report of the scientific review by SME Maintainers | ||
| - A version release note that includes: | ||
| - A high-level summary of the outcomes of the SME Review | ||
| - A summary of the changelog | ||
|
|
||
|
|
||
| Before Merging ``dev`` to ``test`` | ||
| ------------------------------ | ||
|
|
||
| **Major** and **Minor** updates: | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
|
|
||
| 1. RuFaS Maintainers meet to discuss what work **will and will not** be | ||
| included in the release and the proposed timeline. | ||
|
|
||
| 2. The PML reviews and approves pending work to be included and excluded | ||
| from the version update, with additional Maintainer input as needed. | ||
|
|
||
| 3. The PML and team leaders create a GitProject for the version release and | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this project be Public, or Private to maintainers?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I lean towards making it public so that people can easily see what is coming in the next version update.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree I think leaving it as a public project makes sense |
||
| add pending issues/PRs that must be completed before the version update | ||
| (before ``dev → test``). If a Maintainer identifies additional work that would benefit | ||
| the version release after the project is created, issues/PRs should be added to | ||
| the version release project or discussed with the PML at the members discretion. | ||
|
|
||
| 4. SME Maintainers review the scientific evaluation process and criteria from the | ||
| previous version release and update as necessary. | ||
|
|
||
|
|
||
| **Patch** Updates | ||
| ^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Patch updates do not require a full project. Bug fixes required in the patch should be collected | ||
| as sub-issues under a Patch parent/tracker issue. | ||
|
|
||
|
|
||
| After ``test`` is updated | ||
| ------------------------- | ||
| - During the testing phase, SME Maintainers will evaluate integrated model performance. (link to Scientific Evaluation Process). | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. reminder that link needed here! Or to add the Issue number while it's still in progress |
||
| - When the model performance has been verified by at least one SME Maintainer per Module, the Scientific Director will prepare a Scientific Report summarizing the model performance and changes in scientific methodology. | ||
| - The Director of Software Engineering will lead preparation of a set of Release Notes to summarize model updates. | ||
| - When the testing phase is complete, both the Scientific Report and Release notes are added to the project documentation on GitHub and shared with the PML for approval. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should it be made explicit here how/how quickly test->main happens after this? Or should the text here simply link to what's contained in #2813?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My thought was that this statement connects to point 3 in the "Merging to main" section that Branching Strategy PR. I don't think we need a specific timeline although part of me definitely wants one |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.