Setting up a gitlab instance for the social dot coop

If you're willing to maintain this going forward (for now), and train some of us up on any of its essential weirdnesses, so we can help, and ensure succession when you want to step down as maintainer, I'm all in favour of making this an official social.coop thing.

On the process question, I suggest that we treat decisions made here as indications of rough consensus. Any decisions is always open to being reconsidered, to see if a new consensus emerge, especially when a new idea or fact comes up that wasn't considered when the original decision was made.
EDIT: fixed typos

Further to this, in response to a question someone asked in the 'buy a share' discussion (@wulee ?), I think it's always best to start with a proposal in this subgroup, and then if it receives strong support, escalate it to other subgroups (eg finance) as required. That way, we can second-guess ourselves like this, or by new suggestions or major amendments emerging as part of the first proposal process, without messing the wider group around ;)

Congrats on going ahead and experimenting!
I've copied our github repos to https://git.socialcoop.frenchha.us/socialcoop

Sorry that your vote wasn't heard, @gregcerna. So I thought it was you I saw you talking about this on Mastodon and I attempted to invite you in to the vote (so many Gregs!), perhaps I didn't do it in time.

(Will say more when I get another moment)

Why no alternatives?

It seemed reasonable to take the only proposal tabled at the time and try and get consent to go with it. I think there's some urgency to sort something out, and git.coop ticked a lot of boxes.

Decision period

I was unsure how long to set the decision period and left it at the default 3 days. In retrospect maybe it was too short. I set the the main group decision is longer at 4, and I think I'll extend it to 6 as per the social.coop bylaws which state this as the default; alternatively I could label it "URGENT" but there may be some discussion to be had and I'd rather not be seen as jumping the gun.

git.socialcoop.frenchha.us

Thanks for setting this up and generously offering to let us use it. I may try it in the interim as you propose, to start filing issues.

A couple of questions:
- I gather migrating GitLab only works (easily) between instances of the same version. Is yours the same version as https://git.coop?
(I gather GitLab is meant to state its version in the help page, but https://git.coop/help does not seem to. You may want to check with Web Architects and/or @chriscroome)
- I don't think you say what it's hosted on (from the POV of resilience, security etc), nor what features you've deployed. Can you write something which compares and contrasts your deployment with http://git.coop?
e.g. Does it allow CI with Docker, etc.? (Ditto)

Reservations

There are some plusses to deploy-it-yourself, but just to be on the level, here are some reservations I have about using your deployment for more than just a stop-gap:
- Are you offering to host this?
- If so, doesn't that mean this isn't social.coop infrastructure, it's yours?
- Are you the only admin?
- If you get hit by a metaphorical falling piano will we be able to recover this infrastructure?
- Or if social.coop will own and run the host collectively, does this mean a subscription to authorise?
- What tasks would we need to add to our admin rota? (Backups, updates, troubleshooting, etc.)
(i.e. We're short of admin power right now, and not especially flush with money.)

The benefit of using git.coop

We're in a situation with just two admins who have day jobs and want to hand over ASAP. I endorse "owning and controlling our own technical infrastructure" however under these circumstances we probably want to keep it as simple as possible. 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.

I would add that we need to solidify our own status as a cooperative before hosting (reservations raised by Nick are related) and there is a benefit from establishing a connection with another platform cooperative.

I think our priorities are: secure, stable, reliable hosting; democratic ownership, governance and admin; education and sharing of skills; and building the co-op ecosystem. So we should either own and control the hosting ourselves -- which means owning it as a coop -- or we should collaborate with a co-op hosting service.