ServPulse/User stories: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
== Persona == | == Persona == | ||
Created during 2023-06-02 meeting with | Created during 2023-06-02 meeting with Eli, DorianWinty, Dereckson and Fauve. | ||
<gallery> | <gallery> | ||
| Line 10: | Line 10: | ||
File:ServPulse user stories - Persona - Visitor.png|Persona 3 - Visitor | File:ServPulse user stories - Persona - Visitor.png|Persona 3 - Visitor | ||
</gallery> | </gallery> | ||
== User stories == | |||
=== Katherina, the student (Nasqueron member) === | |||
Katherina is interested in open source and free culture. She has a background in computing but is more into development than operations. She uses Ubuntu but isn't comfortable with the terminal. She wants to use Nasqueron services without worrying about infrastructure. | |||
''Pain points: "Why DevCentral doesn't answer?", "I'd like to connect to IRC but Eglide doesn't ping", "Sometimes it's complicated to know what services we have or on what servers."'' | |||
* As a member, I want to see at a glance if all services are fine or if something is broken, so I don't have to guess why a service isn't responding. | |||
* As a member, I want to see which specific service is affected and what its current status is, so I know whether the problem is with DevCentral, IRC, or something else. | |||
* As a member, I want to see what is being done about an ongoing incident, so I know the team is aware and working on it. | |||
* As a member, I want to subscribe to email notifications, so I'm informed of incidents without having to check the page. | |||
* As a member, I want to see services organized by group, so I can find the service I care about without knowing the infrastructure details. | |||
* As a member, I want to see past incidents and how they were resolved, so I can understand what happened while I was away. | |||
* As a member, I want the page to update automatically, so I don't have to keep refreshing during an incident. | |||
=== Gourou, the tech-savvy (Nasqueron ops) === | |||
Gourou knows the Nasqueron infrastructure well. He prefers command-line tools and simple UIs over complex interfaces. He could use either a GUI or a TUI. He wants to manage services easily and detect intermittent downtime. | |||
''Pain points: "Does all my infrastructure is going well?", "Do we have some intermittent down time?", "Does it's easy to use?"'' | |||
* As an ops member, I want to manage services (create, edit, delete) from an admin dashboard, so I don't need direct database access. | |||
* As an ops member, I want to create incidents and update their status through a lifecycle (investigating → identified → monitoring → resolved), so I can communicate the resolution process. | |||
* As an ops member, I want to schedule maintenance windows, so visitors are informed in advance. | |||
* As an ops member, I want monitoring tools to automatically update service status via a webhook, so the page reflects reality without manual action. | |||
* As an ops member, I want to see historical uptime statistics per service, so I can detect intermittent downtime patterns. | |||
* As an ops member, I want health checks to run automatically against service URLs, so statuses stay current without manual updates. | |||
* As an ops member, I want health checks to distinguish between degraded performance and full outage, so the status page is more accurate. | |||
* As an ops member, I want to generate an admin token via CLI, so I can access the dashboard without a user/password system. | |||
* As an ops member, I want to link incidents and maintenance to affected services, so visitors see which services are impacted. | |||
* As an ops member, I want to customize the page title, navigation links, and footer, so the status page matches our branding. | |||
* As an ops member, I want to deploy the entire application with a single command, so setup is fast and repeatable. | |||
=== Mykel, the artist and writer (Visitor) === | |||
Mykel identifies as they, is in their 30s, and uses Nasqueron services casually — clicking links, reading wikis, browsing. They are UI-oriented and put off by complexity, too much text, or too much theory. They interact with Nasqueron services randomly and without commitment. | |||
''Pain points: "I've just clicked on a link, got an error who told me to check status", "Complexity?", "Too much text."'' | |||
* As a visitor, I want to see an overall status banner immediately, so I know in one second if systems are healthy or not. | |||
* As a visitor, I want the page to be simple and visual (not walls of text), so I can understand the situation at a glance. | |||
* As a visitor, I want to see which specific service is down, so I know if the one I care about is affected. | |||
* As a visitor, I want to subscribe to notifications, so I know when the service I use is back without checking repeatedly. | |||
* As a visitor, I want a clear page when I land on a broken link, so I'm not confused by a blank screen. | |||
* As a visitor, I want the page to work well on mobile, so I can check status from my phone. | |||
* As a visitor, I want dark mode support, so the page is comfortable to read at night. | |||
Latest revision as of 15:45, 17 February 2026
User stories allow us to define site features.
Persona
Created during 2023-06-02 meeting with Eli, DorianWinty, Dereckson and Fauve.
-
Persona 1 - Nasqueron member
-
Persona 2 - Nasqueron ops
-
Persona 3 - Visitor
User stories
Katherina, the student (Nasqueron member)
Katherina is interested in open source and free culture. She has a background in computing but is more into development than operations. She uses Ubuntu but isn't comfortable with the terminal. She wants to use Nasqueron services without worrying about infrastructure.
Pain points: "Why DevCentral doesn't answer?", "I'd like to connect to IRC but Eglide doesn't ping", "Sometimes it's complicated to know what services we have or on what servers."
- As a member, I want to see at a glance if all services are fine or if something is broken, so I don't have to guess why a service isn't responding.
- As a member, I want to see which specific service is affected and what its current status is, so I know whether the problem is with DevCentral, IRC, or something else.
- As a member, I want to see what is being done about an ongoing incident, so I know the team is aware and working on it.
- As a member, I want to subscribe to email notifications, so I'm informed of incidents without having to check the page.
- As a member, I want to see services organized by group, so I can find the service I care about without knowing the infrastructure details.
- As a member, I want to see past incidents and how they were resolved, so I can understand what happened while I was away.
- As a member, I want the page to update automatically, so I don't have to keep refreshing during an incident.
Gourou, the tech-savvy (Nasqueron ops)
Gourou knows the Nasqueron infrastructure well. He prefers command-line tools and simple UIs over complex interfaces. He could use either a GUI or a TUI. He wants to manage services easily and detect intermittent downtime.
Pain points: "Does all my infrastructure is going well?", "Do we have some intermittent down time?", "Does it's easy to use?"
- As an ops member, I want to manage services (create, edit, delete) from an admin dashboard, so I don't need direct database access.
- As an ops member, I want to create incidents and update their status through a lifecycle (investigating → identified → monitoring → resolved), so I can communicate the resolution process.
- As an ops member, I want to schedule maintenance windows, so visitors are informed in advance.
- As an ops member, I want monitoring tools to automatically update service status via a webhook, so the page reflects reality without manual action.
- As an ops member, I want to see historical uptime statistics per service, so I can detect intermittent downtime patterns.
- As an ops member, I want health checks to run automatically against service URLs, so statuses stay current without manual updates.
- As an ops member, I want health checks to distinguish between degraded performance and full outage, so the status page is more accurate.
- As an ops member, I want to generate an admin token via CLI, so I can access the dashboard without a user/password system.
- As an ops member, I want to link incidents and maintenance to affected services, so visitors see which services are impacted.
- As an ops member, I want to customize the page title, navigation links, and footer, so the status page matches our branding.
- As an ops member, I want to deploy the entire application with a single command, so setup is fast and repeatable.
Mykel, the artist and writer (Visitor)
Mykel identifies as they, is in their 30s, and uses Nasqueron services casually — clicking links, reading wikis, browsing. They are UI-oriented and put off by complexity, too much text, or too much theory. They interact with Nasqueron services randomly and without commitment.
Pain points: "I've just clicked on a link, got an error who told me to check status", "Complexity?", "Too much text."
- As a visitor, I want to see an overall status banner immediately, so I know in one second if systems are healthy or not.
- As a visitor, I want the page to be simple and visual (not walls of text), so I can understand the situation at a glance.
- As a visitor, I want to see which specific service is down, so I know if the one I care about is affected.
- As a visitor, I want to subscribe to notifications, so I know when the service I use is back without checking repeatedly.
- As a visitor, I want a clear page when I land on a broken link, so I'm not confused by a blank screen.
- As a visitor, I want the page to work well on mobile, so I can check status from my phone.
- As a visitor, I want dark mode support, so the page is comfortable to read at night.
