repository
3 Dec 2022
would-be usefulness of somewhere to plonk evolving stuff and keep track of it and (selectively) share it is already evident, such as with:
- block lists. for keeping these up to date across multiple platforms, as in keeping both microblog and bookclub using the same set of suspensions. for enabling any of us to apply what we've cultivated to communities we are part of elsewhere. for sharing with others we trust who need help preempting threats. and among ourselves for figuring out, together, what to do, and showing what decisions have already been made, how, by whom…
- documents. such as project homepage(s), rules/codes of conduct/etc, helpful reference materials.
- sets of files for new shell users. it's called a skeleton, or something like that? and means that when you first log in, your home directory is already be furnished with, for example, a folder for your website to go in with some templates and a getting started guide. keeping a copy of the skelo in a repo would be good for adjusting what the welcome kit contains in response to feedback, and could help if you accidentally deleted some of your own first furnishings or wanted to download improved versions that only came about after you joined? we could do all that without a repository, but it's also nice to have another form of backup and could be good practice for learning how to use that repository. and again, as with all of these points, would make it easier to pass resources on for other projects.
- modifying platforms to suit the community. to help keep our tweaks consistent as the underlying software changes, and so it's all available to all of us, not just the system admins.
version control systems
there's a moment in the wrapup epistolary from Avantwhatever's first residency period ("Mateus Domingos & Rory Green in conversation")… the participants are holding a discussion in a shared text file, when the host Bec chimes in. there's a tense passage where they realise that they might be trying to edit the file at the same time as one or both of the residents. apparently no problems occur, though there's a nearish miss. for anything serious, busy, or more complicated, i would suggest we not chance glitches of overlap!
there are various options: fossil, darcs, mercurial, and loads of others. some are particularly suited to particular types of work. we can adopt what's appropriate as we go?
bookwyrm, hometwon and gotosocial all use git (despite git being a bit of a mess), so i'll aim for that at first?
projects system
although not strictly necessary, it would probably be an enormous help if we had something to actually hold communal works-in-progress, from which we could share parts publicly or among a group, without each contributor sending always to each person individually.
for now i'll be outsourcing to sr.ht, the paid hosting provided by the maintainer(s?) of sourcehut, which is a zippy and uncluttered system that doesn't seem to pry. we could host a sourcehut ourselves, if we wanted to, in future. we could ditch it altogether.
sourcehut supports git and mercurial, and offers wikis and mailing lists and all sorts.
i'm mucking around getting a feel for things from a personal account. i also snaffled ~snails, to give us the option of a communal account? /some/account has to stand in as The maintainer for any given work. maintainer accounts pay a monthly or annual, slidescalesy fee (but NOTAFLOwhatever it is). contributor accounts are free. accounts are not technically necessary to contribute.
in inconclusion: ?
working title snailspace
we do not have to be snails it is true
your responses
reply by email, granting permission for me to quote you or reply by email and don’t let me quote you