I think I’m with @benhylau here - though I admit that I now have become unclear on what level of management is conducted in a Greenlight container - does it give container admins rights to create room admins, or is it a lower level, where specific rooms can be created, with specific resident hosts? I can no longer remember what kind of rights we conference organisers were given for Open2020, and never was aware at that time how that ‘admin space’ was related to Greenlight ‘container space’. Some kind of Venn diagram of the admin privileges hierarchy would really help, mapped into Greenlight/BBB system architecture, so that we all can see what kinds of constraint there are on how accounts can be administered (as distinct from server/software admin). @osb d’you get this? The ad-hoc administration of user-organisations’ room bundles, by them, is where things should all be focused? Server admin issues should be well in the background, as regards account administration.
Right now, alpha phase, we’re much constrained by what Greenlight capability (and sysadmin familiarity) allows us to administer at the sysadmin level. But the aim should be to move as quickly as is realistic to a use-case based offering of fair-use service bundles (accounts) in the beta phase of meet.coop. And to promise early adopters that this is what we mean to do, in consulation and co-design with them (in collaborative ‘circles’) about room use-cases and organisations’ room-bundle needs, so they stay with us through the painful journey.
I see use cases thus
individual person’s ad hoc meeting room - up to seven ppl cameras on for 2 hours - but typically two ppl cameras on for 1 hour, twice a day
’atelier’ workroom for a circle - seven participants coming and going in varying combinations all day - average four ppl cameras on for five hours
- conference/confluence - 50 participants 6 cameras on over two days plus eight breakouts 50 cameras on total 6 hours
town square - 100 ppl coming and going continually every day cameras on average 5ppl staying 20min
custom - to be individually negotiated
The nature of this use case typology differs from ben’s, I think. Maybe Ben is seeing owner-entrepreneur/freelance/gig-economy small businesses. I certainly am seeing commons-economy/solidarity-economy/civil-society movement organisations and coops trading under coop principles. No individual or free accounts (maybe when we have a large and reliable surplus!). @wouter what would your use-cases look like?
Account offerings is another matter. I see accounts as offering bundles of these room types in maybe three tiers, under fair-use expectations policed as firmly as is possible, priced accordingly, selling only to organisations:
- single-circle organisation = ‘simple organisation’ rate - single-person accounts/rates not to be offered. Free accounts not to be routinely offered (but cases of hardship considered)
- multi-circle organisation = “complex organisation” rate
- federated network (eg a Hispanic or Japanese language-based network, a bioregional trade and civil society network, a university - an example might be Coop University in the UK) dedicated service rate . ‘Own-server’ badged reselling of bandwidth (as in Collocall?) is not a service to be offered. Only networks under meet.coop governance to be eligible for accounts