Wikimedia Cloud Services team/Our audiences

Wikimedia Cloud Services caters to a broad spectrum of users, ranging from contributors with limited coding experience to professional software engineers.

This is an approximation so there are probably errors. There is probably overlap with broader notions of audiences in the Wikimedia movement, while going into more specific detail (e.g. by discussing WMF-internal stakeholders).

User goals

 * Code testers – Software developers, usually people working on MediaWiki, set up Cloud VPS instances (sometimes using MediaWiki-Vagrant) to test the code they are working on. Many of these developers work on Wikimedia Foundation product teams. These developers are not working on tools for public consumption, meaning there is less of an emphasis on scalability or application-level security, and are unlikely to be served by tool discoverability projects, but would likely benefit from projects meant to make Cloud VPS a better place to develop software.
 * Questions: How well are developers served by the current setup? How can we make it easier to set up wikis that can be used for testing code? Who uses Vagrant and who doesn't? Why?
 * Researchers – In this context, "researcher" refers to someone trying to find an answer to a question, and not necessarily to someone with a particular academic background or level of coding skill. Researchers use the dumps and wiki replicas via Toolforge, Quarry, and PAWS (and Cloud VPS in some more sophisticated cases) to write/run scripts and database queries to figure something out about the Wikimedia projects.
 * Questions: How can we make the Quarry and PAWS experience better? How do we provide a more unified Data Services experience?
 * Tool developers – Software developers will use Toolforge (and occasionally Cloud VPS) to host tools they have developed. These tools take the form of web applications and bots (including continuously run and periodically run). Some of these tools are used very heavily and have needs comparable to production-grade software even if they are not in WMF production. They also stand to benefit from projects to improve tool discoverability and to build community around tool developers and users.
 * This audience is a major focus of the tools catalog project.
 * Questions: How do we make it easier to deploy tools? How do we make it easier to scale them? How do we make it easier for tools to be resilient?
 * Tool end-users – These are the people who use the tools created by tool developers. They may have no coding skills and little technical know-how.
 * Question: How do we make it easier for tool users to constructively communicate with tool developers? How do we help users learn more about the platform that hosts tools they use? How do we communicate significant outages to this group?

User effort required

 * No technical skills needed – in an ideal world, it is possible to undertake an activity on Wikimedia Cloud Services with little or no technical skills. Many tool end-users fall into this category, but WMCS' own offerings are not currently ideal for this level of effort.
 * Some code – If you can write some code or an SQL query, you can write code on the PAWS web shell or a query on the Quarry database service. The graphical interface means no "command line tax" – just write code.
 * Code and command line – The Toolforge platform as a service is intended for setting up and deploying software applications using Grid Engine or Kubernetes. Beyond writing the code needed to solve problems, the user must also have at least a basic understanding of command line use, including logging in via SSH, submitting jobs to the Grid Engine, setting up virtual environments, and so on.
 * System administration – The Cloud VPS product requires knowing how to provision virtual machines, configure them, update them, etc. This offering requires the most technical knowledge but also offers the most power to the user.
 * Advanced system administration – For particularly advanced use cases, Cloud VPS users can develop/enable Puppet roles and use Puppet to automatically provision VPS instances. This group includes many Wikimedia Foundation engineers. Some users in this group are interested in having a setup that is as close to production as possible.

Wikimedia Foundation stakeholders

 * Audiences – Teams in Wikimedia Audiences test their code through wikis hosted on our infrastructure. Example: https://commtech.wmflabs.org/ (significant overlap with the "code testers" group)
 * Parsing – The parsing team used virtual machines on Cloud VPS to conduct quality assurance testing on their new HTML parser by comparing it to real content. See at around 36:55.
 * Community Engagement – Certain tools hosted on Toolforge and Cloud VPS are indispensable to CE's operations, including the Projects and Events Dashboard.
 * Technology
 * Analytics – Wikimedia Cloud Services will be the home of the dumps, including the analytics dumps. There is also a data lake hosted on our infrastructure, and they have several Cloud VPS instances.
 * Release Engineering – As part of the software deployment process, code is deployed to the Beta Cluster before entering production. The Beta Cluster is a Cloud VPS project and sort of the raison d'être of Cloud VPS to begin with.
 * Site Reliability Engineering – SRE uses Cloud VPS to evaluate new software tools and to test configuration changes.
 * Research – Experimental APIs and services are run on Cloud Services. Example: https://secrec.wmflabs.org/