diff --git a/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.png b/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.png index 7d744e7401..0c7aa9aff2 100644 Binary files a/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.png and b/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.png differ diff --git a/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.svg b/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.svg index 4d6b887daa..7782fb38e6 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.svg +++ b/doc/contributor-guide/source/ux-ui-guidelines/figures/persona-ecosystem.svg @@ -1,325 +1 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -HARDWARE -CLOUD OS -API ENDPOINTS -DOMAIN -APPLICATION - - - Service Admin - - - - - - - - - Infra Architect - - - - - - - - - Cloud Ops - - - - - - - - - Automation Engineer - - - - - - - - - Datacenter Ops - - - - - - - - - Domain Ops - - - - - - - - - Project Owner - - - - - - - - - App Developer - - - - - - - - - App Architecture - - - - - - - - - - - - - - - - - Governance (Security and Compliance) - - - Business (Business Ops) - - - - Persona candidates - - - Personas - - - Identity and Access Managment - - - - - - - - - - Other teams that impact ecosystem - - +circle of shameHARDWARECLOUD OSAPI ENDPOINTSDOMAINAPPLICATIONService AdminAutomation EngineerDatacenter OpsTaylorDomain OperatorAdrianInfrastructure ArchitectWeiProject OwnerQuinnApp DeveloperApp ArchitectureReyCloud Operator \ No newline at end of file diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas.rst index cf2fb5a03a..e924f241b0 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas.rst @@ -1,32 +1,19 @@ .. _ux-personas: -=========================== -Meet the OpenStack personas -=========================== +================== +OpenStack personas +================== -In order to share the knowledge about the target users, we have created these -representations of our key audience segments based on qualitative and -quantitative user research. The goals are to create more empathy for our -customers and to better display the different types of customers performing -different jobs. - -We have identified five personas: - -* Adrian - Infrastructure Architect -* Rey - Cloud Operator -* Taylor - Domain Operator -* Wei - Project Owner -* Quinn - App Developer - -These personas are based on model companies and user ecosystems. Each -persona takes part in different cloud adoption stages and can assume multiple -roles within each company. - -The personas -~~~~~~~~~~~~ - -The personas fall into different phases of the cloud adoption workflow based -on their specific contribution. +We created personas to help you better define the OpenStack end-users who +benefit from your OpenStack contributions. After much qualitative +and quantitative research, we identified five personas that embody the most +common roles performed by OpenStack users. We also considered where these +personas fit into the cloud adoption workflow and how their roles may change +depending on the size and user ecosystem of their company. You can utilize +these personas in the design and development stage to help ensure user-centric +contributions and well defined use cases. When used consistently, personas +can help ensure your contributions lead to a positive user experience for +OpenStack adopters. .. toctree:: :maxdepth: 1 @@ -36,6 +23,37 @@ on their specific contribution. ux-personas/domain-operator.rst ux-personas/project-owner.rst ux-personas/app-developer.rst + ux-personas/model-companies.rst + +Meet the personas +----------------- + +:ref:`infrastructure-arch` + Adrian is responsible for the strategy and road-map for his company’s + cloud and identifies reasons to compel management to adopt OpenStack for + production environments. +:ref:`cloud-ops` + Rey is involved in installing, operating, using, and updating the + OpenStack cloud services. +:ref:`domain-operator` + Taylor manages the relationship with the cloud services provider. This + includes managing quotas, number of users, applicable policies, and + support tickets. +:ref:`project-owner` + Wei manages projects by adding or removing project members’ access to + the cloud instance. Wei’s main concern is to have enough resources + available to support Wei’s projects. +:ref:`app-developer` + Quinn develops and deploys cloud applications but does not necessarily + know much about the underlying infrastructure of the cloud. + +Role ecosystem +-------------- + +To better understand each persona role, see the following overall role +ecosystem, which is based on levels of abstraction from hardware to +application level. Within this ecosystem, we can see the current +personas as well as candidates for future personas. .. The original SVG copy of this figure is available in in the same directory. @@ -44,109 +62,28 @@ on their specific contribution. :align: center :width: 100% -The model companies -~~~~~~~~~~~~~~~~~~~ +The personas in the above ecosystem fall into different phases of the cloud +adoption workflow and are seen as separate and distinct from one another. +Although it is advantageous to separate the personas based on typical users, +some people, whom the personas represent, can assume multiple roles +depending on their workplace and company responsibilities. To appreciate +the personas in a different role ecosystem, see the following +:ref:`model-companies`: -We have identified three organizational models that best exemplify the roles -that the personas assume depending on their ecosystems. +:ref:`Nikishi-University` - Academic/Nonprofit +Wants to provide cloud services to their internal labs and have bare metal. +Do not want to hire resources internally to deploy trunk. -.. important:: +:ref:`CNBB-Securities` - Enterprise +Wants to provide cloud services to internal customers for applications that +are not customers facing. Has both bare metal and operations. - The institutions described in this document are fictitious and serve only - as representations of different organizational models. +:ref:`Rifkom` - Service provider +Wants to provide services to external customers that do not want or have +internal resources. Has both bare metal and operations resources internally. -Nikishi University - research ------------------------------ +:ref:`MOI` - Small/medium business +Wants to deploy customer-facing applications, but do not have bare metal or +a budget for operations resources. -At Nikishi university, each cloud user can potentially assume all personas' -roles. Although typically each individual specializes in two or more of the -roles. The Infrastructure Architect and the Cloud Operator roles -could be assumed by a single individual. Similarly, the Domain Operations and -Project Owner roles could be merged. This organizational model has a low -staffing budget and is concerned with capital expenditure causing them to -create their own implementation. -.. list-table:: **Nikishi University - Key Info** - :widths: 15 15 15 15 - :header-rows: 1 - - * - Adoption model - - Process and compliance - - Skill depth - - Number of users - * - Roll your own - - Minimal - - Deep - - 100 to 999 users - -CNBB Securities - large enterprise ----------------------------------- - -At CNBB Securities, the company's large organization chart represents each of -the personas. Depending on the company's culture of collaboration, the -personas could interact as if they were part of a single entity. However, -usually the Cloud Operator and the Infrastructure Architect interact as -service providers with the other personas. The personas within CNBB -Securities look for a fast implementation and are responsible for the -operations capital expenditure. The implementation has no customization and -the organization usually outsources its support. - -.. list-table:: **CNBB Securities - Key Info** - :widths: 15 15 15 15 - :header-rows: 1 - - * - Adoption model - - Process and compliance - - Skill depth - - Number of users - * - Distribution with professional services - - High - - Medium - - Over 10000 users - -Rifkom - service provider -------------------------- - -At Rifkom, employees provide services to external customers that do not want -or have the internal resources. Rifkom customizes solutions and -prioritizes a flexible approach to architecture. The highly skilled staff -represents the largest expenditure for Rifkom. Only Infrastructure Architects -and Cloud Operators work at Rifkom since the other personas are their -customers at MOI. Customers usually interact with Rifkom employees through a -ticket system. - -.. list-table:: **Rifkom - Key Info** - :widths: 15 15 15 15 - :header-rows: 1 - - * - Adoption model - - Process and compliance - - Skill depth - - Number of users - * - Roll your own - - Medium to High (depends on customer) - - Deep - - 1000 to 9999 users - -MOI - customer --------------- - -At MOI, speed and convenience rule. Its staff encompasses the roles of App -Developers, Project Owners, and Domain Operations. They do not perform any -customization of the cloud and are willing to sacrifice functionality in -order to save some costs. They interact with their cloud service provider, -Rifkom, through a ticket system in case of problems with their cloud -instance. - -.. list-table:: **MOI - Key Info** - :widths: 15 15 15 15 - :header-rows: 1 - - * - Adoption model - - Process and compliance - - Skill depth - - Number of users - * - Professional services - - Medium - - Minimal - - No OpenStack users diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/app-developer.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/app-developer.rst index 74cbdf36ec..28de290613 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/app-developer.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/app-developer.rst @@ -4,8 +4,12 @@ Quinn - application developer ============================= -Quinn develops and deploys cloud applications but does not necessarily know -much about the underlying infrastructure of the cloud. +Quinn spends very little to no time researching OpenStack. Quinn does not +care how the cloud instances used were installed, as long as they work +exactly as expected and the needed APIs do not change unexpectedly. Quinn +does not control what tool is used to install and maintain the cloud +instances. However, Quinn determines the requirements for those cloud +instances. Any changes made to the APIs greatly impact Quinn's work. Cloud applications are defined as: @@ -41,28 +45,6 @@ Quinn performs the following tasks frequently: * Deployment: Deploys applications to one or multiple cloud instances. -Key information -~~~~~~~~~~~~~~~ - -Quinn spends very little to no time researching OpenStack. Quinn does not -care how the cloud instances used were installed, as long as they work -exactly as expected and the needed APIs do not change unexpectedly. Quinn -does not control what tool is used to install and maintain the cloud -instances. However, Quinn determines the requirements for those cloud -instances. Any changes made to the APIs greatly impact Quinn's work. - -The organizational models -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The tasks that the persona performs within a certain organizational model are -important for the usability of your OpenStack development. Within a small -organization, such as Rifkom or Nikishi University, Quinn might be required -to assume some roles and responsibilities of a Domain Operator or a Cloud -Operator. Within a larger organization, like CNBB Securities, Quinn will -likely not work alone on an application. Multiple application developers -would need to access a single cloud to develop, test, and deploy the same -application, making user control a requirement for the cloud. - Your development ~~~~~~~~~~~~~~~~ @@ -78,3 +60,18 @@ resources are missing in such a way, that Quinn can ask a Cloud or Domain operator to add those resources. Quinn will not add the resources. Therefore, ensure that notifications are clear and do not require any advanced knowledge of OpenStack to identify the issues. + +The organizational models +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The tasks that the persona performs within a certain organizational model are +important for the usability of your OpenStack development. Within a small +organization, such as Rifkom or Nikishi University, Quinn might be required +to assume some roles and responsibilities of a Domain Operator or a Cloud +Operator. Within a larger organization, like CNBB Securities, Quinn will +likely not work alone on an application. Multiple application developers +would need to access a single cloud to develop, test, and deploy the same +application, making user control a requirement for the cloud. See +:ref:`model-companies` for more information on how Quinn fits into different +user ecosystems. + diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/cloud-ops.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/cloud-ops.rst index 1413f92300..6a6b95e0b6 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/cloud-ops.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/cloud-ops.rst @@ -1,13 +1,15 @@ .. _cloud-ops: -====================== -Rey - cloud operations -====================== +==================== +Rey - cloud operator +==================== -Rey is involved in installing, operating, using, and updating the OpenStack -cloud services. Rey ensures that the cloud is up and running and must fix any +Rey ensures that the cloud is up and running and must fix any issues as soon as possible. Collaborating with unskilled IT personnel is very -challenging for Rey. +challenging for Rey. Rey spends some time every day searching for information +on the OpenStack website, and has attended the OpenStack Summit once. Rey +uses any useful tool in operating the cloud. Rey's previous role as a +Linux system administrator influenced their decision to use OpenStack. Key tasks ~~~~~~~~~ @@ -25,26 +27,6 @@ Rey performs the following tasks very frequently: * Update: Performs updates and verification of the OpenStack cloud. -Key information -~~~~~~~~~~~~~~~ - -Rey spends some time every day searching for information on the OpenStack -website and has attended the OpenStack Summit once. Rey uses any useful tool -in operating the cloud. Rey's previous role as a Linux system administrator -influenced the decision to use OpenStack. - -The organizational models -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The tasks that the persona performs within a certain organizational model are -important for the usability of your OpenStack development. Within a small -company, Rey might be required to assume some of the responsibilities of -both the Infrastructure Architect and the Domain Operator. Within a larger -company, multiple individuals could perform subsets of Rey's tasks. For -example, one person could be in charge of installing and updating the cloud -instances, while another could be in charge of monitoring operations and -usage, and yet another person could be in charge of solving issues. In -Rey's organization, Rey is responsible for all of these tasks. Your development ~~~~~~~~~~~~~~~~ @@ -102,3 +84,18 @@ anticipate and compensate when preparing a project: The scale of quotas presents significant obstacles for operators. Consider that Rey may need to manage over one thousand projects in a deployment. + +The organizational models +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The tasks that the persona performs within a certain organizational model are +important for the usability of your OpenStack development. Within a small +company, Rey might be required to assume some of the responsibilities of +both the Infrastructure Architect and the Domain Operator. Within a larger +company, multiple individuals could perform subsets of Rey's tasks. For +example, one person could be in charge of installing and updating the cloud +instances, while another could be in charge of monitoring operations and +usage, and yet another person could be in charge of solving issues. In +Rey's organization, Rey is responsible for all of these tasks. For more +information on how Rey fits into different user ecosystems, see +:ref:`model-companies`. diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/domain-operator.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/domain-operator.rst index 1b9957b70c..6f0d9260bf 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/domain-operator.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/domain-operator.rst @@ -4,15 +4,16 @@ Taylor - domain operator ======================== -Taylor manages the relationship with the cloud services provider. This -includes managing quotas, number of users, applicable policies, and support -tickets. Taylor does not have any major concerns about the underlying +Taylor does not have any major concerns about the underlying infrastructure of the cloud and ensures that the :abbr:`SLA (Service-Level Agreement)` is followed. -Taylor needs to know about any outages, both scheduled and unscheduled. -Unscheduled outages cause a lot of problems for Taylor, as ideally there -would never be an unscheduled outage. +Taylor spends no time researching OpenStack. It is likely that Taylor does +not even know that the cloud service provider uses OpenStack and does not +care how the cloud instances are run, as long as they run without unexpected +outages. Taylor expects to be provided with adequate monitoring tools. Adding +and removing users from the provided cloud services should be as easy as +possible, in Taylor's opinion. Key tasks ~~~~~~~~~ @@ -30,26 +31,6 @@ Taylor performs the following tasks very frequently: * Ensuring SLA compliance: Monitors the various policies and support tickets to ensure that the agreed terms are being fulfilled. -Key information -~~~~~~~~~~~~~~~ - -Taylor spends no time researching OpenStack. It is likely that Taylor does -not even know that the cloud service provider uses OpenStack and does not -care how the cloud instances are run, as long as they run without unexpected -outages. Taylor expects to be provided with adequate monitoring tools. Adding -and removing users from the provided cloud services should be as easy as -possible, in Taylor's opinion. - -The organizational models -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The tasks that the persona performs within a certain organizational model are -important for the usability of your OpenStack development. Within a small -organization, such as Rifkom or Nikishi University, Taylor might be required -to assume some roles and responsibilities of a Cloud Operator or a Project -Owner. Within a larger organization, like CNBB Securities, Taylor's tasks are -performed by the team managing the cloud services provider. - Your development ~~~~~~~~~~~~~~~~ @@ -68,3 +49,15 @@ require any advanced knowledge of OpenStack to identify the issues. If your development modifies the user management of the cloud, ensure to take Taylor into consideration. User management should be as simple as possible and it should not require deep knowledge about OpenStack. + +The organizational models +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The tasks that the persona performs within a certain organizational model are +important for the usability of your OpenStack development. Within a small +organization, such as Rifkom or Nikishi University, Taylor might be required +to assume some roles and responsibilities of a Cloud Operator or a Project +Owner. Within a larger organization, like CNBB Securities, Taylor's tasks are +performed by the team managing the cloud services provider. To see more on +how roles change within organizations, see :ref:`model-companies`. + diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/infrastructure-arch.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/infrastructure-arch.rst index 21023d3a7e..8238506ee7 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/infrastructure-arch.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/infrastructure-arch.rst @@ -4,13 +4,13 @@ Adrian - infrastructure architect ================================= -Adrian is responsible for the strategy and road-map for his company's cloud -and identifies reasons to compel management to adopt OpenStack for production -environments. The reasons that would deter Adrian from recommending OpenStack -are frequent instabilities, non-deterministic errors, the inability to create -an environment, and missing documentation. Similarly to the domain operator, -Adrian needs to know about any outage conditions that may occur on both -testing and production environments. +Adrian spends a lot of time reading and researching information about +OpenStack and other cloud technologies. Adrian has attended more than one +OpenStack summit, and contributes solutions to the community regularly. Adrian +values OpenStack and is committed to drive adoption. Adrian's priority, +however, is a fully functional and stable cloud that fulfills all of his +requirements. Your development affects Adrian if it modifies the scope, +implementation, or usage of OpenStack. Key tasks ~~~~~~~~~ @@ -31,35 +31,28 @@ Adrian performs the following tasks very frequently: * Cloud planning: Defines and plans the cloud while considering hardware, platform choices, services, and scale. -Key information -~~~~~~~~~~~~~~~ - -Adrian spends a lot of time reading and researching information about -OpenStack and other cloud technologies. Adrian has attended more than one -OpenStack summit and contributes solutions to the community regularly. Adrian -values OpenStack and is committed to drive adoption. Adrian's priority, -however, is a fully functional and stable cloud that fulfills all of his -requirements. - -The organizational models -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The tasks that the persona performs within a certain organizational model are -important for the usability of your OpenStack development. Within a small -organization, such as Rifkom or Nikishi University, Adrian might be required -to assume some roles and responsibilities of a Cloud Operator or, more -rarely, a Domain Operator. Within a larger organization, like CNBB -Securities, Adrian's tasks are performed by the team planning and implementing -the cloud instances. - Your development ~~~~~~~~~~~~~~~~ Adrian's main concern is the cloud's architecture. Adrian interacts directly -with OpenStack and has probably developed any pieces that were needed. Your +with OpenStack and has probably developed many pieces that were needed. Your development targets Adrian if it makes any changes to the way clouds are implemented and deployed. Any new features, fixes, and limitations are important to Adrian. -If your development modifies the scope, implementation, and usage of -OpenStack ensure to take Adrian into consideration. +The reasons that would deter Adrian from recommending OpenStack +are frequent instabilities, non-deterministic errors, the inability to create +an environment, and missing documentation. Similarly to the domain operator, +Adrian needs to know about any outage conditions that may occur on both +testing and production environments. + +The organizational models +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Within a small organization, such as Rifkom or Nikishi University, +Adrian might be required to assume some roles and responsibilities of a +Cloud Operator or, more rarely, a Domain Operator. Within a larger +organization, like CNBB Securities, Adrian's tasks are performed by the +team planning and implementing the cloud instances. See :ref:`model-companies` +for more information on how Adrian fits into different user ecosystems. + diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/model-companies.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/model-companies.rst new file mode 100644 index 0000000000..be47dfd446 --- /dev/null +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/model-companies.rst @@ -0,0 +1,133 @@ +.. _model-companies: + +=================== +The model companies +=================== + +This page allows you to see how different companies and user ecosystems +influence a specific persona's role. We have identified four model companies +with three organizational models that best exemplify the companies decision +to adopt OpenStack. Use these companies to help refine your use cases for a +specific type of organizational paradigm. The factors we chose to distinguish +the different model companies include the cloud adoption model, operations, +security needs, and compliance. + +.. important:: + + The institutions described in this document are fictitious and serve only + as representations of different organizational models. + +.. _Nikishi-University: + +Nikishi University - research +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At Nikishi university, each cloud user can potentially assume all persona +roles. Although typically each individual specializes in two or more of the +roles. + +.. list-table:: **Nikishi University - Key Info** + :widths: 15 15 15 15 + :header-rows: 1 + + * - Adoption model + - Process and compliance + - Skill depth + - Number of users + * - Roll your own + - Minimal + - Deep + - 100 to 999 users + +* The roles of :ref:`infrastructure-arch` and :ref:`Cloud-Ops` + could be assumed by a single individual. +* The roles of :ref:`Domain-Operator`, :ref:`Project-Owner`, + and :ref:`app-developer` could be merged. + +This organizational model has a low staffing budget and is concerned with +capital expenditure, which influenced their decision to create their own +implementation. + +.. _CNBB-Securities: + +CNBB Securities - large enterprise +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At CNBB Securities, the company's large organization chart represents each of +the personas. Depending on the company's culture of collaboration, the +personas could interact as if they were part of a single entity. + +.. list-table:: **CNBB Securities - Key Info** + :widths: 15 15 15 15 + :header-rows: 1 + + * - Adoption model + - Process and compliance + - Skill depth + - Number of users + * - Distribution with professional services + - High + - Medium + - Over 10000 users + +* Usually the roles of :ref:`Cloud-Ops` and :ref:`Infrastructure-Arch` + interact as service providers with the other personas. + +The personas within CNBB Securities look for a fast implementation and are +responsible for the operations capital expenditure. The implementation has no +customization and the organization usually outsources its support. + +.. _Rifkom: + +Rifkom - service provider +~~~~~~~~~~~~~~~~~~~~~~~~~ + +At Rifkom, employees provide services to external customers that do not want +or have the internal resources. Rifkom customizes solutions and +prioritizes a flexible approach to architecture. The highly skilled staff +represents the largest expenditure for Rifkom. + +.. list-table:: **Rifkom - Key Info** + :widths: 15 15 15 15 + :header-rows: 1 + + * - Adoption model + - Process and compliance + - Skill depth + - Number of users + * - Roll your own + - Medium to High (depends on customer) + - Deep + - 1000 to 9999 users + +* Only the roles of :ref:`Infrastructure-Arch` and :ref:`Cloud-Ops` exist at + Rifkom. The other personas are their customers at MOI. + +Customers usually interact with Rifkom employees through a ticket system. + +.. _MOI: + +MOI - customer +~~~~~~~~~~~~~~ + +At MOI, speed and convenience rule. They do not perform any customization of +the cloud and are willing to sacrifice functionality in order to save some +costs. They interact with their cloud service provider, Rifkom, through a +ticket system in case of problems with their cloud instance. + +.. list-table:: **MOI - Key Info** + :widths: 15 15 15 15 + :header-rows: 1 + + * - Adoption model + - Process and compliance + - Skill depth + - Number of users + * - Professional services + - Medium + - Minimal + - No OpenStack users + +* MOI's staff encompasses the roles of :ref:`App-Developer`, + :ref:`Project-Owner`, and :ref:`Domain-Operator`. Other roles are external. + diff --git a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/project-owner.rst b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/project-owner.rst index 2a63ec7401..69eb84e067 100644 --- a/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/project-owner.rst +++ b/doc/contributor-guide/source/ux-ui-guidelines/ux-personas/project-owner.rst @@ -4,11 +4,13 @@ Wei - project owner =================== -Wei manages projects by adding or removing project members' access to the -cloud instance. Wei does not know the underlying infrastructure nor the -OpenStack projects involved. Wei's main concern is to have enough resources -available to support Wei's projects. Therefore, if a project runs out of -quota, Wei does not want to have to wait for the operators to raise it. +Wei does not know or care about whether OpenStack is being used for the cloud +instance that the projects use or not. Wei's concern is to have enough +resources whenever they are needed. If Wei's requests for additional +resources take too long to be fulfilled, Wei will start looking for +alternatives until the project's needs are met. +Therefore, if a project runs out of quota, Wei does not want to have to wait +for the operators to raise it. Key tasks ~~~~~~~~~ @@ -24,14 +26,19 @@ Wei performs the following tasks very frequently: * Managing projects: Coordinates project resources to ensure its success and the OpenStack cloud is another resource among many other. -Key information -~~~~~~~~~~~~~~~ +Your development +~~~~~~~~~~~~~~~~ -Wei does not know or care about whether OpenStack is being used for the cloud -instance that the projects use or not. Wei's concern is to have enough -resources whenever they are needed. If Wei's requests for additional -resources take too long to be fulfilled, Wei will start looking for -alternatives until the project's needs are met. +When your development affects the behavior of the capacity of cloud +instances, you should consider Wei as an interested party. Ensuring that +changes to the capacity of cloud instances can occur as easily and as quickly +as possible certainly has a positive impact on Wei's work, for example. +However, Wei does not perform those changes in capacity directly. + +Finally, consider that Wei is a highly skilled developer with little +knowledge of OpenStack and with little time for long, complex research. +Therefore, your solutions for Wei must be focused on enabling others to +provide the needed resources as quickly as possible. The organizational models ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -49,18 +56,6 @@ owner and the company could have several projects. Whatever the case, it is highly likely that Wei is an experienced application developer as well. See the information pertaining to the application -developer persona here: :ref:`app-developer` +developer persona here: :ref:`app-developer`. To see more on +how roles change within organizations, see :ref:`model-companies`. -Your development -~~~~~~~~~~~~~~~~ - -When your development affects the behavior of the capacity of cloud -instances, you should consider Wei as an interested party. Ensuring that -changes to the capacity of cloud instances can occur as easily and as quickly -as possible certainly has a positive impact on Wei's work, for example. -However, Wei does not perform those changes in capacity directly. - -Finally, consider that Wei is a highly skilled developer with little -knowledge of OpenStack and with little time for long, complex research. -Therefore, your solutions for Wei must be focused on enabling others to -provide the needed resources as quickly as possible.