Grant Hickmanchanged title from Update Slack's GitLab Landing Page to communicate support for Notifications in the GitLab for Slack App to Update Slack's {++}GitLab {+for Slack App l+}anding page to communicate support for notifications
changed title from Update Slack's GitLab Landing Page to communicate support for Notifications in the GitLab for Slack App to Update Slack's {++}GitLab {+for Slack App l+}anding page to communicate support for notifications
Grant Hickmanchanged the descriptionCompare with previous version
@lvanc I don't think this requires engineering support. I think we'll just need to have the content created and submit via the App Directory before the next App Submission. Or, at minimum the change could likely be done at any time for the landing page content.
We could probably test by updating the App Name to GitLab for Slack since we're already making these changes (see Docs).
@.luke Do you agree? Any opposition to updating the app name to align with our docs?
If your Slack app integrates with another service, include the name of that service in your app name. If you do not own the service, make sure to not infringe on any trademarks or copyright (e.g., “Task notifications for Slack” rather than “Slack task notifications”).
But to be honest, when I look at things like the Apps we have installed, I think the more concise GitLab is probably better - people know that it's "for Slack" because the context of "for Slack" is very strong! It would seem to me a bit redundant for this app to be named GitLab for Slack:
@.luke That's a good point. Maybe for the app itself, we use GitLab, but everywhere else it's GitLab for Slack. I thought there may be a chance to create some consistency with other integrations like the GitLab for Jira app. But that's a solid point. @lvanc?
In either case, when we do update the basic info to include details about the slack notifications within the app, will that require an app submission? Or will the page update without a review? I don't recall how that played out last time.
when we do update the basic info to include details about the slack notifications within the app, will that require an app submission?
@g.hickman Yes, these details all get published when we republish our Slack app to the Slack App Directory. We're able to change the App Home contents at any time though.
@.luke Ah ok, we do need to "republish" and get changes approved, including the contents in the description. I thought there were some bits from the App Directory page we could change at will, but that must be only the App Home. Thanks for confirming.
@lvanc As we discussed today, I think primarily we want to be consistent. We have the GitLab for Jira app as well. I'd like to pick an approach for when we are communicating about our integrations in docs/marketing.
I would clarify that in the Integrations list view, I think this could be confusing or redundant so in any product UIs, I think we could stick to using just GitLab or Slack (GitLab in the Slack app directory, or in the app itself when the app appears, or Slack in the project settings list view). If we have two integrations with a 3rd party, we could add context -- Slack app / Slack integration, or Slack slash commands, Slack notifications.
Integrations and app both seem somewhat generic and extraneous, so I can see the point there. If we choose to remove this, I'd prefer we do it soon and stick to it. And that we apply this logic across the board (such as updating the GitLab for Jira app terminology in product UIs.
Luke Duncalfechanged title from Update Slack's GitLab{- for Slack App landing page-} to communicate support for notifications to Update Slack's GitLab{+ app description+} to communicate support for notifications
changed title from Update Slack's GitLab{- for Slack App landing page-} to communicate support for notifications to Update Slack's GitLab{+ app description+} to communicate support for notifications
@lvanc@g.hickman This is the only blocking issue of #384226 (closed) - if we were to decide what the updated description should be within a couple of days, then we could submit the app for review #384226 (closed) within %15.7 otherwise that issue would be at risk of slipping.
All SUS-impacting issues need to have a proper severity label set.
Please add a severity label, remove the automation:ux-missing-labels label, and then reply to this comment briefly explaining your reasoning for providing this severity.
If you are not the DRI for this area and would like help determining the best severity, please @ the appropriate person for assistance.
I reviewed and the content looks good. the images, very professional!
A few questions:
I noticed that we've had our pricing listed as "Free and paid plans available". I'm not sure this makes sense as the integration itself is free, though of course GitLab has free and paid plans. I hadn't noticed this before but I'm wondering if we should update this. For comparison, I see Jira's listing showing pricing as "Free", but they of course also have paid plans for Jira.
I was looking through the Basic Information tab and browsed through other tabs as well, but can't seem to find where we modify this page: https://gitlab.slack.com/apps/A676ADMV5-gitlab?tab=features. Am I missing it somehow? Is this something we could also update?
@g.hickman thanks for reviewing this! as for your questions:
I noticed that we've had our pricing listed as "Free and paid plans available". I'm not sure this makes sense as the integration itself is free, though of course GitLab has free and paid plans. I hadn't noticed this before but I'm wondering if we should update this. For comparison, I see Jira's listing showing pricing as "Free", but they of course also have paid plans for Jira.
Hmm, good question. I think keeping "Free and paid plans available" still makes sense here since parts of the integrations require a paid plan. For example, the "Vulnerability" trigger requires an Ultimate plan.
I was looking through the Basic Information tab and browsed through other tabs as well, but can't seem to find where we modify this page: https://gitlab.slack.com/apps/A676ADMV5-gitlab?tab=features. Am I missing it somehow? Is this something we could also update?
I think the content of this "Features" tab is auto-generated based on what is configured under the "Features" left nav section. For example, try editing this command:
https://api.slack.com/apps/A676ADMV5/slash-commands?
Hmm, good question. I think keeping "Free and paid plans available" still makes sense here since parts of the integrations require a paid plan. For example, the "Vulnerability" trigger requires an Ultimate plan.
@lvanc I see your point. Okay, we can leave for now unless/until we have better guidance.
@lvanc@g.hickman I might actually close this, because it's a blocking issue of #381012 (closed) and it might be confusing for this to be left open. If we close it, then the only blocking issue will be #384226 (closed) which is probably easier for people to understand. I want to reduce the chance that we end up being confused about what is blocking our ability to release in #381012 (closed).