[Cordova Wiki] Update of "CommitterWorkflow" by MarcelKinard

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.

The "CommitterWorkflow" page has been changed by MarcelKinard:
https://wiki.apache.org/cordova/CommitterWorkflow?action=diff&rev1=20&rev2=21

Comment:
added verbage about test expectations

   * For small changes, private topic branches are preferred.
   * Note: You should never rebase a public topic branch!
  
+ == Step 4: Make your changes ==
+  * Thank you for making the world a better place.
+ 
+ == Step 5: Test your changes ==
+  * The author is responsible to test their own changes and correct any problems with their changes before a pull request is submitted (contributor authored) or it lands in the stream (committer authored). The testing includes both verifying the function they added/touched, plus running the test suites to verify there are no regressions.
+  * When we say "run the test suites" this includes all automated tests in mobile-spec, manual tests in mobile-spec that might be affected by the change, and any platform-specific unit tests (i.e., cordova-android/test, cordova-ios/CordovaLibTests, etc.)
+  * It is recommended to add a short comment to the Jira item stating what testing you did.
+  * It is recommended that where reasonably feasible, you add automated tests to validate your change and catch any future regressions.
+ 
- == Step 4: Ask for a code review ==
+ == Step 6: Ask for a code review ==
   * If you are using a public topic branch, then you should ask for a code review when you consider it to be complete.
   * Use [[http://reviews.apache.org/|reviews.apache.org]] to create a review request.
     * By default, the ML will be notified of your review request.
     * If you have someone in particular that you would like approval from, be sure to add them in "People" field of the review.
  
- == Step 5: Merge your change ==
+ == Step 7: Merge your change ==
   * Once your topic branch is tested & working, it's time to merge it.
   * Rebase & commit it to master. If it fixes a regression, then also cherry-pick it into the appropriate release branch.
   * Here is an example workflow for committing a change:
@@ -83, +92 @@

  
  Note also that the timestamp on a commit will be unchanged by a rebase, but that it will appear "out of order" in git log. This is because git log is not chronological order, but in order of the `parent` chain of the commits.
  
- == Step 6: Update JIRA ==
+ == Step 8: Update JIRA ==
  
  Mark the relevant JIRA as fixed, and be sure to include the relevant commit IDs.
  
@@ -92, +101 @@

  
  == Step 1: Review the change ==
   * View the user's branch in github and request changes be made (if applicable) by adding comments in the web interface
+  * Verify that the contributor tested it, per the test guidelines above.
  
  == Step 2: Ensure that they have signed the Contributor Agreement ==
   * For trivial changes, this is not necessary.