Once the proposed changes have been created, the changes must be committed to your branch. Modifications are saved by the GitLab IDE using a commit and you can commit as many times as you need until your proposal is complete. Please commit your changes if you are done working. Leaving GitLab without committing changes will lead to losing work.

Committing Proposed Changes and Submitting the Proposal

Changes are committed from the GitLab IDE.

If you are not already in GitLab, navigate to your branch that includes your proposal content. You can get here from your Jira ticket by clicking on the "Link to Content" link in the Editing and Managing Proposal Content section on the right side of your Jira ticket. If you need to login, use your Jira login to do so.
Once in GitLab, click "Web IDE". On the left hand side, click on the icon for Source Control. If changes have been made to files, there will be a blue number indicating the number of files changed on the icon (as shown below).
This view will show all of the files changed and the type of change (A for adding a file, M for modification, and D for deleting a file). Clicking on the files will show a diff of each file. Before committing, please review each change. T
Once ready to commit, enter a message describing the changes you are committing where it says "Commit Message". When ready to save (or commit), click on the blue "Commit & Push" button.
GitLab will ask you if you want to commit to a new branch. You MUST select NO (Use the current branch)
A message will display at the bottom right of the page letting you know that your changes have been committed. DO NOT CLICK ON CREATE MR. You may choose to Continue working if you have more changes to make.
If you are done committing all of the needed changes for your proposal, you can return to the UP ticket. Since GitLab opens in a new tab, you may still have the tab open. Otherwise, please return to your ticket by searching for it in Jira. Once on your ticket, you can see your commits (and diffs) by clicking on "Link to Branch Diff" in the Editing and Managing Proposal Content area of the ticket. This will show all commits made to the branch and display the diffs for all files.
If you are read to submit your changes for Consensus Review, return to your proposal once again (tab should still be open). Click on the Proposal Draft button and select Submit.
This transition will ensure that you have several required fields: Sponsor Approval Date, Sponsor, and Change Objects
1. Sponsor Approval Date: Enter the date that the sponsoring Work Group approved the proposal. The meeting minutes from the call in which this proposal was approved should be linked in the proposal description before submitting the proposal.
2. Sponsor: Enter the name of the sponsoring Work Group
3. Change Objects: This field is auto-populated using the information from the commits and will help reviewers review the changes by linking them directly to each change diff.
Click 'Submit' when the proposed changes have been submitted and the information in the proposal is as desired.
1. Submission of a proposal kicks off an automated build process that will validate the content and give an indicator if errors have been introduced. This eliminates the need for submitters to run the IG Publisher locally to validate their content. To view the status/results of the build, click on "Link to Build Pipeline" in the Editing and Managing Proposal Content area of the proposal. This process will take around an hour, so you will likely wish to monitor progress via the "Link to Build Pipeline" or return later. NOTE THAT YOU DO NOT NEED TO REVIEW THE AUTOMATED BUILD RESULTS IF YOU ARE NOT FAMILIAR WITH DOING SO. THIS STEP SAVES TIME BY PERFOMING VALIDATIONS ON THE SERVER SO THAT THE TERMINOLOGY CURATOR DOES NOT NEED TO BUILD LOCALLY EACH TIME. IF YOU ARE FAMILIAR, IT IS A USEFUL TOOL TO ENSURE THAT YOUR PROPOSED CONTENT IS CORRECT AND SAVE TIME IN CORRECTING ANY ISSUES.
  1. This page will show you if your build is running or if it has passed or failed
  2. To download a local copy of the build, click on the download icon on the right side of the build result and click "build-job:archive". This will download the entire output of the automated build.
    1. To view the build output, navigate to your downloads and unzip the artifacts.zip package. To start at the Home Page of the build, navigate to ...\artifacts\output\full-ig and click index.html. You can also view specific artifacts by navigating to \artifacts\output\full-ig\site and selecting the html file for the artifact you need to review.
  3. To view the build log, click on the Status (such as passed) and then click "build-job"
  4. The comparison of Errors, Warnings, Info, and Broken Links is also added as a comment to the proposal on your UP ticket in Jira. Note that this may vary if the version of the IG Publisher has changed. We are working on having a stable IG build so that this will be more useful.
2. If there are no issues found by the automated build and the curator, the proposal will be pushed to the 'Consensus Review' state where it can be voted on the by the larger community.
3. Notifications will be provided via email about state changes, comments, etc.

VERY IMPORTANT: After Submission, your proposal will enter Consensus Review once automated and manual checks on the content have been verified. Once in Consensus Review, the proposal is locked. NO ADDITIONAL CHANGES should be made as additional commits after entering Consensus Review will not be implemented. If you need to make changes, the proposal must be pulled back into 'Proposal Draft'. Please see Resubmitting a Proposal with Changes for more information.

Page tree

Saving and Committing Proposed Changes

Committing Proposed Changes and Submitting the Proposal