Friendly naming for our concepts #17
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#17
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently:
wordpress
ornextcloud
, which is made up of multiple services..Prior art (using above naming):
Maybe there's a balance to be struck between metaphors people will already be familiar with (hello "app") and helping people learn the esoteric Docker CLI API ("stack").
Yes, excellent. Good to think about this. Here is a brain dump...
I think it is very important to keep in mind who is the public of this project. We seem to be fuzzily settled on "other people who do hosting" but then in some of our conversations we want Autonomic to be doing the hosting and then say, some CoTech member to be receiving services - therefore, they would be reading the documentation not as "a person who does hosting". We can orientate towards mulitple publics though, like YunoHost does in https://yunohost.org/#/docs "admin guide", "contributor guide". Maybe we want both?
I do very much like this overall breakdown. This would be the "forest" view, I guess. Something like this in the eventually published documentation would be super useful IMHO.
It's kinda like a social infrastructure or? We have some aspirations to have some governance, Autonomic provides some infrastructure to get the ball rolling, we have some design vision for the the thing. There isn't like, a central place to log in or anything.
"Platform" is such a muddled term at this point and can easily be mistaken for some sort of neo-feudal SaaS monopoloy driven social relation that I would be up for trying to dig into some new terms. Things like "Cypherspace" and "Sunrise Choir" (coming out of scuttleverse) are inspiring in this regard - trying to put some terms on this thing that is actually quite new!
Lol indeed, I am wide open to replacement names for any of this ("platform" is my least favourite of the current lingo, "stack" a close second).
Definitely! I think in my mind our first target people are user-collaborators, i.e. other outfits roughly our size who would like to use CoöpCloud themselves to host, and might help us with app packaging or maintenance.
I think "not persons who do hosting" are going to be much easier to reach if and when we have some kind of UI for app management, and in the mean-time we can maybe direct them to autonomic.zone and expand the list of "cloud" services we offer there? Anyway also open to a separate ticket or pad for the "target audience" question, it's a good'un.
Thinking about this again...
I'd like to suggest that we merge the idea of the "host" and the "context" together. I think reducing the number of high-level concepts is a good thing for the first take on understanding what this is. Later, you get the difference. So, I would propose then that we use "server"? I think nearly most people would recognise that for what it means. Sooo, the CLI thing would be
abra server ls
abra server use
abra server add
etc. instead ofabra context
. Whatcha think?Then I think stack should just become app. Everyone gets that one too.
Then we'd just have to deal with 2 things: "servers" and "apps". This would even the playing field in terms of language for technical and non-technical people. "How it works" is then a question of knowing about Docker contexts, swarm, stacks and the rest.
I am bringing this up because I somehow feel like naming is important and I shouldn't follow my own advice to avoid it :)
Yep seems ideal 👍 👍 👍
I like this too.
My heart still longs for some way of separating "app definition" from "app instance" but overloading "app" for both doesn't seem like a bad compromise for the moment.
Ok, nice! I will leave this open so that I document this on the new docs.