Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| platform_vision_guide [2025/09/21 18:15] – created sarah | platform_vision_guide [2025/10/26 18:02] (current) – [Example user stories] sarah | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Vision ===== | ===== Vision ===== | ||
| - | An alternative to Facebook Groups that can be used by specific local organisations and collectives, | + | An alternative to Facebook Groups that can be used by specific local organisations and collectives, |
| - | ===== Target users use cases & personas: examples | + | ===== Example user personas ===== |
| - | Example | + | These groups |
| - | - Brunswick Tool Library | + | |
| - | - Good Karma Network | + | * Brunswick Tool Library |
| - | - Gig Guide | + | |
| - | - Radical Socialist Base | + | |
| - | - Muslim Women’s association | + | |
| - | - Radicle Roots | + | |
| - | - Balam Balam | + | |
| - | - Library services | + | |
| - | Additional critical uses: Community emergency announcements | + | |
| - | 2 What we need from the system | + | |
| - | - Discoverability: | + | ===== Example user stories ===== |
| - | o Ability to manage multiple overlapping circles of community, e.g. micro-locality, | + | We can prioritise these to identify core functionality and non-essential functionality (e.g. MoSCoW prioritisation) |
| - | - Onboarding plan and functionality | + | |
| - | - Options for verification | + | For more detail, see [[Use cases for digital town squares]] |
| - | o Systems people know (email, mobile) | + | |
| - | o And ability to provision accounts, reset accounts without these | + | **In an emergency** |
| - | o | + | * Community emergency announcements |
| - | - Initial user experience and visual appearance: | + | * Organising / coordinating volunteers (e.g. community gardening, food parcel delivery) |
| - | - Target | + | * Alerting neighbours and groups to people in need of assistance |
| - | - Needs to be FOSS/ Standards based / interoperable, | + | * Coordinating community response to requests for assistance |
| - | - Robust | + | |
| + | **Business as usual** | ||
| + | |||
| + | Being used regularly as part of everyday community activities will mean that the platform is familiar and useful to many in an emergency / blackout scenario. | ||
| + | * Advertising events, workshops and groups' | ||
| + | * Offering and requesting items, services and assistance (per e.g. Freecycle / Good Karma) | ||
| + | * Requesting advice and recommendations regarding local businesses and services | ||
| + | * Seeking social connections with neighbours | ||
| + | * Community organising: including formal groups and adhoc groups e.g. neighbourhood activities | ||
| + | * Discussion of local politics and current affairs ? | ||
| + | |||
| + | ===== Essentials | ||
| + | These could be provided by the platform itself or by supporting services and capabilities | ||
| + | * Onboarding plan and functionality | ||
| + | * Discoverability: | ||
| + | | ||
| + | | ||
| + | * | ||
| + | | ||
| + | | ||
| + | * Needs to be FOSS, standards based, interoperable, | ||
| + | |||
| + | Beyond these, here are several big categories of issues that need to be addressed for successful community-run digital spaces, including: | ||
| + | |||
| + | * Online vs real-world identities: policies and enforcement | ||
| + | * mitigating bots, bad actors | ||
| + | * removing and banning | ||
| + | * allowing anonymity for stigmatised | ||
| + | * allowing anonymity for illegal topics, people who would want to hide identity from police, whistleblowing? | ||
| + | * meeting U16 social media requirements (legislation and duty of care) | ||
| + | * Ease of signup and sign-on vs security | ||
| + | * reduce usability barriers for platform signup and sign-on | ||
| + | * balance with security: password strength, 2FA, password resets | ||
| + | * requirement | ||
| + | * ability to change email? | ||
| + | * Moderating online discussion | ||
| + | * establishing enforceable rules that balance community expectations | ||
| + | * addressing disinformation | ||
| + | * encouraging decent behaviour | ||
| + | * recruiting, training, retaining volunteer moderators | ||
| + | * compensating toxicity vs decent behaviour | ||
| + | * Tech skills and capabilities | ||
| + | * What skills and capabilities are needed of our tech ops teams? admins? community moderators? | ||
| + | * minimum viable workforce to run things? (assume e.g. | ||
| + | * Ongoing viability and financial considerations | ||
| + | * potential uptake for Merri-bek residents: ~20% of 180,000 = 36,000 users. | ||
| + | * Ongoing hosting | ||
| + | * recruiting, training, retaining volunteer mods, admins and tech support ongoing | ||
| + | * compensation for workers? | ||
| + | * how many mods / admins needed per 1000 users? | ||
| + | * Long-term user engagement and utility | ||
| + | * main factors that would drive uptake (signup?) | ||
| + | * main factors that would drive ongoing use? | ||
| + | * success factors e.g. | ||
| + | * Info & comms platform of choice for Merri-bek non-profit groups; | ||
| + | * Merri-bek residents use as platform of choice for connecting with neighbours (e.g. freecycle / good karma group equivalent; asking for local info or recommendations) | ||
| + | * platform of choice for Merri-bek Council to inform & engage with community | ||
| + | * new Merri-bek arrivals sign up as a way to access community info; | ||