Provide optional title and description before submitting edits made with the Static Site Editor
Problem to solve
Engineering best practices dictate that changes should be accompanied by a concise, descriptive title and description of the change. The context provided is valuable during the review process and for documenting the justification and motivation for the change.
The Static Site Editor attempts to abstract as much of the Git workflow away from the editor as possible. In its current state, that means that changes are submitted using a default branch name, merge request title, and description. A user who wants to provide additional context or justification must do so by editing the resulting merge request after its creation.
Intended users
User experience goal
The user should be able to provide additional context about the changes made in the Static Site Editor that carry over into the resulting merge request.
Proposal
When submitting a change from the Static Site Editor, prompt the user to provide a custom merge request title and description. The current defaults should be used as placeholders for each field so we can retain the streamlined publishing process users currently enjoy.
Workflow
- User opens SSE and makes changes
- User clicks submit changes
- Modal opens with MR title and description pre-filled with default values.
- User optionally changes the values.
- User submits values
- If submit
- Branch, commit and MR gets created.
- The user is presented with a success screen.
- If close modal
- User returns to edited editor state (no branch, commit, MR created)
- If submit
Design
#216861[direction-20201008-submitchangetitledescription.png]
Iteration plan
- Iteration 1: Introduce MR title and description modal
Documentation
Availability & Testing
What does success look like, and how can we measure that?
- Fewer generic-looking MRs being created in
www-gitlab-com
Instrumentation
- An event should be created and stored if a user overrides the default MR title or description
Problems to solve
-
Currently, we have a "Submit Changes" call to action in the editor as well as on the modal. We should think about how we prompt the user for the actions.
Execution plan
-
MR1: submit_content_changes.js
'ssubmitContentChanges()
needs to forward atitle
(vs. current generated approach) anddescription
(bake defaults for now) -
MR2: add UI for collecting user input of title
anddescription
and forward to MR1's implementation -
MR3: handle UI close and reopen scenario via local storage persistence (likely via GitLab's autosave.js
)