m (→Persona #3) |
mNo edit summary |
||
(72 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
{{admon/ | {{admon/note| This is a living document. | This document can be updated as discussion dictates, etc. Not sure why we have personas? Read the [https://fedoraproject.org/wiki/Server/Personas/FAQ Personas FAQ]. | ||
}} | }} | ||
= Discussion = | |||
Why do we have personas for the server product? [https://fedoraproject.org/wiki/Server/Personas/FAQ Read the personas FAQ]. | |||
* [https://lists.fedoraproject.org/pipermail/server/2013-October/000224.html Discussion of Fedora Server use-cases mailing list thread] | |||
* [https://fedoraserver-wgblog.rhcloud.com/?p=32 November 19 2013 meeting] | |||
* December 10 2013 Meeting | |||
* December 17 2013 Meeting | |||
= Personas = | = Personas = | ||
Line 10: | Line 17: | ||
* A mid-level Microsoft administrator who does not have time for a steep learning curve. | * A mid-level Microsoft administrator who does not have time for a steep learning curve. | ||
== Persona #1 == | == Primary Personas == | ||
=== Persona #1: SysAdmin MacGuyver === | |||
<div style="float: left;"> | <div style="float: left;"> | ||
Line 21: | Line 30: | ||
<span style="font-size: 14px;"> | <span style="font-size: 14px;"> | ||
Senior System Administrator | Senior System Administrator; New Amsterdam Historical Society | ||
</span> | </span> | ||
Line 33: | Line 42: | ||
{| | {| | ||
! Profile | ! Profile | ||
| MacGyver | | SysAdmin MacGyver | ||
|- | |- | ||
! Age | ! Age | ||
| | | 36 | ||
|- | |- | ||
! Location | ! Location | ||
Line 56: | Line 65: | ||
=== Motivation === | ==== Motivation ==== | ||
* Keep IT team within budget. | * Keep IT team within budget. | ||
* Minimize late-night phone calls. | * Minimize late-night phone calls. | ||
=== Goals === | ==== Goals ==== | ||
* Clean, secure, and manageable deployment of multiple server applications to a single server. | * Clean, secure, and manageable deployment of multiple server applications to a single server. | ||
Line 68: | Line 77: | ||
* Ability to easily deploy apps to underutilized resources. | * Ability to easily deploy apps to underutilized resources. | ||
=== Frustrations === | ==== Frustrations ==== | ||
* Home-grown scripts for deploying apps that have been around forever that have mysterious voodoo power. Difficult to reproduce application deployments consistently. | * Home-grown scripts for deploying apps that have been around forever that have mysterious voodoo power. Difficult to reproduce application deployments consistently. | ||
* Proliferation of various management console interfaces to have to manage. | * Proliferation of various management console interfaces to have to manage. | ||
=== Work Description === | ==== Work Description ==== | ||
< description of a typical work day goes here. > | < description of a typical work day goes here. > | ||
<hr /> | |||
== Persona #2 == | === Persona #2: DevOps === | ||
<div style="float: left;"> | <div style="float: left;"> | ||
Line 93: | Line 103: | ||
<span style="font-size: 16px; font-style: italic;"> | <span style="font-size: 16px; font-style: italic;"> | ||
"I want to build amazing, easy-to-deploy server applications for my clients." | |||
</span> | </span> | ||
Line 101: | Line 111: | ||
{| | {| | ||
! Profile | ! Profile | ||
| | | DevOps | ||
|- | |- | ||
! Age | ! Age | ||
| | | 27 | ||
|- | |- | ||
! Location | ! Location | ||
| | | San Francisco, California | ||
|- | |- | ||
! Technical Level | ! Technical Level | ||
| | | Journeyman | ||
|- | |- | ||
! Years Experience | ! Years Experience | ||
| | | 7 | ||
|- | |- | ||
! Primary Tools | ! Primary Tools | ||
| | | Uses a MacBook Pro as his workstation. Uses Ruby on Rails and Github. | ||
|- | |- | ||
! Referrals | ! Referrals | ||
| | | RubyWeekly, Ruby Insider, engadget, lifehacker, ... (?) | ||
|} | |} | ||
</div> | </div> | ||
=== Motivation === | ==== Motivation ==== | ||
* Use the latest and best technology to solve interesting problems. | |||
* Produce high-quality applications that excite my clients and build a great reputation for it. | |||
* Grow my business and gain key clients. | |||
==== Goals ==== | |||
* Agility | |||
* Rapid recovery / rebuild of servers when they go down. | |||
* Anticipating outages / becoming aware of outages before they happen or as soon as possible in order to mitigate them. | |||
* Seamless migrations/upgrades of my applications. | |||
* Deploy projects to PaaS, multiple cloud providers, and even bare-metal | |||
(Perhaps not relevant to Server) | |||
* | * Balance multiple ongoing development projects at the same time. | ||
=== Frustrations === | ==== Frustrations ==== | ||
* | * Platform bugs that casue me to spend cycles porting my code forward. It's time-consuming and uninteresting work. | ||
* | * Cloud providers that change their APIs in an incompatible way with little notice! Having to develop new connectors for production servers with only a few days' notice is not cool. | ||
* Spending cycles packaging code up for an endless array of platforms - it's time-consuming and uninteresting work. | |||
* Building software on a platform so old it doesn't have the python or ruby library I need and not being able to pull it in from out-of-stream. | |||
* Being forced to build on top of or connect together poorly or undocumented platforms, and/or use weak platform APIs | |||
* Frameworks configured by default to require a lot of customization. I want to start running right away instead of getting bogged down in that kind of detail. | |||
=== Work Description === | ==== Work Description ==== | ||
< description of a typical work day goes here. > | < description of a typical work day goes here. > | ||
== Persona #3 == | <hr /> | ||
=== Persona #3: Traditional App Developer === | |||
<div style="float: left;"> | |||
[[Image:serverwg-persona-traditionaldev.jpg]] | |||
</div> | |||
<span style="font-size: 22px; font-weight: bold;"> | |||
George Simpson | |||
</span> | |||
<span style="font-size: 14px;"> | |||
Principal Application Developer, Defense Contractor | |||
</span> | |||
<span style="font-size: 16px; font-style: italic;"> | |||
"Critical bugs could seriously injure real people, or worse. We have a strict regimen behind our development process to minimize risk." | |||
</span> | |||
<br /> | |||
<div style="float: right; padding-left: 30px;"> | |||
{| | |||
! Profile | |||
| Traditional Developer | |||
|- | |||
! Age | |||
| 43 | |||
|- | |||
! Location | |||
| Washington, DC | |||
|- | |||
! Technical Level | |||
| Master | |||
|- | |||
! Years Experience | |||
| 22 | |||
|- | |||
! Primary Tools | |||
| Uses a Thinkpad as his workstation, emacs, gcc and git. | |||
Has a smartcard and various x509 certificates to access critical systems. | |||
|- | |||
! Referrals | |||
| ACM? IEEE? USENIX? LISA? | |||
|} | |||
</div> | |||
==== Motivation ==== | |||
* Keep the people interfacing with my software safe. | |||
==== Goals ==== | |||
* Stability and predictability | |||
* Minimize risk; vet every code change before it gets in and causes potential problems. | |||
==== Frustrations ==== | |||
* Bureacracy - although I understand why it's in place, it takes the effort of moving a mountain to move a molehill in this codebase. | |||
* Hardware vendors not supporting hardware for as long as we need to run it in the field. | |||
* Testing matrix requires a lot of infrastructure to perform various tests in a reasonable time frame on as many configurations as possible. | |||
==== Work Description ==== | |||
* Triage of bugs filed by support/users | |||
* Short daily or weekley status meetings | |||
* Prepares design documents for new futures or bug fixes | |||
* One of the following: | |||
** Writes code/bugfixes | |||
** Writes unit tests | |||
** Writes memos for doc writers or writes documentation directly | |||
<hr /> | |||
=== Persona #4: Junior Enterprise SysAdmin === | |||
<div style="float: left;"> | <div style="float: left;"> | ||
Line 160: | Line 255: | ||
<span style="font-size: 16px; font-style: italic;"> | <span style="font-size: 16px; font-style: italic;"> | ||
"Automation is critical to managing a rollout to a server environment this large." | |||
</span> | </span> | ||
Line 168: | Line 263: | ||
{| | {| | ||
! Profile | ! Profile | ||
| | | Junior Enterprise SysAdmin | ||
|- | |- | ||
! Age | ! Age | ||
| | | 24 | ||
|- | |- | ||
! Location | ! Location | ||
| | | Jersey City, NJ | ||
|- | |- | ||
! Technical Level | ! Technical Level | ||
| | | Apprentice | ||
|- | |- | ||
! Years Experience | ! Years Experience | ||
| | | 2 | ||
|- | |- | ||
! Primary Tools | ! Primary Tools | ||
| | | bash, ssh, mutt, ? | ||
|- | |- | ||
! Referrals | ! Referrals | ||
| | | ? | ||
|} | |} | ||
</div> | </div> | ||
=== Motivation === | ==== Motivation ==== | ||
* | * Avoiding screwups - I want to get noticed at my company and build a good reputation. | ||
* | * Learn and become a better sysadmin. | ||
=== Goals === | ==== Goals ==== | ||
* | * I manage the email infrastructure; my goal is 95% uptime this year. | ||
* | * Minimize unplanned outages. | ||
* | * <ugh what automation goals might he have with mail infra?> | ||
=== Frustrations === | ==== Frustrations ==== | ||
* | * Bureacracy - I work at a large company, and it's really hard to make change happen here. | ||
* | * Spending cycles porting code to an endless array of platforms – it’s time-consuming and uninteresting work | ||
* Spammers - gunking up the works. One of the things that sucks about working on mail infrastructure. | |||
* End-user interaction - it's hard to walk people through tasks on the phone, and we have a heterogeneous environment so I'm not always quite sure what mail client they are using. | |||
=== Work Description === | ==== Work Description ==== | ||
< description of a typical work day goes here. > | < description of a typical work day goes here. > | ||
= | <hr /> | ||
=== Persona #5: Decision-Maker === | |||
<div style="float: left;"> | |||
[[Image:serverwg-persona-decisionmaker.jpg]] | |||
</div> | |||
<span style="font-size: 22px; font-weight: bold;"> | |||
Priya Moore | |||
</span> | |||
<span style="font-size: 14px;"> | |||
CTO, Cloud Startup | |||
</span> | |||
<span style="font-size: 16px; font-style: italic;"> | |||
"In this competitive startup market, we need to be fast, efficient, and use technologies that attract developers to the company." | |||
</span> | |||
<br /> | |||
<div style="float: right; padding-left: 30px;"> | |||
{| | |||
! Profile | |||
| Decision-Maker | |||
|- | |||
! Age | |||
| 31 | |||
|- | |||
! Location | |||
| San Francisco, California | |||
|- | |||
! Technical Level | |||
| Advanced | |||
|- | |||
! Years Experience | |||
| 12 | |||
|- | |||
! Primary Tools | |||
| Uses a ThinkPad with Linux or MacBook Air, a tablet for meetings, and supports developers using their choice of hardware and OS | |||
|- | |||
! Referrals | |||
| TED, Twitter, Google+, Reddit, TechCrunch, GigaOm, Hacker News, Mailing Lists, Strata, Wired, Big Data newsletters, blogs (especially ones from Facebook, Twitter, and similar industry-leading engineering departments), other industry conferences | |||
|} | |||
</div> | |||
==== Motivation ==== | |||
* Building a great company around great technology | |||
==== Goals ==== | |||
* Communicate the organization's technology vision to the world | |||
* Interface with upstream projects to see where technology is headed and influence the direction | |||
* Establish good, key metrics to encourage work in the right direction | |||
==== Frustrations ==== | |||
* Needing to get a minimum viable product (MVP) shipping | |||
* Security models | |||
* Linking services together across machines | |||
* Playing office network admin in addition to CTO | |||
* Tension between choosing respected, traditional choices and things that will give the company an edge. | |||
* Integrating developer tools, QA needs, and production needs | |||
* Cloud versus bare-metal economics and overhead | |||
* Proprietary versus FOSS/in-house service options | |||
==== Work Description ==== | |||
* General executive meetings (short daily ones, longer weekly ones, and occasional retreats) | |||
* Coordinating with VP Engineering on weekly- to roadmap-level planning | |||
* Preparing internal communication materials for sales, marketing, support, and the general company presentations | |||
* Blogging, writing articles, and participating in online discussions | |||
* Coding and code reviews | |||
* Planning hackfests to improve FOSS projects, meet external developers for recruitment, and learn about projects | |||
* Attending community meetups | |||
* Vetting candidates and participating in interviewing | |||
* Preparing responses to security questionnaires from potential clients | |||
== Secondary Personas == | |||
=== Persona #6: Server Role Creator === | |||
<div style="float: left;"> | |||
[[Image:serverwg-persona-fedorameta.jpg]] | |||
</div> | |||
<span style="font-size: 22px; font-weight: bold;"> | |||
Edward Bryant | |||
</span> | |||
<span style="font-size: 14px;"> | |||
System Administrator | |||
</span> | |||
<span style="font-size: 16px; font-style: italic;"> | |||
"The work I do would be helpful to others, so I want to share it." | |||
</span> | |||
<br /> | |||
<div style="float: right; padding-left: 30px;"> | |||
{| | |||
! Profile | |||
| Fedora Server Contributor | |||
|- | |||
! Age | |||
| Indeterminate | |||
|- | |||
! Location | |||
| Silicon Valley | |||
|- | |||
! Technical Level | |||
| Moderate to high | |||
|- | |||
! Years Experience | |||
| 5+ | |||
|- | |||
! Primary Tools | |||
| Shell scripts, source-control, IRC | |||
|- | |||
! Referrals | |||
| Flock, FUDCon, FOSDEM, LinuxCon, Fedora mailing lists and IRC | |||
|} | |||
</div> | |||
==== Motivation ==== | |||
* Enhance the State of the Art | |||
* Minimize effort for deployment | |||
==== Goals ==== | |||
* Create a new role for Fedora Server so that he can use Fedora Server for an application that doesn't currently have a role to support it. He would like this application to plug nicely into Fedora. | |||
==== Frustrations ==== | |||
* New to Fedora community; not sure how to get involved. | |||
* Documentation is often sparse, out of date or scattered between many sites. | |||
* Guidelines are built around packaging projects, not solutions. | |||
* Hates seeing people solving the same problem over and over. | |||
==== Work Description ==== | |||
* Coordination between multiple upstream projects | |||
* | ** Release schedules. | ||
** API stability promises. | |||
* Builds deployment scripts and setup tools. | |||
* Communicates with the Fedora Project and its Server SIG. | |||
* Acts as a liason with one or more companies with a goal to achieve. | |||
* Helps prioritize the high-value roles for construction and maintenance. | |||
* Attends conferences to evangelize and listen to pain points. |
Latest revision as of 16:09, 25 February 2014
Discussion
Why do we have personas for the server product? Read the personas FAQ.
- Discussion of Fedora Server use-cases mailing list thread
- November 19 2013 meeting
- December 10 2013 Meeting
- December 17 2013 Meeting
Personas
- ‘application developer’ could be one right? someone who wants to build server applications
- ‘home/small business’ where they are constrained to one server/limited resources?
- ‘enterprise datacenter’ where they want to roll out many server instances and automate.
- A mid-level Microsoft administrator who does not have time for a steep learning curve.
Primary Personas
Persona #1: SysAdmin MacGuyver
Sandra Summers
Senior System Administrator; New Amsterdam Historical Society
"We're a small organization and we have limited resources... we just can't order new hardware for every new service request we get."
Profile | SysAdmin MacGyver |
---|---|
Age | 36 |
Location | Brooklyn, New York, USA |
Technical Level | Advanced |
Years Experience | 15 |
Primary Tools | ? Not sure. Thinking about things like puppet, nagios, splunk, etc. |
Referrals | Learns about new tech from team members, USENIX mailing lists, blogs |
Motivation
- Keep IT team within budget.
- Minimize late-night phone calls.
Goals
- Clean, secure, and manageable deployment of multiple server applications to a single server.
- Unified management of server resources.
- Ability to understand resource usage across server inventory to identify underutilized resources.
- Ability to easily deploy apps to underutilized resources.
Frustrations
- Home-grown scripts for deploying apps that have been around forever that have mysterious voodoo power. Difficult to reproduce application deployments consistently.
- Proliferation of various management console interfaces to have to manage.
Work Description
< description of a typical work day goes here. >
Persona #2: DevOps
Joe Franklin
Ruby on Rails Freelancer; Joe, Inc.
"I want to build amazing, easy-to-deploy server applications for my clients."
Profile | DevOps |
---|---|
Age | 27 |
Location | San Francisco, California |
Technical Level | Journeyman |
Years Experience | 7 |
Primary Tools | Uses a MacBook Pro as his workstation. Uses Ruby on Rails and Github. |
Referrals | RubyWeekly, Ruby Insider, engadget, lifehacker, ... (?) |
Motivation
- Use the latest and best technology to solve interesting problems.
- Produce high-quality applications that excite my clients and build a great reputation for it.
- Grow my business and gain key clients.
Goals
- Agility
- Rapid recovery / rebuild of servers when they go down.
- Anticipating outages / becoming aware of outages before they happen or as soon as possible in order to mitigate them.
- Seamless migrations/upgrades of my applications.
- Deploy projects to PaaS, multiple cloud providers, and even bare-metal
(Perhaps not relevant to Server)
- Balance multiple ongoing development projects at the same time.
Frustrations
- Platform bugs that casue me to spend cycles porting my code forward. It's time-consuming and uninteresting work.
- Cloud providers that change their APIs in an incompatible way with little notice! Having to develop new connectors for production servers with only a few days' notice is not cool.
- Spending cycles packaging code up for an endless array of platforms - it's time-consuming and uninteresting work.
- Building software on a platform so old it doesn't have the python or ruby library I need and not being able to pull it in from out-of-stream.
- Being forced to build on top of or connect together poorly or undocumented platforms, and/or use weak platform APIs
- Frameworks configured by default to require a lot of customization. I want to start running right away instead of getting bogged down in that kind of detail.
Work Description
< description of a typical work day goes here. >
Persona #3: Traditional App Developer
George Simpson
Principal Application Developer, Defense Contractor
"Critical bugs could seriously injure real people, or worse. We have a strict regimen behind our development process to minimize risk."
Profile | Traditional Developer |
---|---|
Age | 43 |
Location | Washington, DC |
Technical Level | Master |
Years Experience | 22 |
Primary Tools | Uses a Thinkpad as his workstation, emacs, gcc and git.
Has a smartcard and various x509 certificates to access critical systems. |
Referrals | ACM? IEEE? USENIX? LISA? |
Motivation
- Keep the people interfacing with my software safe.
Goals
- Stability and predictability
- Minimize risk; vet every code change before it gets in and causes potential problems.
Frustrations
- Bureacracy - although I understand why it's in place, it takes the effort of moving a mountain to move a molehill in this codebase.
- Hardware vendors not supporting hardware for as long as we need to run it in the field.
- Testing matrix requires a lot of infrastructure to perform various tests in a reasonable time frame on as many configurations as possible.
Work Description
- Triage of bugs filed by support/users
- Short daily or weekley status meetings
- Prepares design documents for new futures or bug fixes
- One of the following:
- Writes code/bugfixes
- Writes unit tests
- Writes memos for doc writers or writes documentation directly
Persona #4: Junior Enterprise SysAdmin
Andy Grant
Junior System Administrator; MegaBank, Inc.
"Automation is critical to managing a rollout to a server environment this large."
Profile | Junior Enterprise SysAdmin |
---|---|
Age | 24 |
Location | Jersey City, NJ |
Technical Level | Apprentice |
Years Experience | 2 |
Primary Tools | bash, ssh, mutt, ? |
Referrals | ? |
Motivation
- Avoiding screwups - I want to get noticed at my company and build a good reputation.
- Learn and become a better sysadmin.
Goals
- I manage the email infrastructure; my goal is 95% uptime this year.
- Minimize unplanned outages.
- <ugh what automation goals might he have with mail infra?>
Frustrations
- Bureacracy - I work at a large company, and it's really hard to make change happen here.
- Spending cycles porting code to an endless array of platforms – it’s time-consuming and uninteresting work
- Spammers - gunking up the works. One of the things that sucks about working on mail infrastructure.
- End-user interaction - it's hard to walk people through tasks on the phone, and we have a heterogeneous environment so I'm not always quite sure what mail client they are using.
Work Description
< description of a typical work day goes here. >
Persona #5: Decision-Maker
Priya Moore
CTO, Cloud Startup
"In this competitive startup market, we need to be fast, efficient, and use technologies that attract developers to the company."
Profile | Decision-Maker |
---|---|
Age | 31 |
Location | San Francisco, California |
Technical Level | Advanced |
Years Experience | 12 |
Primary Tools | Uses a ThinkPad with Linux or MacBook Air, a tablet for meetings, and supports developers using their choice of hardware and OS |
Referrals | TED, Twitter, Google+, Reddit, TechCrunch, GigaOm, Hacker News, Mailing Lists, Strata, Wired, Big Data newsletters, blogs (especially ones from Facebook, Twitter, and similar industry-leading engineering departments), other industry conferences |
Motivation
- Building a great company around great technology
Goals
- Communicate the organization's technology vision to the world
- Interface with upstream projects to see where technology is headed and influence the direction
- Establish good, key metrics to encourage work in the right direction
Frustrations
- Needing to get a minimum viable product (MVP) shipping
- Security models
- Linking services together across machines
- Playing office network admin in addition to CTO
- Tension between choosing respected, traditional choices and things that will give the company an edge.
- Integrating developer tools, QA needs, and production needs
- Cloud versus bare-metal economics and overhead
- Proprietary versus FOSS/in-house service options
Work Description
- General executive meetings (short daily ones, longer weekly ones, and occasional retreats)
- Coordinating with VP Engineering on weekly- to roadmap-level planning
- Preparing internal communication materials for sales, marketing, support, and the general company presentations
- Blogging, writing articles, and participating in online discussions
- Coding and code reviews
- Planning hackfests to improve FOSS projects, meet external developers for recruitment, and learn about projects
- Attending community meetups
- Vetting candidates and participating in interviewing
- Preparing responses to security questionnaires from potential clients
Secondary Personas
Persona #6: Server Role Creator
Edward Bryant
System Administrator
"The work I do would be helpful to others, so I want to share it."
Profile | Fedora Server Contributor |
---|---|
Age | Indeterminate |
Location | Silicon Valley |
Technical Level | Moderate to high |
Years Experience | 5+ |
Primary Tools | Shell scripts, source-control, IRC |
Referrals | Flock, FUDCon, FOSDEM, LinuxCon, Fedora mailing lists and IRC |
Motivation
- Enhance the State of the Art
- Minimize effort for deployment
Goals
- Create a new role for Fedora Server so that he can use Fedora Server for an application that doesn't currently have a role to support it. He would like this application to plug nicely into Fedora.
Frustrations
- New to Fedora community; not sure how to get involved.
- Documentation is often sparse, out of date or scattered between many sites.
- Guidelines are built around packaging projects, not solutions.
- Hates seeing people solving the same problem over and over.
Work Description
- Coordination between multiple upstream projects
- Release schedules.
- API stability promises.
- Builds deployment scripts and setup tools.
- Communicates with the Fedora Project and its Server SIG.
- Acts as a liason with one or more companies with a goal to achieve.
- Helps prioritize the high-value roles for construction and maintenance.
- Attends conferences to evangelize and listen to pain points.