Reduce the reliance on required running of gitlab-rails console
Request for comments
Need
This is a meta issue combining a few conversations about reducing the need to resort to using the gitlab-rails console
.
- As
@wwjenkins
noted in #5615, the need to use thegitlab-rails console
is difficult and of concern to select US Government customers. - In the list of Features that are not available for GitLab Dedicated, we note: Any functionality or feature behind a Feature Flag that is toggled
off
by default
Approach
Big picture, I think we should do something like:
Enumerate the different places where we have folks resort to the gitlab-rails console
. I think those places (at a high level) are:
- Docs (consider the old GitLab Rails Console Cheat Sheet stuff that was moved into troubleshooting sections -- see gitlab-org/gitlab!102708 (merged), gitlab-org&8147 (closed))
- Feature flags
- Workarounds in issues
Start the conversation about reducing the need to get to gitlab-rails console
in each of those places as it makes sense (the goal isn't console zero
):
- Docs: if a particular problem is considered fixed because there's a way to address it via
gitlab-rails console
in the docs, there should probably be a🆕 New issue capturing the need for a non-Rails console fix.- The scope there could be massive. With
git grep
and friends, we should be able to get a handle on the scope.
- The scope there could be massive. With
- Feature Flags
- To be clear: I am not advocating "no more Feature Flags". I do think we have an opportunity to influence a bit of clean-up gitlab-org/gitlab#373936. We should be able to link customers to the rollout issue for a given feature flag.
- That will help them to understand when the behavior they are seeking is enabled by default in GitLab.
- To be clear: I am not advocating "no more Feature Flags". I do think we have an opportunity to influence a bit of clean-up gitlab-org/gitlab#373936. We should be able to link customers to the rollout issue for a given feature flag.
- Change our thinking about issue Severity and workarounds in issues
- I would propose addressing this with an adjustment to how we think about Severity. If the workaround for an issue requires the usage of
gitlab-rails console
, the issue is a strong candidate forS2
. (It'd only technically beS2
for GitLab Dedicated and select US Government and Global customers.)-
👉 See the MR. gitlab-com/content-sites/handbook!4412 (merged)
-
- I would propose addressing this with an adjustment to how we think about Severity. If the workaround for an issue requires the usage of
I talk often about the 80/20 rule. This proposal is big and we should endeavor to find the places we can maximize our impact. The goal is to reduce the need for customers to go to gitlab-rails console
where possible and reasonable.
Benefit
Taken together, this effort helps customers for whom a reliance on gitlab-rails console
is problematic by:
- ensuring that concern is accounted for when issues are triaged moving forward
- starting to tackle places where the need for
gitlab-rails console
is clear and obvious already
Competition / Alternatives
- We could do nothing.
- We could deal with the frustration caused by a dependence on
gitlab-rails console
on a case-by-case basis.