Page Comparison

1.  Handling of New ProposalsAdmin (Former user (Deleted) )Proposals 
1. Options & Notes (From last week)
1.  Completely new domains like Pnf
- not an issue
2. Make proposals in own local copy
3. Make a package and copy all relevant artifacts and edit, merge when done
4. Create a 'duplicate' copy of item being edited (Vnfd and VnfdDraft)
5. Create a "Proposed" stereotype with a string called note that can be populated
with (By
1. (example - additional attributes added - Editor:  Jessie).  
2. Could use Experimental with a string?? - this will probably not work.   What if already accepted, then experimental???
3. Should we allow for multiple editors, or should there just be one to not compound the problem?
4. Use colors of text to highlight proposed changes with a comment
   1. Colors only apply to diagrams, not the tables 
   2. Would have to standardize on colors
2. Premise
   1. The editor must not 'destroy' accepted material until updates are accepted 
   2. Must have traceability
2. Papyrus Bug Status
1. Model "recleaned" this weekCould have Vincent recleanweek
2. Hopefully fix will be in next version - Jessie Former user (Deleted) will engage with Vencent Vincent
3. Bug occurs when object is moved from one submodel to another.
4. Bug does not occur if referencing or using object from another submodel. 
3. Gerrit
   1. Committing
   2. Reviewing 
4. ETSI Special Task Force - Did not discuss
5. Tool Tips, Tricks, and IssuesAssociation appearance & bus Issues - Did not discuss 
   1. Association appearance & Error

Notes:

1. Handling of New Proposals
   1. Agree to use 1av above to manage proposals (add stereotype of proposed)
   2. Jessie to update profile and apply next Monday.   Editors to include their name in the note to assure distinguishing with editor made the proposal.
   3. Use this concept going forward.
   4. Arun will update gendoc templates (Jessie made an update to the template to handle reference stereotype)
2. Gerrit Process
   1. Discussed this a fair amount
   2. Questions on
      1. who should review what submodel
         1. Perhaps the reviewer should be someone involved in that area (attends working calls, familiar with the area) 
      2. how many reviewers are necessary
      3. who is allowed to do a +2 versus just a +1 
      4. Committer should not merge their own work
      5. First reviewer does only a +1
      6. Another reviewer can then do a +2 and merge (either trust the first review and/or verify as well)
   3. If major issue found after merge, it can be abandoned
   4. If the commit is new material not socialized, perhaps a more relaxed review is appropriate - maybe just give some suggestions
   5. If a developed area and the updates are a concern, then perhaps apply a more careful review
   6. Kevin Scaggs will set up a wiki page for this process, and start on a proposal.