Page History

1. Someone editing a given submodel commits an update to gerrit.
1. Only the current model editor should be committing updates unless permission is granted by the current editor for someone else to temporarily be the editor to perform some update.

A couple quick thoughts - I went down the thought process of reviewers should be active and familiar with the area, but found it difficult to put names to a given submodel.   Maybe leave it as a general 'rule' without putting names to it?

The editor commits some update
2. A reasonable message is included in the commit, explaining what was updated.
   1. Given there is only a few characters allowed in the first line of commit, the second line of text should probably be used. 
3. Generally, a separate commit should be performed for each submodel.   An exception to this would be if the multiple models relate as part of some effort (some cross-model contribution)
.Updates should be committed weekly on Friday.    This suggests a given submodel may be a "work in progress"
1. .
2. IISOMI modeling guidelines
should
1. must be followed
.
1. Appropriate packages should be used for various entities (associations in the associations package, diagrams in the diagram package, classes in the ObjectClasses package, etc.)
2. Descriptions and stereotypes should be appropriately applied.
3. The committer should assign reviewers
   1. at least one reviewer should be assigned (two or more is fine)
   2. The reviewer performing the +1 must be familiar with the area.
   3. If a second reviewer is not assigned by the committer, the reviewer will add a second reviewer.
   4. Per the process below, one reviewer will presumably perform a +1, the other a +2 and merge.
1. , and reviews must assure that the guidelines are being adhered to before discussion occurs in some working team.
4. The committer assigns reviewers
1. At least two reviewers, but more is fine.   Available reviewers are Hui Deng , Xu Yang , Chuyi Guo Kevin Scaggs .
   Note:  Only one +1 is required, regardless of the number of reviewers assigned
2. The committer must
The committer can
1. also supply a gendoc output of the submodel (or the relevant portion of the submodel), supplying it to
the committers
1. the reviewers to facilitate easier approval.
 
5. Reviewers
   1. The committer cannot review, approve, or merge their own contribution.
   2. Reviewers should not work for the same company as the committer (at least not the reviewer performing the +1)
   3. Reviewers should be familiar with the subject area of the contribution if possible.   This suggests they participate on the weekly calls related to the contribution.   It is noted that there may be exceptions to this (work on party, business interaction, etc. may be "new" to all.
Approvals
1.   
   1. Gendoc output to be placed in Model tools \ Papyrus \ Gendoc Files Related to Gerrit Commits
   2. Providing such output will allow for quick reviews, and not require the reviewers to attempt to download the committed files into a papyrus environment for review.
   3. It is assumed that the gendoc output reflects the model / model fragment being updated.
6. Reviewers
1. Reviews are done with a 'first come, first serve" approach with a couple of exceptions
   1. The +1 reviewer cannot be from the same company as the editor performing the commit.
   2. If the editor performing the commit is not the regular submodel editor, the regular editor should perform the +2, verify, and merge.
2. The first available reviewer examines the request, including the gendoc output (2b above) as appropriate, and performs the +1.
3. The second reviewer (whoever next notices the request) is responsible for performing the +2, verify, and merge.
4. Keep in mind that commits are part of a "work in progress", not necessarily a finished work.
5. Reviews should be completed quickly to facilitate further development (suggest 24 hours or less)
7. Generally, commits to gerrit are a "work in progress" given commits are encouraged on a weekly basis.   We want to turn these around quickly to facilitate further development (commit on Friday, approved and merged for recloning and further work the following Monday).
8. The first reviewer should only do a +1 (or -1).
   1. In order to perform the review, the reviewer has either downloaded the Papyrus model files, loaded them into Papyrus and reviewed, or reviewed the output of the model (WIKI, gendoc, etc), or in some other way is familiar with the commit.
9. The second reviewer will then
   1. perform the +2 and merge.   This reviewer will either 'trust' the review of the first reviewer and/or perform a review themselves.
   2. reject the contribution (-1)
   3. Provide a +1 and assign a third reviewer if one is not already assigned.    This is presumably for situations where the committer is not comfortable providing the +2 and merge.
10. If multiple reviewers are assigned, all are not required to review to do the merge, just the first two.
If an additional reviewer examines the commit at a later time and a major concern is raised, the commit can be abandoned
1. .
2. For contributions of new material not yet socialized and/or not fully developed, a fairly 'relaxed' review with perhaps some suggestions is very reasonable. 
3. If a model conflict occurs, the submodel editor decides how to resolve.

Note:  In the past, Deng Hui has carried the burden of merging all commits.   This proposal will relieve him of that burden - any committer can merge given the guidelines abovethis burden.