Talk:Wikimedia Cloud Services team/Rebranding Cloud Services products

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

2017-05-11 to 2017-05-31 discussion closed per pre-announced timeline.

The Wikimedia Cloud Services team will consider input provided here and begin formulating a concrete plan with timelines for making changes.

---

Call for participation

I am seeking constructive participation. Arguments that the status quo is fine and that changes are unneeded are not constructive. Suggestions of which problems have been missed or which changes would be of the most beneficially impact are constructive. Suggestions of past efforts which might be examined and other communities that have solved certain problems are constructive. Prognostications of failure due to past performance of initiative X, Y, or Z are not constructive.

More "What Would You Do If You Weren't Afraid?" and less "Who Moved My Cheese?" please. --BryanDavis (talk) 18:24, 11 May 2017 (UTC)

Minimizing link breakage

I think as much work as possible should be done to prevent breaking links. Even if we fix all the links on Wikimedia projects, we don't know where else links are being used. To this end, once we figure out a new approach, we should have robust redirect rules in place, such that tools.wmflabs.org/$1 consistently redirects to $1.wikimediatools.org (or whatever the domain is). This minimizes disruption and makes it easier for all of us since we won't have to immediately hunt down all the wmflabs.org links. Harej (talk) 20:41, 11 May 2017 (UTC)

I agree with this 100% line of thinking. In the current proposal I'm actually advocating for not changing the tools.wmflabs.org and other *.wmflabs.org URLs at all. There is a suggestion that in the future we tie transitioning away from the wmflabs.org domain to a major platform change that would start as a voluntary process and take a reasonable amount of time to fully complete. --BryanDavis (talk) 21:13, 11 May 2017 (UTC)

I must've misread, then. If the links are going to be stable then that's fine. (Alternatively, we could say no new domains on the wmflabs.org domain, have new subdomains on the new domain only, and encourage others to switch, but at their own pace.) Harej (talk) 21:18, 11 May 2017 (UTC)

I agree that having something named "Cloud Services" hosted at a domain that includes "labs" but not "Cloud" can be a bit puzzling, so I'd support the idea of creating new projects (and maybe also tools if that's possible) on new domains only. EddieGP (talk) 21:32, 11 May 2017 (UTC)

Name nitpicks

As a whole, I support re-branding. I've felt for a while that "Labs" is a misnomer, since the most significant software projects on Labs are in fact quasi-production, used in the real world. "Cloud" is probably not the best branding – depending on your tolerance for fads – but it's in common usage, it parallels services like Google Cloud, and I don't have any better ideas. So on the whole I say let's go for it. My nitpicks are as follows:

• I wasn't sure where the idea for "Tool Forge" came from, then I saw the Wikipedia article on software forges and it made a lot more sense. I assume this is a term in common usage and I just didn't know about it. But why Tool Forge, as opposed to something like Wikimedia Tools, if it's just going to be abbreviated as Tools anyway?
• To the extent we want as clear names as possible, I think we should reserve "Wikimedia Cloud" for the parent entity/brand, Wikimedia Cloud Services, and pick a different name for Cloud VPS, just as how it's Tool Forge / Tools and not "Cloud Tools." One obvious choice is "Wikimedia VPS" but I feel like we can do better.

Thank you for leading this! Harej (talk) 21:08, 11 May 2017 (UTC)

• I'll start another thread about "why cloud" because its a topic that is likely to drag on for a bit based on past discussions. :)
• I actually wasn't aware of w:Forge_(software), but its a nice tie in. For me the reference was more to w:Forge and the idea that those of us who craft custom software tools have similarities with town blacksmiths who provided a service of creating custom tools for their customers. This same core idea led to the naming of Striker as well.
• Product names with "Wikimedia" in them are things that the Foundation likes to trademark. This makes "Wikimedia Tools" more costly than "Tool Forge". Also "tools" is a generic term of art in the Wikimedia movement that covers a wide range of software that could be hosted/executed anywhere. Calling the shared hosting product maintained by Cloud Services "Tools" would be inventing a new version of the "labs labs labs" problem. "Tool Forge" distinguishes the product of our hosting environment tailored to the needs of tools from tools as a semi-generic term. People will naturally shorten it to Tools in some conversational contexts. There's really nothing that can be done about that.
• "Wikimedia VPS" has the same trademark issues as "Wikimedia Tools". My understanding (IANAL) is that the protection we are already planning to seek for "Wikimedia Cloud" will be structured such that "Wikimedia Cloud Services", "Wikimedia Cloud VPS", "Wikimedia Cloud $SOMETHING" are protected under the same filing. This needs to be solidly confirmed however. If this is not the case, the product branding should shift to something without "Wikimedia" in the name to avoid the trademark issues.

--BryanDavis (talk) 21:50, 11 May 2017 (UTC)

I think having Tool Forge refer specifically to the platform, and "tools" being a generic term, makes sense. If we are going in that direction, then documentation and branding materials should consistently refer to it as Tool Forge, and we should use that term as consistently as possible when referring to the Tool Forge platform. People might refer to it informally as "Tools" but such usage should not be encouraged (since, as you said, it's too ambiguous).

Re. the issue with "Wikimedia VPS," does that mean the brand needs to be "Wikimedia Cloud $1" or something without "Wikimedia" in it? Harej (talk) 22:13, 11 May 2017 (UTC)

"Yes". :) My current understanding is that if it is "Wikimedia $X" it really needs to be "Wikimedia Cloud $X" or we will have to spend a non-trivial amount of money and time to file an additional trademark. If it does not include "Wikimedia" I think we can mostly do what we want without many restrictions. I had "Wikimedia VPS" in the earlier drafts of this doc until that was pointed out to me. I do need to check with Legal to be 100% sure of this either way however. --BryanDavis (talk) 23:20, 11 May 2017 (UTC)

General term "project" in Phabricator

At the phabricator section, the very general term "project" is used often, and unfortunately sometimes without "VPS project". I think that's bad, because I'm not sure that this one is really unambiguous, especially in phabricator where there are "phabricator projects".

Most times it'll be clear from the context, but a sentence like "We should archive unused projects" might refer to language versions of Wikipedia, Wiktionary, Wikiversity, ... that should be locked, to old phabricator projects that should be marked as archived or to cloud projects which should be deleted. Especially we already have a #Project-Admins phabricator project, which is about creating new phabricator projects and has nothing to do with cloud services, but matches the suggested new naming convention #project-*.

Maybe we should go with #vps-project-* for "Volunteer projects" and #vps-project-requests for the milestone of #vps. I think it's worth to add those four characters to not run into a "Projects projects projects" at some point.

That's also more consistent: We're refering to "Misc volunteer tools" as #tools and to specific "Volunteer tools" as #tool-*. Also we're naming "Misc volunteer projects" #vps-projects, so making specific "Volunteer projects" be tagged with #vps-project-* would make sense in that way.

Thanks to everybody that you take time to care about this, reach out for feedback and put effort into resolving the Labs labs labs problem. As someone who started contributing to wm projects just a few months ago I remember that this ambiguity hit me often in the first weeks. I was so confused by it that I went to the Labs labs labs page about a dozen times the first day. EddieGP (talk) 21:20, 11 May 2017 (UTC) (PS: I probably won't look on this page again often or regularly, please feel free to ping me if there's some question or answer on this topic, thanks!)

@EddieGP: The overload of the term "project" in Phabricator is a great point and just the sort of thing that I was hoping for help spotting in this consultation. I'm going to update the proposal to use the "vps-" prefix as you have suggested. --BryanDavis (talk) 21:57, 11 May 2017 (UTC)

Thanks once again. Glad to have helped :-) EddieGP (talk) 22:06, 11 May 2017 (UTC)

Why was "cloud" chosen?

Cloud computing is a type of Internet-based computing that provides shared computer processing resources and data to computers and other devices on demand. It is a model for enabling ubiquitous, on-demand access to a shared pool of configurable computing resources (e.g., computer networks, servers, storage, applications and services), which can be rapidly provisioned and released with minimal management effort.—w:Cloud Computing

When Chase and I were putting together a pitch to form a new team we knew that one of the issues we wanted to take on strongly was the 'Labs labs labs' confusion that we had both seen people inside and outside of the Foundation struggle with. We tried out a lot of different names like "Wikimedia Hosting", "Wikimedia Web Services", etc. I was a proponent of "Wikimedia Cloud" through all of it for one simple reason that the excerpt from the enwiki article I think points out. The term "cloud computing" directly describes the suite of services that are offered by the Foundation to the movement via the team. Its also a word that non-technical people have some idea about. The idea that "cloud" means something about computer things is pretty strong (thanks mostly to horrible overuse in marketing in past years, yes). "Labs" could mean anything. Science, experiments, beta features, working on something. It does not distinctly say "computers that can be used to solve problems". The immediate recognition of "cloud" is what I advocated for, and ultimately won enough people over with. Adding "services" at the end to make "Wikimedia Cloud Services" was a late stage change, but one that I'm fine with. Our suite of products are services based on a common cloud computing model. Obviously this comes down to opinion at some point, but I really think that the over use of 'cloud' only affected the opinion of technology insiders (like say professional developers of web software). The majority of current and future Wikimedia Cloud Services customers are not members of this class. Love it, hate it, or be ambivalent about it; "cloud" here to stay at least until the next engineering reorg. --BryanDavis (talk) 23:06, 11 May 2017 (UTC)

Sounds good to me. Harej (talk) 23:51, 11 May 2017 (UTC)

VPS

I'm not a big fan of the "VPS" term for two reasons:

• It's not less ambiguous. I can't imagine us saying "you can run this on (a) VPS" without the other party getting confused or asking a follow-up question about in which realm to run this in. We have VPSes in prod and it's conceivable we might run VPSes in other realms as well.
• VPS in the industry has been used traditionally for static/persistent VMs, not "cloud" VMs that can be API-driven, ephemeral, elastic etc. Our OpenStack setup is a mixture of both probably, so this depends on what do you envision this service to be (cattle or pets?). This is a wider decision to be made there and could affect other decisions down the line, like whether it's OK to randomly kill running VMs of a project or whether you should be live-migrating them. Perhaps it would even make sense to split the two product offerings too?

faidon (talk) 13:47, 19 May 2017 (UTC)

Does anyone have a better suggestion for a short memorable term which implies "a self-service VM creation environment where the lifecycle of the resulting VM is under the control of the creator"? One of the primary intents of the renaming effort is to use terms which have meaning to the typical software developer who comes into the Wikimedia movement. This was why chose "cloud" rather than some more abstract product name.

Our current OpenStack product offering is much more VPS than say AWS or GCE aligned. We do not offer remote API access which would allow something like Vagrant to be used to create/manage VM instances. We also do not have block storage service which allows migrating VMs trivially from one exec node to another. These things will not be changing in the near term (i.e. fiscal year 2017/2018). In the longer term we do want block storage that allows migration between exec nodes. I don't know if or when fully programmatic instance lifecycle management will be worked on. (There is one exception to this in the CI project's use of nodepool, but that is actually a use case that the RelEng team is working towards eliminating by replacing VMs with containers for isolating test execution.)

We do promote the "cattle, not pets" point of view generally, but primarily by encouraging project owners to use existing Puppet modules to configure their VMs. We honestly don't have a great solution for projects who want Puppet management but are not intending to eventually deploy to the WMF production network. Upstreaming new Puppet modules into operations/puppet.git is not a trivial exercise for a volunteer developer. --BryanDavis (talk) 14:36, 19 May 2017 (UTC)

How about "Cloud Machines"? That keeps the branding coherent and is descriptive enough, I think? faidon (talk) 15:01, 21 May 2017 (UTC)

Tool Labs vs Tools vs Tool Forge vs Tools Forge vs ToolForge vs Tool

I have pitched this in person to a few people and I feel I have generally good feedback.

Tools Labs - We are moving away from this as part of the 'Labs' untangling

Tool Forge - A combination of Tool and Software Forge reference

Tools Forge - A commonly used extension of 'Tool Forge/Tools' already that is awkwardly plural

ToolForge - A compound word to marry the Tools environment and the Software Forge concept

Tool - The proper noun singular that refers to a bot/webservice/cron/analytics or distinct resource consuming entity within the Tools environment

Tools - This is the colloquial/familiar term for the environment where a Tool lives.

Outcome I'm proposing:

• ToolForge (can be shortened to Tools)

• Tool - A proper noun singular entity within Tools on either existing or any future scheduling or execution platform. Agnostic to scheduling mechanisms (one-time, ongoing, webservices, etc)

• Include these on Help:Terminology

Rush (talk) 12:42, 20 May 2017 (UTC)

@Rush: works for me. Do you want to w:WP:BOLD and make the edits that the proposal page needs to reflect this? --BryanDavis (talk) 12:45, 20 May 2017 (UTC)

If going with the "forge" naming, I'd recommend either "Toolforge" or "Tool Forge", not a camel case name. I'd also like to propose Tool Hub as additional option. Krinkle (talk) 21:25, 23 May 2017 (UTC)

Labsdb needs a new name

Labsdb currently refers to our public offering 'replicas of production MySQL databases' and the labsdb servers (which themselves hold the replicas, toolsdb and possible future analytics data). While the server naming may take longer to fix, we should fix the naming of our offered products, and the service URL names for the new setup.

Proposal:

• Rename the 'replicas of production MySQL databases' to 'Wiki Replicas' (Since these are really per wiki replicas of our production databases)
• Keep the ToolsDB name
• Any future new analytics thing would have it's own distinct name
• The service URL for the new replicas setup would be updated to wiki-replicas (or some version of it)

Madhuvishy (talk) 13:56, 20 May 2017 (UTC)

comments on remaing lists, domain name, phab questions

Renaming the mailing lists is reasonably easy nowadays, due to a helper script that replaced the former process with many steps.

Changing the domain name would be pretty disruptive indeed, i would probably leave that open last.

Phabricator questions: Is "#tool-labs-tools-other" just a tool that isn't "big" enough to have its own phab tag? Why is that a sub-project of a different parent though?

re: " The https://toolserver.org/ domain is still hosted by the Foundation more than three years after it was decommissioned for active use. ": It will probably stay forever since cool URIs don't change is such a strong mantra . I would maybe reconsider if changing the wmflabs.org domain is really worth it (but do all the rest).

dzahn (talk) 21:06, 23 May 2017 (UTC)

Is "#tool-labs-tools-other" just a tool that isn't "big" enough to have its own phab tag?

This was inherited from bugzilla. It tends to be used generally for "bugs in some tool that doesn't have its own project".

Why is that a sub-project of a different parent though?

My current proposal is to make #tools the catch-all bucket for tool related bugs and then nest tools with dedicated workboards under that umbrella project as sub-projects. That would mean that all tool related bugs would be searchable within the #tools project and likely that eventually all specific tools would show as workboard columns there too. (That's a not yet implemented feature request upstream). --BryanDavis (talk) 22:47, 23 May 2017 (UTC)

IRC channels, when will we start using the new irc channels?

Hi, i see the new branding for labs across wikitech. When will we start using the new irc channels? I also think #wikimedia-clouds is a better irc name then #wikimedia-cloud. Paladox (talk) 21:08, 23 May 2017 (UTC)

Probably sometime in June. In my announcement of the consultation I said comments would be open until at least 2017-05-26. Depending on what sort of feedback we end up getting there may be additional targeted rounds.

#wikimedia-clouds doesn't match up with any other branding that is currently proposed. I would like to see some level of consistency across mailing lists, phab, irc, and on-wiki terminology . --BryanDavis (talk) 22:38, 23 May 2017 (UTC)

IRC channels and mailing lists

"cloud-l" and "wikimedia-cloud" seem a bit ambiguous at first glance. They suggest that the channel/list is for the entire Wikimedia cloud, i.e. including Wikimedia production, which it is not. Tom29739 (talk) 11:34, 28 May 2017 (UTC)

The products managed by the Cloud Services team are really the only things in the Wikimedia computing infrastructure that meet the definition given in w:Cloud Computing ("a shared pool of configurable computing resources (e.g., computer networks, servers, storage, applications and services), which can be rapidly provisioned and released with minimal management effort"). Chase has taken to using the phrase "public cloud" to disambiguate from other possible confusion with the Ganetti virtual machines or Kubernetes cluster in the networks that are managed by the techops team. The use of the term "production" itself is problematic from my point of view because it implies that the products provided by the Cloud Services team are somehow not 'production' quality. --BryanDavis (talk) 14:55, 28 May 2017 (UTC)

Wikitech main page

I see that the Wikitech main page has been updated. Has the renaming effort already started? I thought this was still open for consultation. Tom29739 (talk) 11:45, 28 May 2017 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.