Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 37,117
    • Issues 37,117
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1,398
    • Merge requests 1,398
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #281073

Closed
Open
Created Nov 11, 2020 by Ezekiel Kigbo@ekigbo🌴Maintainer6 of 12 tasks completed6/12 tasks

[Feature flag] Rollout of `set_user_availability_status`

What

Remove the :set_user_availability_status feature flag ...

Owners

  • Team: groupoptimize
  • Most appropriate slack channel to reach out to: #g_manage_optimize
  • Best individual to reach out to: @ekigbo

Expectations

What are we expecting to happen?

User's should be able to set their "availability" status (busy / not set) from the user profile settings and from the set status modal.

The "busy" status will be reflected next to the user's name in various locations

What might happen if this goes wrong?

The feature does not work as expected

What can we monitor to detect problems with this?

Beta groups/projects

If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.

  • gitlab-org/manage/optimize
  • gitlab-org/gitlab project
  • gitlab-org/gitlab-com groups

Roll Out Steps

  • Enable on staging (/chatops run feature set feature_name true --staging)
  • Test on staging
  • Ensure that documentation has been updated
  • Enable on GitLab.com for individual groups/projects listed above and verify behaviour (/chatops run feature set --project=gitlab-org/gitlab feature_name true)
  • Coordinate a time to enable the flag with the SRE oncall and release managers
    • In #production by pinging @sre-oncall
    • In #g_delivery by pinging @release-managers
  • Announce on the issue an estimated time this will be enabled on GitLab.com
  • Enable on GitLab.com by running chatops command in #production (/chatops run feature set feature_name true)
  • Cross post chatops Slack command to #support_gitlab-com (more guidance when this is necessary in the dev docs) and in your team channel
  • Announce on the issue that the flag has been enabled
  • Remove feature flag and add changelog entry
  • After the flag removal is deployed, clean up the feature flag by running chatops command in #production channel

Rollback Steps

  • This feature can be disabled by running the following Chatops command:
/chatops run feature set set_user_availability_status false
Edited Jan 06, 2021 by Ezekiel Kigbo
Assignee
Assign to
13.9
Milestone
13.9 (Past due)
Assign milestone
Time tracking