[Verify] Use "compute minutes" instead of "CI/CD minutes", etc.

Problem

In this issue we changed the language in the documentation to be consistently "CI/CD minutes." However, the UI includes older and inconsistent language when referring to these minutes, including:

1. CI/CD minute(s)
2. CI minute(s)
3. pipeline minute(s)
4. CI pipeline minute(s)
5. pipeline minute(s) quota

Also, the Customers Portal uses CI minutes terminology, though maybe it was changed recently. CI minutes is part of our ubiquitous language and it's used in the backend and in our general communication.

UPDATE, 2023-03-21: We are now calling CI/CD minutes "units of compute." As part of this update, we'll need to address all of these UI terms as well.

UPDATE, 2023-06-26: We are now going to use compute minutes for the feature name.

Solution

Grep for pipeline minute, CI minute, CI/CD minute, CI pipeline minute, and pipeline minute(s) quota and adjust user-facing UI text to use the term compute minute.

added Category:Continuous Integration Compute minutes documentation frontend grouppipeline execution labels

marked this issue as related to #331656 (closed)

changed the description

@jreporter @marcel.amirault WDYT?

@tgolubeva @hilaqu @williamchia - fyi on this proposal. I think we should convert to CI minutes Since that is how we reference them.

@fabiopitino we may want to add docs to this change

Thanks, @jreporter ! Tagging @esybrant here as well

@jreporter @fabiopitino I'm opinionated on this and happy to share some thoughts on my way out :)

I strongly recommend using pipeline minutes or CI/CD minutes as the one term that you choose and use everywhere. CI minutes can cause confusion. Use and Customers will wonder, are they only charged CI? Are there CD minutes? etc.

This would be consistent with our docs - which uniformly refer to GitLab CI/CD https://docs.gitlab.com/ee/ci/ (Only the URL is a legacy CI-only term)

For branding/promotion. GitLab does way more than just CI. We don't want people to think of GitLab as just a CI tool. We want them to think of GitLab as a full-featured CI/CD that they can use to release and deploy software as well as test.

Thanks @williamchia!

@amandarueda - your perspective here would be helpful. I don't know if our users would understand CI/CD minutes since that is not a term they have interfaced with.

@rayana - what do you recommend from a UX perspective to evaluate the name that would be salient for our users?

Unfortunately we have a variety of terms used in the docs as well, the below was found with 5 minutes of searching, there are more pages with more variations.

1. Pipeline quotas
   1. Pipeline duration: explains the total run time for a pipeline.
   2. Pipeline quota: explains the total run time for all jobs (without overlap) for a pipeline.
2. Purchase CI Minutes: directions on how to buy more minutes
3. Graphical presentation of how CI minutes work
4. Pipeline minutes quota: explains how to set the max number of minutes that a group can use on the instance
5. extra_shared_runners_minutes_limit: how to set the minutes for a user via the API
6. shared_runners_minutes_limit: how to set the minutes for a group via the API

That said, @jreporter, I like the idea of standardizing on a term and updating artifacts to match. Which is the best, is up for debate.

We've been using CI Minutes since the ability to buy them has rolled out (~ 2 years?) and no one has asked where they buy CD minutes. However, being explicit isn't a bad thing. I don't think anyone would be confused per se about the term CI/CD minutes (would like @lyle's opinion as well), but I could see the backend reference getting messy (i.e. one dev using CI_CD_minutes, another using CI-CD-minutes, etc).

I'd consider whether additional changes may be coming to CI (like Mac OS feature) which may sway the naming decision. And I would loop in @supadhyaya for feedback since she's crafted community comms around CI in the past and @esybrant since she's thought about this product and the user experience for some time.

I realize this wasn't super helpful, but want to be clear that I defer to your judgement here @jreporter.

This was super helpful and really appreciate you tagging others to bring their POV in, @amandarueda - so thank you!

I don’t want to misstep here and make assumptions. I’ll let everyone advise on their thoughts and maybe we can create a survey with mocks to decide the next best step

@jreporter @fabiopitino This is very similar to what I did for variables. We had a variety of ways to talk about the, and often used CI Variables, but I suggested using CI/CD variables as the standard across the docs, and implemented the change in #321011 (closed). Up to that point, we users often used CI variables, secret variables, environment variables and even just variables... but changing to one standard of CI/CD variables seems to have been accepted by the community without issue.

So, I'm fully onboard with CI/CD minutes as our front-facing standard. Within the backend code, I don't think it'll be necessary to update mentions of this, as long as the frontend is fine.

@marcel.amirault On the backend, from about 1 year ago, we are almost standardized on Ci::Minutes term. I'm saying "almost" because we still have references of shared_runners_minutes which we are going to remove. I think if we decide to use CI/CD minutes publicly this is still fine since the Ci:: prefix is necessary for code organization and ownership (we don't have CiCd:: or Cd:: namespaces).

cc @jreporter

Okay this makes sense! I will wait for @rayana thoughts and go from there

I don't think anyone will be confused by "CI/CD Minutes". In fact, we're already using that terminology on our pricing page as well. I'm all for making this language more standard. Even within support we use all the terms Amanda pointed out. I'd love to have just one!

I'm totally on board for unifying the language, it's always bothered me that we have so many terms.

Personally, I would vote for CI minutes or CI/CD minutes, with a preference for CI minutes just because the slash feels clunky to say/read/type.

@amandarueda thanks for the tag. We have used CI/CD minutes consistent in our communication for the CI/CD consumption pricing FAQ, blog and on the pricing page and pricing page FAQ. I'm in favor of using CI/CD minutes consistently - for all the reasons William mentioned above.

Sounds good - thanks @supadhyaya

I’ll update this proposal for CI/CD minutes

Setting label(s) devopsverify sectionops based on grouppipeline execution.

added devopsverify sectionops labels

mentioned in issue #197368 (closed)

marked this issue as related to #197368 (closed)

changed title from Use "CI minutes" consistently instead of "pipeline minutes" to Use "CI/CD minutes" consistently instead of "pipeline minutes"

changed the description

mentioned in merge request !72316 (merged)

added Technical Writing UI text labels

mentioned in issue #331656 (closed)

mentioned in merge request !76253 (merged)

mentioned in commit b201d2f9

mentioned in merge request !77152 (merged)

@sselhorn is !77152 (merged) fully tackling this issue? Would you want to assign this issue to yourself?

/cc @avielle

@fabiopitino I was going to tackle the docs, and I think that MR covers all of them.

I just did a search of the rest of the repo and there are a lot of non-docs instances of:

• pipeline minute
• CI minute
• CI pipeline minute

I think an engineer would be better to handle these. I could take a shot at it, but there is a lot I don't know, and I think it would take a bit longer. I'm happy to review an MR but I don't think I should be the one opening it.

@sselhorn Ah good point. I think we need engineers to look at those then. Thank you!

changed the description

added 1 deleted label

mentioned in merge request !78962 (closed)

All SUS-impacting issues need to have a proper severity label set. Please add those to this issue.

added automation:ux-missing-labels label

added severity4 label

mentioned in issue #352757

removed automation:ux-missing-labels label

added Seeking community contributions label

@sselhorn thanks for adding the Seeking community contributions label!

This issue's description does not seem to have a section for "Implementation Guide". Please consider adding one, because it makes a big difference for contributors. This section can be brief but must have clear technical guidance, like:

• Hints on lines of code which may need changing
• Hints on similar code/patterns that can be leveraged
• Suggestions for test coverage
• Ideas for breaking up the merge requests into iterative chunks

changed the description

mentioned in merge request !87163 (merged)

mentioned in issue #361575 (closed)

@paarth551 what do you think about taking a look at this?

It will probably involve having a grep around the codebase for the offending phrases- fixing them, then regenerating the translations?

Sure, I'd love to. I think the first task, as you described, requires manually looking for "those phrases" and replacing them. How to regenerate translations?

https://docs.gitlab.com/ee/development/i18n/externalization.html#updating-the-po-files-with-the-new-content

bin/rake gettext:regenerate

assigned to @paarth551

How to set up the codebase? After cloning, it showed some error saying cloned successfully but failed to checkout and when I use git status it shows a lot of deleted and untracked files.

https://docs.gitlab.com/ee/development/documentation/workflow.html might help

Basically you need to fork the repo, create a branch, make your changes then raise an MR to the upstream.

You could use GitPod, the WebIDE or single file editor if you want too, that saves you having to setup stuff locally.

removed Seeking community contributions label

mentioned in issue #352143 (closed)

added Track Health Status [DEPRECATED] label

changed milestone to %Backlog

mentioned in issue gitlab-com/Product#5218 (closed)

unassigned @paarth551

@paarth551 Thanks for volunteering to handle this before! I've unassigned you from this issue, as I believe there might be more work on the UI in this area in the future, and we might need to update the proposal to match before we work on this. So let's put this on hold for now (@jheimbuck_gl has already set this to %Backlog) and we'll revisit when the time is right.

mentioned in merge request !115388 (merged)

Thanks for sharing this issue, @sselhorn! Given gitlab-com/Product#5218 (closed), should we rename this issue to Use "compute credits" consistently instead of "pipeline minutes"?

changed title from Use "CI/CD minutes" consistently instead of "pipeline minutes" to Use "compute credits" instead of "CI/CD minutes", "pipeline minutes", etc.

changed the description

changed the description

changed the description

mentioned in merge request !115475 (closed)

assigned to @marcel.amirault

changed milestone to %15.11

@marcel.amirault - please see the following guidance and update this issue.

	1 Error
	Please add typebug typefeature, typemaintenance and a subtype label to this issue.

If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.

This message was generated automatically. You're welcome to improve it.

added featureenhancement typefeature labels

mentioned in epic gitlab-com&2150 (closed)

changed title from Use "compute credits" instead of "CI/CD minutes", "pipeline minutes", etc. to [Verify] Use "compute credits" instead of "CI/CD minutes", "pipeline minutes", etc.

added to epic gitlab-com&2150 (closed)

FYI - just made this a child epic to "CI minutes" > "compute minutes" (gitlab-com&2150 - closed) to make it easier to track. Thanks!

changed title from [Verify] Use "compute credits" instead of "CI/CD minutes", "pipeline minutes", etc. to [Verify] Use "compute" instead of "CI/CD minutes", "pipeline minutes", etc.

changed the description

added workflowin review label

changed the description

changed milestone to %16.0

added missed:15.11 label

mentioned in issue gl-retrospectives/verify-stage/pipeline-execution#41 (closed)

added Stretch label

@marcel.amirault is this still targeted for 16.0?

@jreporter Yeah, though the name seems to be changing to units of compute now, and I'll need to redo this if that name sticks. If that happens, we might consider this at risk

So far, the name is sticking

@marcel.amirault I saw Start renaming CI/CD minutes to compute credits (!115475 - closed) was closed - would the work still be targeted for 16.0 and handled in a different MR?

Moving to %16.1 based on this comment from @marcel.amirault, copied below.

@ipedowitz I've had a lot of 16.0 deprecation/removal-related work as well as handling TW duties for two more groups. Adding in the late change to Units of Compute terminology and a holiday period last week here in Japan means I couldn't start work on this in 16.0 (and the cutoff is earlier this release). This definitely won't happen until 16.1, unfortunately, even if we can find a friendly frontend engineer to do all the heavy lifting for us

added cicdactive label

changed milestone to %16.1

@marcel.amirault is this a docs-only change?

@jreporter I believe this was supposed to be frontend for the most part. I just tried to tackle it while improving the docs, and went down a rabbit hole trying to fix the UI at the same time. There's a lot of nuance in the UI though, so I think it would be good for me to attempt it myself, but all the 16.0 work coming in kept me too busy

@marcel.amirault - okay I see! Should we put it en queue for frontend development or is 16.1 reasonable?

@jreporter The reason I was trying to do it myself rather than a frontend engineer was that it seemed like every usage needed to be evaluated on a case-by-case basis, and I didn't know all the cases until I started digging in the code. There's a great example of this here: gitlab-com&2150 (comment 1379114594)

It seemed like I could save everyone some time... but if a frontend engineer is blocked on some other work and looking for something to do, it certainly wouldn't hurt to have them take a swing at updating one of the pages! Then they could send to me for review and I could suggest tweaks as needed.

Got it, feel free to tag me as needed if you feel capacity is getting away from you @marcel.amirault

Had a quiet morning and got the ball rolling: Update CI minutes settings to compute (!121361 - merged)

mentioned in merge request !121361 (merged)

Hi all - after speaking with David DeSanto today he let me know that this will block work for Remote Development on SaaS. I've updated the due date to be 2023-07-22 to align with the 16.2 milestone so that work for Remote Development on SaaS won't be blocked. Please let me know if you don't feel this is achievable.

FYI @marcel.amirault

@ipedowitz I aim to have this done within a week or two, within the 16.1 milestone, assuming we don't run into any major problems during MR reviews

mentioned in issue #407063 (closed)

@marcel.amirault I just realized the title says use "compute" instead of use "units of compute" - is that intended? We had settled on units of compute. Thanks!

changed title from [Verify] Use "compute" instead of "CI/CD minutes", "pipeline minutes", etc. to [Verify] Use "compute" / "units of compute" instead of "CI/CD minutes", etc.

mentioned in merge request !122015 (merged)

@marcel.amirault thanks for everything so far here! Given Update usage page to use "compute" instead of C... (!122015 - merged) was merged, is this ready to be closed?

@ipedowitz Like in the other issue, gimme a day or two to update all the issue descriptions with the details of backend code that probably needs to be cleaned up someday.

changed milestone to %16.2

added missed:16.1 label

mentioned in issue gl-retrospectives/verify-stage/pipeline-execution#43 (closed)

changed title from [Verify] Use "compute" / "units of compute" instead of "CI/CD minutes", etc. to [Verify] Use "compute minutes" instead of "CI/CD minutes", etc.

changed the description

added sectionci label and removed sectionops label

Hi all - it's been requested to update the renaming to compute minutes rather than units of compute. I've updated this issues title/description to reflect that. Thanks!

changed due date to October 22, 2023

Hi @marcel.amirault once Updating `units of compute` to `compute minutes` (!124671 - merged) merges, should this be closed? Thanks!

@ipedowitz Like in the other issue, I'd lean towards yes personally, but would want to ping an EM/Engineer to ask if they feel any followup issues are needed for code cleanup.

Thanks, Marcel! @fabiopitino would you be able to take a look at this from Engineering?

@marcel.amirault With the change from computes credits to compute minutes we actually don't need to do much renaming in code and keep Ci::Minutes:: namespace. There would be some renaming in the user facing messaging.

/cc @carolinesimpson

Thanks, @fabiopitino! Would it make sense to reassign this to you from Marcel/me for any follow-ups needed?

@ipedowitz - You could coordinate any follow-ups with @carolinesimpson

Thank you, Fabio! @carolinesimpson should I reassign this issue over to you? Thanks!

Sure @ipedowitz that is fine. I will verify that there are no additional follow-up issues needed for code cleanup and then close this issue.

Thanks, @carolinesimpson! Do you know when the verification would be able to be completed? Appreciate your help!

@ipedowitz I'm going to go ahead and close this now. But @drew can you verify that we don't have any additional code updates or create any follow-ups that are needed, please?

@carolinesimpson AFAIK this is fine to go ahead and close out. Around the codebase you will still see things like ci_minutes, because Ci is a whole module. So the Minutes class is Ci::Minutes, because it lives in lib/gitlab/ci/minutes, etc. We don't need to change this

Thanks, both! Are there any concerns with not renaming the module as we expand the offerings that compute minutes are the unit for?

@ipedowitz I don't think so at this point. It can always be revisited in the future if it causes an issues or if the grouppipeline execution no longer owns the base code in the future.

assigned to @ipedowitz

assigned to @carolinesimpson

unassigned @marcel.amirault and @ipedowitz

changed milestone to %16.3

added missed:16.2 label

mentioned in issue gl-retrospectives/verify-stage/pipeline-execution#44 (closed)

closed

added workflowcomplete label and removed workflowin review label