Should we buy a share in the Web Architects co-op to get access to git.coop?
Nick S PublicSeen by 61A proposal to this effect on the Tech Working Group closed yesterday (link here), and nominally passed (at least amongst those who responded):
- 9 Agree
- 4 Abstain
- 1 Disagree
- 35 undecided
In brief: the motivation is to get access to a GitLab instance with issue trackers, documentation tools etc., to coordinate setting up the various Ops Teams discussed in the main group here, here, here and here.
I think the process now is to move the proposal here for wider participation. I plan to do this shortly when I've redrafted it to summarise the outcome.
In the mean time, this is a thread to discuss the proposal, since voter comments in the proposal are limited in size. And if you saw the proposal and want to comment before I post it again, this is the place. :)
I definitely like the idea of social.coop using a free code platform (not GH) for code management and documentation, and I like GL. There are arguments for hosting an instance on the same hosting as the Mastodon instance. But since there is already an instance run by a coop (and while the social.coop ops time are getting organised), using git.coop seems like a sensible solution, at least for now.
As mentioned here, which seemed an appropriate place to ask, I believe the finance working group also needs to be involved in this decision (because funds), and I'm wondering if I should put the proposal there, or here, or both...
My current inclination is to put it here and link to it in a parallel decision in the FWG, as I think we need the resource fairly urgently, to help to accomodate @victormatekole and @mayel's wish to hand over. Also, if I put it here, everyone in the FWG can see also it - otherwise just the FWG can see it.
Please comment if anyone thinks this is the wrong thing to do.
Social.coop should join the Web Architects Co-op, in order to get access to the git.coop service
proposal by Nick S Closed Sat 16 Jun 2018 6:02PM
Seems to have passed.
Some abstainers asked questions - I hope these are dealt with in the comments? If not please remind me which points I missed.
@greg disagreed, I don't know if you might want to say more based on my answers to your questions (which came after your vote I believe)? @strypey suggested we should discuss your proposal.
@victormatekole didn't cast a vote this time, and @mayel abstained, both for unstated reasons. As key stakeholders in the matter, I invite you guys to clarify why you chose these options, since you need to be happy about this.
There's a parallel proposal in the finance group concerning how much to pay for a share in Web Architects, which currently split between the suggested £100, and £50 now then £50 later. I think I shall reopen that so that some more people can't contribute and push it one way or another.
Social.coop should join the Web Architects Co-op, in order to get access to the git.coop service
The use of Web Architects' service https://git.coop was originally proposed by @chriscroome, who is a member of social.coop and WebArchitects. WebArchitects is UK-based multistakeholder Co-op that provides this service to all members, for a minimum one-off stake of GBP £1, but a suggested stake of £100 for groups and £10 for individuals.
This proposal adapted from this proposal and this post.
The task organisation idea in 'Steps' is summarised from my suggestion in this thread here
There is a parallel decision asking for approval of the funds in the finance working group here
What is GitLab?
GitLab is a web-based project management tool, reviewed here, which Web Architects offer as a service to their members. GitLab (the software and the company) provides facilities similar to services provided by GitHub, but GitHub is a closed-source proprietary service (recently acquired by Microsoft) whereas the community-edition GitLab software we would be using is open-source.
Motivation
The motivation for this proposal is to facilitate organising social.coop's technical working group's activities (and potentially the other WGs'), from social.coop's main servers. We would use it for our up-front planning and documentation now, and later also for coordination.
As such I believe we don't want or need to defer this decision until after recruiting the ops team. I argue it makes sense to have such a tool because helps people to self-organise, and the work to branch out in parallel, rather than be constrained to linear steps.
Steps:
- If we get this tool, it facilitates us (specifically myself with help from @victormatekole @mayel and hopefully others) to:
- Begin compiling one-off tasks in its issue tracker.
- Begin compiling recurring tasks in its wiki.
- Add outline/time/skill assessments. - Move our public GitHub social-cooperative account to private repositories in GitLab.
- We can then recruit people (voluntary or otherwise) with a clear remit based on skill/time matches to the above. They then:
- Flesh out docs in the wiki, on the job.
- Coordinate/prioritise work using the issue tracker.
Costs/Benefits
Cost/Cons:
- A suggested UKP £100+ one-off membership share, exact amount to be agreed by the finance working group.
- I'm told the CI facility at git.coop uses Debian Stretch as the base OS, so to use it our deployment images would need to be ported from Alpine Linux.
- Various arguments about GitLab vs alternatives.
Benefts:
- Git hosting (to store and track documents/code/configuration/text in an auditable and collaborative way).
- Wikis/web pages (providing a user-friendly web interface for documentation stored as Markdown files in these Git repositories).
- Issue tracking (for prioritising/allocating/discussing work).
- Continuous Integration (for testing deployment/maintenance procedures without the risk of breaking the live services we provide).
- Hosted independently of social.coop's live servers, and so a) not adding an additional admin burden, and b) still available when live servers are not.
- Using open source software.
- Executing co-operative principle 6 (collaboration between co-ops).
Outcome of the Tech WG proposal
The consensus amongst those who responded was broadly in favour, but with one notable exception: @victormatekole. However, he made this caveat:
> If making this subscription (Web Architects) and getting Gitlab
> going doesn't add extensive time to getting the team operational
> then by all means let's do it. At the same time I think those who
> are up for it should get involved, by doing.
So I hope we can simultaneously try and address @victormatekole's concerns by working on the schedule/to-do list as best we can.
An outstanding question about legal ownership of the share is discussed here and here, which seems to conclude it should be workable if joining the Institute of Organisations was.
Results
| Results | Option | Votes | % of votes cast | % of eligible voters | |
|---|---|---|---|---|---|
| Agree | 18 | 72 | 18 |              | |
| Abstain | 7 | 28 | 7 |     | |
| Disagree | 0 | 0 | 0 | ||
| Block | 0 | 0 | 0 | ||
| Not voted | 75 | 75 |                |
Sounds OK to me - but too tech for me to be sure, or to contribute to making it work.
Support the proposal in principle - but can speak to the operational benefits of this.
Makes sense to me tools etc. to be driven by the people who are going to be doing/co-ordinating the work.
Someone has opened a discussio on their offer to host a social.coop instance of GitLab, which would avoid the need for image porting etc. I think it best to defer this decision pending the result of that discussion.
Support the proposal in principle - but can't speak to the operational benefits of this.
Makes sense to me that tools etc. be driven by the people who are going to be doing/co-ordinating the work.
UKP100 seems like a reasonable price to pay to a friendly co-op for the service
I don't have the knowledge to understand all the implications of this.
I think this idea is on the right side of the cost/benefit line, and I'd like to point out that having to port deployment images to a solid and well-respected distro which many more people are familiar with may be a blessing in disguise.
Makes sense to me
Someone has opened a discussion on their offer to host a social.coop instance of GitLab. I think it best to defer this decision pending the result of that discussion. But I'm liking the arguments for keeping sysadmin tools separate from production.
As I'm also from the UK I've been aware of Web Architects and their work for some time. I think it'd be nice for us to join WA.
Although my git skills are limited, I interact / use services from a few groups and orgs using gitlab to organise
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?
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?
Yes we can add accounts for arbitrary email addresses but we would rather not do this as it would add an additional administrative burden for us.
@mayel manages DNS, I do not have access.... I am not aware of any email services hosted or self-hosted that social.coop uses, in order to enable the use of aliases...
If I were you I'd choose a sub-domain for developer email addresses
(since you already have mx records for social.coop), for example
developer.social.coop and then ask us to whitelist this sub-domain at
git.coop and then point the MX records for this to our Mailcow server
at webarch.email and we could then provide you with a admin account
that you could use to add unlimited email aliases for people who need
access to git.coop, hosting a domain on our Mailcow server is
something we charge £15 a year
for, you might be able to find somewhere else that is cheaper or free.
The advantage of an arrangement like this is that you
would be in control of who has a @developer.social.coop alias and
could add new ones when you wish without having to contact Webarchitects
for help.
Would a simple /etc/aliases style alias do for this purpose? In which case it could be free and simple to set up aliases for the mail administrator, so long as developer.social.coop could be pointed at an MX server we manage.
However, I see the social.coop MX record points to zoho.eu; I don't know what we have on the other end, @mayel's document doesn't mention this.
@chriscroome, how does the whitelisting work, and is it a full GitLab instance we get or merely accounts on a shared instance? For instance, it sounds like we don't have the ability to manage our own GitLab accounts.
You would have the ability to manage who has aliases and therefore
accounts, plus you can set up groups and control the access to those,
yes it is a shared server at git.coop.
Would a simple
/etc/aliasesstyle alias do for this purpose?
Yes that would be perfect, I only suggested using our Mailcow server since this gives you a web based interface for managing aliases (which would allow people who are not happy ssh'ing into a server, sudo'ing to root, editing /etc/aliases and running newaliases to manage the aliases).
I full agree, I'm ready to start moving over docs to their wiki (gitlab has like a sub-repo for wikis) and i can set up the gitlab bot in the matrix room