Time to consolidate wikis?

As someone who still feels pretty new to the community, I'd like to flag a couple "low-hanging fruit" issues I think would make a tremendous difference to the experience of new users:

1. Add a direct link to the wiki from https://social.coop/about/more. The Mastodon server is how I first joined Social.Coop and where I'm still most active, so this is how I usually navigate to the Wiki via the "About this server" (see below*) link. There's a link to the "wiki" but that goes directly to the CoC, which seems redundant to me since there's already a link to the CoC on git.coop.

2. On the Wiki, distinguish more clearly between "Home", "Wiki" and the social.coop Mastodon server. After navigating to the CoC as outlined in No. 1, I always click "Home" in the main menu (see below**) to get to the main entries of the for the Wiki itself, but am confused when this takes me back to Mastodon instead. It takes me a lot of trial and error to realize that "Wiki" is actually the link for the home screen. This is made all the more confusing by the inconsistent URL (ie, `home.html`) and heading of "HOME" which are given to that page. To my mind, it would be more intuitive to simply label the link to https://social.coop as simply "Social.Coop", and label https://wiki.social.coop/home.html as "Home", but I'm sure there are other configurations that would work just as well, so long as they're consistent.

Apologies in advance, I know these are such trifling nitpicks, but they seem like they'd be easy enough to change and I think would go a long ways.

* Screenshot of the "About this server" link:

** Screenshot of "Wiki" page:

Great points. I noticed these too!

Initial thoughts based on responses so far: Propose a two-stage process:

• Short-term: consolidate all information into the current wiki and ensure all working groups have access

• Medium-term: adopt SSO system for members and add a fully member editable wiki

Thoughts?

When you say "the current wiki", do you mean https://wiki.social.coop or the GitLab-based WG wikis?

I assume that the WGs had their reasons to migrate their note-taking to the GitLab-based wikis, so I would hesitate to move them back to wiki.social.coop without consultation, just for the sake of consolidating somewhere.

FWIW, I have been in conversation with members of both WGs in the formulation of this proposal. I have not heard any opposition to consolidation, except with sensitive information.

I wasn't able to comment on my vote because the loomio mobile site is a little wonky, but I am hugely in favor of having an actual wiki wiki!!! I agree with above points that a static site in a repo is a prohibitive barrier for many- having the pages in a different "place" than they are published is a challenging cognitive model for nonprogrammers/people that are used to documents being documents, and so can having the markup syntax be different than the rendered page!

I hear the concerns about edit permissions, but I also am a big believer in the principle of SoftSecurity, particularly as it applies to wikis. We are a pretty large co-op, but a co-op should be built around trust! If someone were to make a malicious edit to the bylaws/other pages, that should be visible in an edit history and would be a pretty clear violation of principles of good faith, so would be a matter of reviewing membership. I think the benefits from quasi-universal edit access are much greater than the risks, as everyone is able to lend a hand organizing and it doesn't fall all on the ops teams.

I've been using wikis in my residential coops with universal edit access for years and it works excellently. We use mediawiki because it has a wonderful visual editor that keeps barriers low for people used to gdocs, but I am always open to trying new wiki engines.

I think having a functional wiki would do wonders for the organization- being able to put all minutes in one place that's discoverable by everyone, link out to relevant loomio threads to have a longer-stretching institutional memory, document processes and projects and everything else! I don't see a conflict between having more narrative/guidelike pages and having more wandering webs of pages, to me that's just a matter of choosing which style is appropriate when, rather than a need for multiple mediums.

I'm also a huge wiki evangelist generally and have started about 50 of them at this point so forgive my enthusiasm. I don't mean to dismiss others concerns & would be better about being in thread but I saw this while I was out and about and it's sort of hard to thread on mobile lol

in cooperation🫀

edit: I'm also happy to help set it up! @Flancian got a chance to see my wiki enthusiasm this last weekend in a workshop we had set up,and I thought that one worked well!

I love this:)

also love this - and a relative noob, but happy to help if i can @jonny

Yay Jonny! I also am excited by wikis! Shared sense making FTW

Excuse my ignorance, but are there wiki systems that use a revision control system such as git for backend storage of text? Do those systems permit direct modification of content via git? This would facilitate a review process, and permit offline curation.

Yes, for instance GitBook provides a frontend for a Git backend.

But virtually every wiki has a decent version control system. The feature-set of Git is not really necessary for most wiki applications, so most wikis don't use it. Given that most of our users are not Git users, I think it is actually bad for usability to use a Git-based wiki.

Thank you for saying so. I might write content for what we do. (In fact, I volunteered to write a Q&A about what the Finance Committee does and how finance is coop governed for our members). I am not a Git user, and I don't understand the comparative features that we are discussing in this thread. A Git-based wiki might not work for me as a contributing writer unless there was onboarding and learning support. I have some tech-learning fatigue, though I am also curious to be a Git user. I appreciate the overall sentiment of this thread of conversation: to put more of our information in one place for members to use, especially new members who are onboarding to Social.Coop, and for members to innovate by expanding the knowledge-base of what Social.Coop is and wants to become.

I'm not volunteering to do the hard work here -- and that's editing. Writing content is easy. Curating content is the hard part. This involves: integrating new content written by others in a manner suitable to the organization; editing existing content, to ensure that it's coherent with the rest of the material and up to date; linking and indexing content so that is logically organized in a way that can be discovered; and finally, pruning material that is unnecessary or expired. As someone who had to maintain materials for a group of ten contributors, I found a wiki to be poor for these tasks. Yet, leaving curation to the wind means you have uneven content, content that is irrelevant, content missing important aspects, etc. How I succeeded in the last editorial job I had was basically brute force... I used markdown in a git repository, and had people send me changes via email. It sucked, but it worked. Emails actually worked well, it created a natural TODO list for me. Also, I could have a staging zone and ask for feedback. I taught a few semi-technical contributors how to email me markdown. I then used git to manage conflicts, etc. Anyway. I guess what I'm saying is that the tool used should reflect the needs of whom ever is going to have the curator/editor role, which should be explicit. For me, while a wiki interface for contributors is nice, having a way to bypass the wiki interface and directly edit the content would be an essential feature for editorial work.

Nathan, I'm a bit puzzled by your response. Perhaps we're misunderstanding each other. If it exists and meets user needs, I'm suggesting we use a system that has git+markdown for a storage layer. This would benefit someone who has to do editorial/curation work, to bypass the web based user interface as appropriate. I'm not suggesting that contributors would need or want to directly use git+markdown directly. Hence, this request is independent of that class of users, or at least should be independent, as the front end shouldn't expose git complexity.

@Clark C. Evans sorry if you've already surmised this, but the system we have now is git based on git.coop. People edit via the gitlab interface (if they can login), or by committing directly to the repository (if they do git), and then pages are picked up by a server that is pinged via a webhook. The problem that I think this thread is illustrating is that the wiki is in need of gardening because a lot of people (including myself until recently) don't really understand the mechanism, and were not motivated, or able, to tend to the content.

As the membership grows it looks like we may be converging on using an actual wiki, hopefully one that is maintainable and that people can easily authenticate to edit, without having to do Internet research to figure it out. If that's git on the backend with Markdown that's great, but that's just incidental and not really (in my opinion) the primary motivation for this discussion.

@Matt Noyes @mariah @Aaron Wolf sorry for the misunderstanding, that's what I meant by "canonical." I can revise the language.

@Aaron Wolf Do you have any tool suggestions? What you describe is what we currently have, but unfortunately it is not really a wiki because it requires a manually created account. And structural changes (menus, etc.) require even more technical intervention. DokuWiki has the benefit of simplicity.

I'm also not sure what advantages Git has over simpler version control in the context of a wiki, where changes occur sequentially rather than through complex parallel processes. Especially for a less-technical userbase for whom the Git features are likely to be more trouble than they're worth.

See above for repeated concerns that Git presents barriers to accessibility.

Lacking SSO and blocking totally-anonymous-public-editing does not make something "not really a wiki". I definitely want to see SSO, I agree about the value.

I do not know all the options, but I saw https://js.wiki/ as something to consider.

I also found that DokuWiki plugins might resolve my concerns. https://www.dokuwiki.org/plugin:commonmark can let us all work with Markdown. That's the main thing of my concerns. https://www.dokuwiki.org/plugin:gitbacked looks interesting.

EDIT: https://github.com/gollum/gollum/ looks really compelling. It's like the GitHub/GitLab wikis but independent. It does not require anyone to know or interact with Git. It supports some SSO. It supports Markdown. It might be just the solution. I don't know how it works (or what variations of workflows we could develop) for marking canonical-versions of documents.

Git workflow is just much better than wiki for tons of reasons for anyone up for using it. The capacity to make changes for consideration, review them, adjust them, all before they get merged and while others might be making other changes at the same time. While forcing people to learn Git is a no-go, allowing people to use it has lots of benefits. Git does NOT present barriers to accessibility if there exists a straightforward way to propose/make edits without any understanding of Git (which many Git-backed tools do offer).

On "canonical" versions, I want to avoid situations where people are looking at non-canonical versions and might miss that fact. I'd want some set up that shows the canonical versions by default and accessing non-canonical updates is opt-in, people have to click to choose to see updates.

Gollum does sound interesting. Having an independently accessible and version controlled backend for media, should provide significant advantages. There are explicit features and implicit ergonomics that @Nathan Schneider and others are looking for -- what are they? The express features that I have found useful in the past:

• Having independent access to text files of the wiki site so they can be changed and committed in a single transaction.

• Being able to have a separate staging site, so that changes can be ratified by the community as a whole. This may not be needed by this community.

• Having history to know when content was changed and by whom.

• Ability to more easily validate/curate/prune content since you can see all of the files involved and use tools such as spell checkers; global changes, etc.

These are the sort of things that a version controlled backend might provide. It appears that DocuWiki has a gitbackend plugin, but it seems this is not endorsed by the community, https://www.dokuwiki.org/devel:ideas:git_backend. However, programs such as Gollum may not have the implicit quality that users might expect. Further, there is probably concern that complexities, and not just benefits of git, may bleed though.

I've been looking at https://github.com/documize/community#readme it's also 'not a wiki' but might solve the documentation problem. It has SSO.

If anyone wants to have a look at it then DM me your email and I'll send you an invite to a dev instance. https://docs.transition-space.org

This looks super interesting! SSO + phrasing as Confluence alternative seems good.

Before we finalize, I’d love to shortlist three or so options, try them with slightly different users. I’ll see if I can get this running to try out.

Documize uses the "open-core" style of proprietary software. The licensing is AGPL+CLA. So, the "community edition" is AGPL, but all contributions are under the CLA which allows the company to make proprietary "enterprise edition". These sorts of arrangements are better than totally proprietary software, but they do not set up healthy real community arrangements with cooperative spirit.

I don't know what Confluence is or why this would be better or worse than a wiki.

As long as everyone understands the concerns and trade-offs, I'm not staunchly opposed to Documize or to compromising by using open-core software. However, I want everyone to acknowledge that it is a compromise, that open-core is not ideal compared to actual FLO (Free/Libre/Open) projects that have no separate tiers, no exclusions and proprietary restrictions.

Confluence is a wiki made by Atlassian. It's the worst, most irritating, unusable piece of software ever made. I'm not sure what makes this an alternative to it specifically :)

Now, now, you're exaggerating. The most irritating and unusable piece of software ever made is Jira. Confluence is merely the second. 😹

want to give another strong nod to mediawiki and its visual editor as the lowest barrier tool I'm aware of, and to the notion of SoftSecurity and lack of evident need for careful pre-planning of edit/approvals in the context of a co-op, as someone with plenty of experience in this specific domain.:)

I see there is a Markdown extension at least https://www.mediawiki.org/wiki/Extension:WikiMarkdown

I'm not sure other details and SSO etc. I still prefer Git-backed so that Git workflow is an option (side-note: I'm not a programmer, I've just learned to really appreciate the value of having branches and reviews and such; that's not for strict security as much as a preferred creative collaborative way of working).

Given the result of the poll above to consolidate and then port the content to a more user-friendly wiki I've gone ahead and largely copied the Tech Working Group wiki content that was previously in https://git.coop/social.coop/tech/operations/-/wikis/home into the general wiki at https://git.coop/social.coop/general/-/wikis/tech-working-group/Tech-Working-Group

I updated some of the links so that they work, but some of the content is quite stale and in need of further consolidation. I thought that could happen now that it has been moved, or once we've decided to move to new wiki software (and it is easier to maintain).

I think that we will want to archive the old repository, or remove the wiki content from it, so that there isn't confusion about where to edit it. One reason why we might want to remove the wiki content instead of archiving is that we have been using the issue tracker in the tech/operations repository to track issues.

thank you, @Ed Summers! Do you or anyone know if people are wanting to look at this from a UX point of view as a path to further consolidation? I'd be happy to help with that.

Hi @Christina Bowen Yes, I think we definitely will want to do that. I think it could be helpful to have a meeting or perhaps join the Matrix chat?

@Christina Bowen thanks for your interest in participating! If you or anyone else would like to pitch in, please join us in this Matrix room: https://matrix.to/#/!aevtMVSJMpwTzohLVx:matrix.org?via=matrix.org

Does one need to be a member of some specific Social.coop Matrix space first? I am in both the social.coop "tech chat" and "open chatroom" Matrix channels, but Matrix gives me this error when I try to join the link above:

I do suggest getting to the "space", that's what worked for me.

Thanks for the direct space link in Matrix, @Aaron Wolf, that was helpful. 🙌🏼

In case anyone else is as confused as I was about how to find this "space", this link might work: https://matrix.to/#/#social.coop:matrix.org

Now that I have managed to join this channel, I notice that I can't see any previous activity in the channel because the messages are encrypted. Not sure if that's intentional or not. If we want to use the channel for coordination, and there is nothing very sensitive being shared there, it might be helpful for newcomers to the channel to be able to see past discussions.