Time to consolidate wikis?

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.)