### Problem to solve ChatOps is all about enabling operations via intuitive commands and actions that can be typed and integrated into one's chat tool. We've extended our existing suite of Slack slash commands with a command that allows you to add a comment to a GitLab issue without leaving Slack. This reduces context-switching and eliminates having to navigate multiple UIs just to update a teammate or stakeholder on an issue. Internally, issues are used by the GitLab infra team as a public portal for status updates to stakeholders. They are currently manually creating and updating a time line of events an actions as they occur during an incident. If they are using GitLab as a way to inform the public and stakeholders or progress, we want to give them an easy way to update an issue from the place where they are collaborating. This is the first step towards enabling them to update stakeholders faster and with less context switching. <!-- What problem do we solve? --> ### Intended users [Sasha the Software Developer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) [Devon the DevOps Engineer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) [Sidney the Systems Administrator](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details This work contributes to the [Incident Management Vision](https://about.gitlab.com/direction/monitor/debugging_and_health/incident_management/) ### Original Proposal Create a slash command that allows a user to add a comment to an issue. The design should minimize the number of inputs a user is required to populate in the command. Ideally, if the command is used in a thread underneath an incident, it should require zero inputs to route a comment to GitLab. GFM should be possible. <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ### Current Proposal * As a first pass, follow the [existing slack command model](https://gitlab.com/gitlab-org/gitlab-ce/uploads/0a2723de103334bb73c6835825cd847a/Screen_Shot_2019-08-14_at_2.24.35_PM.png), adding a new slash command for comment: `/gitlab <namespace/project> issue comment <issue-id>` * The *new* comment will be added to the specified Gitlab issue. This functionality does not extend to adding an existing comment to a GitLab issue. * Following the existing patterns, users should also be able to utilize GFM to append additional details to their comments, such as including code, referencing a merge request or linking to metrics. More details [here](https://gitlab.com/gitlab-org/gitlab-ce/issues/65864#note_206186199). * When the comment has successfully posted the user will get a message in slack confirming that the comment has been added. This comment will only be visible to the person who made the comment, along the lines of:  ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation Documentation required, most likely [here](https://docs.gitlab.com/ee/integration/slash_commands.html). <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references /label gitlab-ce~10230929