INFO - Version related attributes
- Dominant language
- TypeScript
- Stars
- 9
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Description
These are for thought — I’m open to discussion but each touches on an important principle that needs to be addressed:
- [ ] there is NO confusion EVER about which version is legal
- this applies whether looking at the WQ or at a specific RUP
- all statuses fall into four categories
1. In progress — draft, in feedback, waiting for signatures, waiting for decision etc.
2. Current legal — most recent legal version (either approved OR one of the “stands” statuses)
3. Past legal — was once legal but a more recent version is now legal
4. Not implemented (?) — not approved or wrongly made-without effect
- [ ] if you are looking at a version that is no longer legal (has been superseded or determined to be wrongly made without effect) that must be clear
- [ ] it would be helpful, when looking at the screen that lists the versions, to be able tell which RAN these RUP versions are for (sometimes a user may have more than one browser window open and it gets confusing)
- [ ] there should never be more than one “in progress” version in play at any given time
- amendments can only be built off of “current legal” versions not anything else
- [ ] when a new version is created (aside from amendment that could be at time of expiry) it should be a snapshot of all of the data EXCEPT the final status/date
- a new version should take the “earliest” draft status that relates to the user that initiated the version
- for staff that would be 6-SD
- for AH that would be 4-D
- [ ] when a new version is started the non-initiating party should not be able to view the details of the version in 6 or 4 until it is pushed to the non-initiator by way of a submit action (respectful relationship viewing)
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.