Time to consolidate wikis?

It seems to me that we'll need clarity about a few things before we run with something like that (apols if this repeats decisions already made in social dot coop - I'm new here.):

1. how do we shape UX? (is this a member handbook only? a community knowledge base? is this aimed at the public non-member interested?) if multiple kinds of folks, do we need clear pathways from the main page to 'choose your adventure'?

2. who can edit structure (home page, mostly? tagging? not sure...)?

3. who can edit content?

4. is there a diff between pages 'officially' about social coop (member-guide / more controlled) vs a community knowledge base (more open)?

5. Where will the data live? (sounds like now at git? any problems with this?)

6. What are reqs for wiki tool options to best supports our needs?

If we get clear on at least what we need to find out from the above, if not answering all, then we could run with a how-to-do-it proposal, as the one above.

Happy to help, but new to much of this!

I agree with @Christina Bowen 's points of clarity. Thanks for identifying the need @Nathan Schneider and documenting the current state, and also for the beginning of a proposal. Sounds like it's worth taking a little more time to hash out some details, before deciding on a platform and moving all the content over.

Absolutely—that's why I started with a thread, not a proposal :)

Thanks for these ideas!

Ideally, I think every Start.coop member should have edit access, along with strong version control in order to mitigate against bad behavior. All official docs should be linked to the Loomio decision that ratified them. The Community Working Group would be tasked with managing the structure of the wiki, and would perhaps have special admin powers. This approach is predicated on us having a serviceable SSO system to facilitate this.

Alternatively, we could manage the wiki strictly through working groups. In this case, all working groups would have access credentials to the git.coop system, so they could update the wiki through that. This would probably work through our existing wiki.social.coop system, which means it would be a lot simpler. But potentially less democratic.

Every start.coop member or social.coop? Broadening edit access does seem important otherwise it might as well be a CMS. As every change is version controlled, perhaps better to start broad and tighten if there is abuse/spamming/etc, than plan for that and as a result lock it down and limit participation?

Sorry, Social.coop:) It's a bit tricky to be involved in two co-ops with somewhat similar names!

I agree with you on this. I would prefer to err on the side of openness with strong version control, in the spirit of participation. In the current models, all the wikis are pretty locked down and inaccessible. But this would also require some kind of SSO so that we know which user made which changes.

I don't think the order is necessarily an issue - after deciding a platform/location, we can move everything we have over first in its current form(s), and then, when its all consolidated, figure out how to better organize and structure it? One benefit of that approach might be that we would know we all have first, instead of searching for it in its separate locations later.

I would love to see all of our docs consolidated and made easier to find.

Of @Christina Bowen's excellent list of clarifying questions, it feels like at least #4 ("is there a diff between pages 'officially' about social coop (member-guide / more controlled) vs a community knowledge base (more open)?") is a blocker before moving forward with a more complete proposal.

For my part, I would love to see:

• an easy-to-edit-by-all wiki, which would serve as our more general knowledge base, and could also be used by WG for meeting notes and other info; i would like for this to not be git-based, to facilitate editing by all

• a separate, more "official" place that collects our bylaws, CoC, etc; this is maybe what is currently the mis-named social.wiki.coop

Can you explain why you'd want to have two separate ones? It seems to me that a transparency-first group like us should just want to expose all the useful info together with the official info. We could also have more strenuous permissions for certain pages, or just monitor the edit logs and make sure all edits are carefully monitored.

Given that we have a track record of letting things get out of date, I want to err on the side of simplicity in the hope that it will be easier to update.

Another way of accomplishing what you suggest is to use Mastodon info pages to memorialize the core official docs, but to keep everything else on the wiki.

My concern was mainly that we probably don't want to have e.g. the bylaws editable by all without any kind of auditing. If you think we can accomplish all of that in one system that is easy to edit by all for the knowledge-base-like content, then that's fine as well.

I'm also happy to use the Mastodon info pages for more "official" content, but that takes us back to the two-system solution.

While transparency is useful, as a new member i'm likely to run away if you dump all possible info in my lap at once. Seeing clear and well-connected paths to access what I need when I need it is different than putting it all together. (just thinking out loud here)

Another thing I've been thinking is that with a member handbook or somesuch, I'd expect to be able to reasonably read it through, to see an end, and not have it be too overwhelming. With a community knowledge garden, I visit to discover, like wikipedia, and expect it to be rich, and to grow. So the purpose and UX for the 2 is different, regardless of whether they can both co-exist happily in the same wiki.

Wiki JS does have the ability to create nuanced paths with some pages more closed / more open (even regional groups, which is cool), so if the info architecture was clear, I'd think we could treat them as two things, but host them in one tool - just need visual clarity when you move from one to the other. (sections? page styling? not sure)

https://docs.requarks.io/groups (wikiJS page on permissioned user groups)

(I remember getting frustrated in WikiJS by having to make manual links to existing pages each time, but have not used it for a while. IDK what per-page permissions docuwiki has.)

I like this idea for the reason that version control feels nicer in a git environment (clearer diffs and release tags) which seems good for changes to bylaws/etc, but wikis are generally more intuitive to jump in and edit quick. But if there can be two levels of permission in one space, then it's maybe just extra work.

@Nic Wistreich as i understand it, you can pick whether you can edit in git, or edit in WikiJS interface - the data is all in git. which seems great for ease / choice, just not sure about permissions nuance in the currently implemented docuwiki (which i think draws from git?)

I'd agree getting all this in hand would be a good thing to do.

Guess the work bringing all the docs together could belong to CWG, but maybe of interest to people who've not joined there? I'd like to see this not land with the CWG ops team as they already handle a lot of stuff for us.

Like the idea of having wiki editing thats more open.

I think currently you can edit text in wikis by getting access to git.coop by getting an email address @social.coop whoch forwards onto some existing email address you specify. Not sure who has access to set up new @social.coop email forwarding, or if this could possibly somehow be automated/streamlined to make it easier for people to start editing.

I like the idea of sticking with what we have if it doesn't create too much friction. Guess the editing workflow using git.coop (which is gitlab) may be somewhat alien to folks used to editing wikis - but not too hard to pick up. We could make a how-to wiki page 😀

Interesting. Though I guess I think it would be ideal for the front page of the wiki to serve the purpose of helping newcomers, while also being a gateway to the more detailed stuff.

Seeing how imperfectly organized and managed our existing materials are, my major design impulse at this point is to minimize the number of things that need maintaining.

I very much support the goals/ideas expressed so far:

1. consolidating the wikis (thanks for the analysis Nathan!)

2. making the wiki easily editable by all members without requiring knowledge of git

I completely understand the concern around edits to the bylaws and other important pages in the wiki. Perhaps our choice of wiki should support locking pages, or somehow getting alerts when certain pages are edited?

Currently wiki.social.coop provides information to potential new members as well as existing members. I wonder if we might want to introduce a very simple static website at www.social.coop that provides very basic information about social.coop and points in various places to the wiki?

Perhaps this could be a path forward:

1. consolidate all the public social.coop wiki content into wiki.social.coop

2. migrate the content to a new wiki (which wiki TBD)

3. set up a simple static site at www.social.coop

PS. I'd love to give DokuWiki a try--I've heard good things!

posted this look at nuanced permissions/ groups above, with additional context, but here's what I'm wondering if docuwiki also does or not:

https://docs.requarks.io/groups (wikiJS page on permissioned user groups)

Nathan,

I'd consider making it a static website driven by Markdown files in a git repository. Both gitlab and github have a way to directly edit textfiles, as well as triggers to rebuild on commit. We could setup branches on a separate staging website, letting the final editorial control be done via pull requests. There are several blog style generators to choose from. In this way, it's accessible and accountable to its user community.

Clark

This actually well describes our current wiki at wiki.social.coop. My ideal solution is actually to make this existing model work better and be better maintained. To test this, I'm working on a revision now.

My experience is that Git poses a significant barrier to community maintenance of documentation. Even with web-based editing UIs, it still requires editors to understand commits, branching, pull requests, etc.

(And can we stop calling a static website a "wiki"? It's misleading at best.)

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.