- Handling of New Proposals
- Options & Notes (From last week)
- Completely new domains like Pnf
- Make proposals in own local copy
- Make a package and copy all relevant artifacts and edit, merge when done
- Create a 'duplicate' copy of item being edited (Vnfd and VnfdDraft)
- Create a "Proposed" stereotype with a string called note that can be populated (example - additional attributes added - Editor: Jessie).
- Could use Experimental with a string?? - this will probably not work. What if already accepted, then experimental???
- Should we allow for multiple editors, or should there just be one to not compound the problem?
- Use colors of text to highlight proposed changes with a comment
- Colors only apply to diagrams, not the tables
- Would have to standardize on colors
- Premise
- The editor must not 'destroy' accepted material until updates are accepted
- Must have traceability
- Papyrus Bug Status
- Model "recleaned" this week
- Hopefully fix will be in next version - Jessie S Jewitt will engage with Vincent
- Bug occurs when object is moved from one submodel to another.
- Bug does not occur if referencing or using object from another submodel.
- Gerrit
- Committing
- Reviewing
- ETSI Special Task Force - Did not discuss
- Tool Tips, Tricks, and Issues - Did not discuss
- Association appearance & Error
Notes:
- Handling of New Proposals
- Agree to use 1av above to manage proposals (add stereotype of proposed)
- Jessie to update profile and apply next Monday. Editors to include their name in the note to assure distinguishing with editor made the proposal.
- Use this concept going forward.
- Arun will update gendoc templates (Jessie made an update to the template to handle reference stereotype)
- Gerrit Process
- Discussed this a fair amount
- Questions on
- who should review what submodel
- Perhaps the reviewer should be someone involved in that area (attends working calls, familiar with the area)
- how many reviewers are necessary
- who is allowed to do a +2 versus just a +1
- Committer should not merge their own work
- First reviewer does only a +1
- Another reviewer can then do a +2 and merge (either trust the first review and/or verify as well)
- who should review what submodel
- If major issue found after merge, it can be abandoned
- If the commit is new material not socialized, perhaps a more relaxed review is appropriate - maybe just give some suggestions
- If a developed area and the updates are a concern, then perhaps apply a more careful review
- Kevin Scaggs will set up a wiki page for this process, and start on a proposal.