Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »


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?


  1. The editor commits some update
    1. 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. 
    2. 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).
    3. IISOMI modeling guidelines must be followed, and reviews must assure that the guidelines are being adhered to before discussion occurs in some working team.
    4. Appropriate packages should be used for various entities (associations in the associations package, diagrams in the diagram package, classes in the ObjectClasses package, etc.)
    5. Descriptions and stereotypes should be appropriately applied.
    6. 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.
    7. The committer can also supply a gendoc output of the submodel (or the relevant portion of the submodel), supplying it to the committers to facilitate easier approval. 
  2. 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.
  3. Approvals
    1. 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).
    2. 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.
    3. 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.
    4. If multiple reviewers are assigned, all are not required to review to do the merge, just the first two.
    5. If an additional reviewer examines the commit at a later time and a major concern is raised, the commit can be abandoned.
    6. For contributions of new material not yet socialized and/or not fully developed, a fairly 'relaxed' review with perhaps some suggestions is very reasonable. 


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 above. 

  • No labels