Should we buy a share in the Web Architects co-op to get access to git.coop?

Before I vote on this proposal I have some questions:

• Where are social.coop's servers hosted?
• Since it's being emphasized, what benefit would there be to using git.coop versus spinning up our own Git repository?
• What would be involved in the move from Alpine Linux to Debian?
• What advantage would there be to using Git's wiki for this work instead of the wiki we already have?

A quick reply before bed. I think mostly these have been tackled in the Tech WG thread and here as well as the proposal itself.

Where are social.coop's servers hosted?

The two main servers are somewhere on @mayel's https://cloudvault.me service. I don't know the details, except what he wrote a short outline document on the topic linked from here, that I hope will get expanded as one consequence of this proposal.

Since it's being emphasized, what benefit would there be to using git.coop versus spinning up our own Git repository?

GitLab is a web-based project management tool, so much more than just a Git repository.

As for why 3rd party rather than self-host: there are some points tackling this in the proposal. To put it another way, borrowing from this... with git.coop:
- We're not hosting it (no recurring fees)
- We're not maintaining it (doesn't add to our workload)
- It's not on our production servers (stays up if they go down)
- It's super value for money (the one-off share purchase is small)
- It's a share not a fee.

What would be involved in the move from Alpine Linux to Debian?

That isn't clear to me either. Possibly trivial, possibly not, I'd hoped @mayel or @victormatekole would be able to comment.

Saying that, the main point of using git.coop is not the continuous integration tools (which this relates to) - these are just a nice addition which integrates with the rest of GitLab. If it turns out not to be trivial, I believe @mayel (correct me if wrong) already has some CI tools he uses elsewhere.

What advantage would there be to using Git's wiki for this work instead of the wiki we already have?

@mayel says in his document: "[the wiki] was initially set up as an experiment and should now be migrated to social.coop's servers." I'd propose the "stays up if they go down" principle applies to any wiki describing our servers and their admin tools. git.coop's GitLab wikis would tick both boxes, be easily replicated (because they're backed by git repos), and still allow people to edit them online without using git directly.

Hope this clarifies... :)

I'd propose the "stays up if they go down" principle applies to any wiki describing our servers and their admin tools.

Just as it applies to the Loomio group. I'd like to see social.coop sever all (direct) dependencies on corporate servers, but that doesn't mean we have to host everything ourselves. Using services run by coops, not-for-profits, and social enterprises, are also legitimate options, especially for the collaboration and documentation tools we would need to fix our servers if they went down.

As a general observations, the phrase "self-hosted" is sometimes taken far too literally. Unless "self-hosted" is literally what I mean, I've started to use the phrase "community-hosted". This communicates that it's about trust and cooperation, more than decentralization and DIY. Although the latter are bonus features that tend to come with community-hosting, having every netizen admin their own instance of everything they use, paying a "cloud" hosting service run by the same corporations that currently do the admin for us and give us hosting gratis, is as much a step to the right as it is a step to the left #TimeWarp

I just realised one thing that isn't clear from looking at their website, will WA provide us with just one user account to use, or will any member who wishes be able to easily sign up to contribute on Gitlab (for eg. to edit the wiki)? cc @chriscroome

It says on https://www.webarchitects.co.uk/git: "If you join as an organisation we will whitelist your domain so all your members can register accounts." Sounds like this would rely on us having a social.coop email address?

@chriscroome said that if social.coop used git.coop "you could have unlimited @social.coop accounts and repos, private if needs be"

I'm not entirely sure what "whitelist your domain" means in this context, but I don't think it is necessary for domains to be whitelisted in order to use GitLab, just a convenience.

We generally whitelist domains, would it be possible for everybody who would like a git.coop account to have a @social.coop email alias?

The GitLab instance at git.coop doesn't allow anyone to create accounts, only people with email addresses for whitelisted domains can create accounts, would it be possible to create @social.coop email aliases for people?

Thanks for answering this. I don't know - I'm sure it's possible, but @mayel or @victormatekole will know what we can do easily.

GitLab usually works by getting users to register. But is it possible to create accounts administratively for arbitrary email addresses in GitLab?