Add Maintainer Version Update process description to wiki - #2840
Conversation
|
Current Coverage: 99% Mypy errors on Maintainer-Version-Update-Process branch: 1420 |
|
🚨 Please update the changelog. This PR cannot be merged until |
LisaM-kiwi
left a comment
LisaM-kiwi
left a comment
There was a problem hiding this comment.
This looks good to me!
Updated wording for clarity and consistency in the version update workflow documentation.
|
Current Coverage: 99% Mypy errors on Maintainer-Version-Update-Process branch: 1191 |
1 similar comment
|
Current Coverage: 99% Mypy errors on Maintainer-Version-Update-Process branch: 1191 |
JoeWaddell
left a comment
JoeWaddell
left a comment
There was a problem hiding this comment.
This looks great, pending a couple questions! Hits the right amount of detail for me, as it works as a good set of guidelines without being too restrictive.
Also, it now works well with #2813, and I think the code there can link to or otherwise reference this writeup.
|
|
||
| After ``test`` is updated | ||
| ------------------------- | ||
| - During the testing phase, SME Maintainers will evaluate integrated model performance. (link to Scientific Evaluation Process). |
There was a problem hiding this comment.
reminder that link needed here! Or to add the Issue number while it's still in progress
Clarified the explanation regarding bug fixes in patch updates.
Create distinct processes for Major, Minor, and Patch updates, including deliverables and review requirements.
Corrected grammatical errors and improved clarity in the version update workflow documentation.
Correct formatting and spelling errors in the version update workflow documentation.
Removed link reference from the evaluation process description.
JuanTricarico
left a comment
JuanTricarico
left a comment
There was a problem hiding this comment.
My interpretation of the Version Update Maintainer Process is:
- Define release scope.
- Prepare evaluation criteria and evaluation inputs.
- Freeze dev and create release candidate in test.
- Evaluate model performance and generate reports.
- Approve and release the version with supporting documentation.
The workflow clearly describes how the release progresses from scope definition through evaluation, approval, and release. It also identifies the major release records generated during the process:
- Release scope and GitProject
- Evaluation criteria
- Changelog summary / release notes
- Evaluation results summary
- Technical review report
- High-level review summary
- Official release
What is still missing is an explicit description of where these release records are stored and how they are linked together. The workflow should allow future maintainers to locate the records associated with a release, understand how release decisions were made, and reconstruct the history of the version update process. A brief section describing how release records are organized and connected across the version update process would strengthen transparency and traceability.
The current strengths of the workflow are:
- Establishing explicit scope before execution.
- Requiring evaluation planning before creating the release candidate.
- That the dev > test gate ensures everyone tests, evaluates, and documents the same release candidate.
- The release decisions depend on scientific evaluation and code completion.
- Requirings documentation and director approval before release.
These strengths align well with RuFaS values and operating principles. The workflow supports scientific integrity through formal evaluation and review, shared stewardship through maintainer and SME participation, and systems thinking by evaluating integrated model performance. It also reinforces the operating principles of rigor > convenience, explicitness > implicit authority, and shared ownership > possession.
Most other major questions raised during review appear to be addressed either in this PR or in the related versioning/branching and SME review PRs and documents. Those details can continue to evolve as future releases identify opportunities for improvement.
Correct formatting of links in the Version Update Workflow documentation.
|
Current Coverage: 99% Mypy errors on Maintainer-Version-Update-Process branch: 1134 |
|
🚨 Please update the changelog. This PR cannot be merged until |
|
Current Coverage: % Mypy errors on Maintainer-Version-Update-Process branch: 1134 |
|
🚨 Please update the changelog. This PR cannot be merged until |
Removed redundant mention of the Release Notes and Technical Report posting alongside the release tag.
Thanks for calling this out @JuanTricarico. I have now added a description and links for where the release notes and technical reports can be found. We will continue to add clarity and specifity to the scientific evaluation process via #2818. |
…m/RuminantFarmSystems/RuFaS into Maintainer-Version-Update-Process
|
Current Coverage: % Mypy errors on Maintainer-Version-Update-Process branch: 1134 |
|
🚨 Some tests have failed. |
|
Current Coverage: 99% Mypy errors on Maintainer-Version-Update-Process branch: 1134 |
4 participants
Context
Issue(s) closed by this pull request: closes #2796
This PR adds the process developed through discussion in issue #2796 into a wiki page to document the process for reference in the future.
Note that when issue #2818 is complete, the references to the SME Review process on this page should be linked to that page