I agree with you here.

The current model is based on a GitLab "wiki," which means there is no branching, etc. Just updates.

I think this could work if we assume the wiki should only ever be edited by a subset of the community, eg. working group members.

If we don't want to operate on that assumption, we should move to something more accessible like DokuWiki.

Which brings us back to Christina's questions above, and specifically her points #1 and #4. :-)

Personally, I'm surprised there is even a question that ideally all social.coop members would co-maintain some kind of knowledge base. It seems to me pretty obvious that having things restricted to WG-only is a big reason we don't have up-to-date and clear information for members and, especially, newcomers. Can you explain why think that limiting editing to WGs is desirable?

Ana, I wonder if it's merely a lack of documentation and training videos, or, if there is software that helps automate the underling process (of markdown static websites)? This underlying workflow is robust, extensible, and auditable. As a side note, this process could use meta-data that tracks when content has been last reviewed for accuracy, to distinguish stale vs stable content. By contrast, most wiki oriented solutions lack these qualities, and the content ends up lacking review due to opaque storage layer. - Clark

In my experience, it is not a lack of documentation or training. Fundamentally, a git-based editing process tends to be overly complex and alienating to those who don't already use Git regularly and fluently. But I'm repeating myself.

@Clark C. Evans, I don't think docuwiki or wikiJS have opaque storage - i think they both support editing either from the wiki or via git? As I understand it the git storage makes version control clear, and the wiki editor makes the learning curve for contributing less steep.

DokuWiki has excellent version control, but not with Git.

I concur with @Ana Ulin. I am fairly technical, and I still find Git really hard to understand—unnecessarily complex for a wiki. I just actually built a GitLab-based wiki and found that my students had a really hard time using it. So I would lean away from an approach that requires use of a Git repo.

It is amazing that a lot of people are sharing their opinion and ideas.

I would accept a proposal to Bring all material into the official wiki.social.coop and them create a new proposal about editing control.

The need to a more clear information for newcomers like me is crucial to the members begin participating.

I can often fall into the trap of just 'doing the thing' and not thinking about why I'm doing the thing. As a working group member, and one that worked on the CoC process/ updating the wiki in git a couple of years ago, I will be the first to echo @Ana Ulin that it is not very accessible. It evolved from the easiest to implement solution set up when social.coop was first established but probably hasn't scaled very well. In terms of registration, moderation, server access, use of git...it makes sense to me to keep these limited to WG members so that we have a proper on-boarding process before members can make possibly irreversible changes.

Agreed on all points.

In this case, following @Ana Ulin's concern, it might be best to call the document a "handbook" rather than a "wiki," to clarify that it is not meant to be universally editable.

But @emi do just to clarify: Have you edited the current version of wiki.social.coop recently? I found the current version actually quite easy to edit, with no git workflows, just markdown files. It can be edited by anyone with proper permissions here.