Loomio
Sat 12 Nov 2022 8:27PM

Time to consolidate wikis?

NS Nathan Schneider Public Seen by 199

As I've been trying to provide better documentation for newcomers, I'm realizing our documentation is a bit all over the place. Currently we have:

And there may be more.

I believe that we should have all this information in one clear, convenient place so that newcomers (and oldcomers like me, who struggled to find all this stuff) can easily understand how Social.coop works. To that end, I propose that we consolidate all Social.coop information into a single wiki that is appropriately editable by community members. @Christina Bowen @Tom Resing @Boris Mann @Flancian have expressed interest in this.

A proposal could be something like:

  • Bring all material into the official wiki.social.coop and ensure all working groups have access to edit it in Git

    • Can that system be deployed automatically based on Git repo updates?

  • Create a new wiki with SSO to Social.coop accounts, so all members can edit it

    • I've found dokuwiki works nicely with SSO and is simple to deploy and maintain and edit

Okay—thoughts before we make a proposal?

CB

Christina Bowen Sat 12 Nov 2022 8:58PM

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!

TR

Tom Resing Sat 12 Nov 2022 10:23PM

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.

NS

Nathan Schneider Sun 13 Nov 2022 12:43AM

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

NS

Nathan Schneider Sun 13 Nov 2022 1:02AM

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.

N

Nic Sun 13 Nov 2022 11:46AM

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?

NS

Nathan Schneider Sun 13 Nov 2022 9:30PM

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.

NC

Nithin Coca @ncoca Sat 12 Nov 2022 11:57PM

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.

AU

Ana Ulin Sun 13 Nov 2022 12:29AM

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

NS

Nathan Schneider Sun 13 Nov 2022 12:47AM

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.

AU

Ana Ulin Sun 13 Nov 2022 1:00AM

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.

CB

Christina Bowen Sun 13 Nov 2022 8:32AM

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

N

Nic Sun 13 Nov 2022 11:51AM

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.

CB

Christina Bowen Sun 13 Nov 2022 9:05PM

@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?)

D

Darren Sun 13 Nov 2022 2:14AM

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 😀

NS

Nathan Schneider Sun 13 Nov 2022 11:34PM

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.

ES

Ed Summers Sun 13 Nov 2022 1:04PM

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!

CB

Christina Bowen Sun 13 Nov 2022 9:16PM

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)

CCE

Clark C. Evans Mon 14 Nov 2022 12:00AM

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

NS

Nathan Schneider Mon 14 Nov 2022 12:21AM

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.

AU

Ana Ulin Mon 14 Nov 2022 12:45AM

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

NS

Nathan Schneider Mon 14 Nov 2022 1:02AM

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.

AU

Ana Ulin Mon 14 Nov 2022 1:57AM

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?

CCE

Clark C. Evans Mon 14 Nov 2022 8:57PM

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

AU

Ana Ulin Mon 14 Nov 2022 9:54PM

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.

CB

Christina Bowen Tue 15 Nov 2022 12:12AM

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

NS

Nathan Schneider Tue 15 Nov 2022 5:22PM

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.

MAC

Marcelo Avelar Cohen Mon 14 Nov 2022 4:55AM

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.

ED

emi do Tue 15 Nov 2022 3:55PM

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.

NS

Nathan Schneider Tue 15 Nov 2022 5:23PM

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.

NS

Poll Created Tue 15 Nov 2022 5:35PM

Draft proposal ideas—what do you think? Closed Fri 18 Nov 2022 5:02PM

Please rank the options below (1 is dislike, 5 is really like) to help guide the development of a proposal.

Results

Results Option Points Mean Voters
Consolidate all operational information into a single document (unless it is sensitive) 156 3.8 41
Rename the "wiki" to "handbook" to clarify that it is not universally editable 136 3.3 41
It's okay for just working group members to have permissions to edit 132 3.2 41
All members of Social.coop should be able to edit the wiki 120 2.9 41
I like how the current wiki.social.coop looks—it just needs to be better maintained 93 2.3 41
I think we should move to another platform, e.g., DokuWiki or Wiki.js 88 2.1 41
Undecided 0 0 185

41 of 226 people have voted (18%)

TR

Tom Resing Tue 15 Nov 2022 5:35PM

5 - Consolidate all operational information into a single document (unless it is sensitive)
3 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
3 - It's okay for just working group members to have permissions to edit
2 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
2 - All members of Social.coop should be able to edit the wiki
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained

It seems like consolidation might be the most important piece of this. I don't mind if only working group members have permission to edit. Renaming from wiki would probably help people understand the purpose

H

Harris Tue 15 Nov 2022 5:35PM

5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
4 - It's okay for just working group members to have permissions to edit
2 - Consolidate all operational information into a single document (unless it is sensitive)
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - All members of Social.coop should be able to edit the wiki

"Handbook" seems like a more descriptive and beginner-friendly description than wiki, even beyond permission issues. I think it makes sense for working group members to have edit permissions for security reasons—they should have a higher level of vetting than general membership. If we changed platforms we could utilize page level permissions to make certain "official" documents restricted and have other "fun" pages be world-editable, but idk if that's needed.

BM

Boris Mann Tue 15 Nov 2022 5:35PM

5 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
5 - All members of Social.coop should be able to edit the wiki
3 - Consolidate all operational information into a single document (unless it is sensitive)
2 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - It's okay for just working group members to have permissions to edit

I think we should have easy pathways for everyone to participate, and contributing / editing documentation of resources is a great first step. So, I think it's important that all Socal.Coop members should be able to edit. In fact, that might be part of onboarding -- add an entry / intro / background of themselves, of some kind.

I don't know what consolidate into one doc means. Yes it should be in one place, with sections, but not a document -- one place / platform.

N

Nic Tue 15 Nov 2022 5:35PM

5 - All members of Social.coop should be able to edit the wiki
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
1 - It's okay for just working group members to have permissions to edit
1 - Consolidate all operational information into a single document (unless it is sensitive)

If Wikipedia can cope with being open to the world to edit, I'd have thought the wiki here could cope with 1.5k cooperators being able to, esepcially given the ability to revert changes. The point of cooperating in wiki spaces is that if I see, say, a typo, I can quickly change it (without having to join a working group or email someone). But there should be admins with the power to revert changes. And of course review this if it ends up problematic.

MB

Moon Baron Tue 15 Nov 2022 5:35PM

5 - I like how the current wiki.social.coop looks—it just needs to be better maintained
5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
5 - It's okay for just working group members to have permissions to edit
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - All members of Social.coop should be able to edit the wiki
1 - Consolidate all operational information into a single document (unless it is sensitive)

This is a tough one. I'd say the best solution would likely be a wiki like DokuWiki with access controls such that certain pages (e.g. the CoC and By-Laws) be restricted to relevant WGs, while others are open to all social.coop members. This would encourage folks to contribute and round-out the docs for sundry things (e.g. requesting custom emojis, how to open a Loomio post).

This is likely too much to ask though, so I support just calling this a handbook and keeping its scope small.

CB

Christina Bowen Tue 15 Nov 2022 5:35PM

5 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
5 - All members of Social.coop should be able to edit the wiki
5 - Consolidate all operational information into a single document (unless it is sensitive)
3 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
2 - It's okay for just working group members to have permissions to edit
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained

A Handbook section of a consolidated wiki could be editable only by working group members. BUT it's important for all members to edit a shared knowledge base. I'd like to see a more clear outline structure so that I know whether I'm in the Handbook or general wiki pages. The current site is simple on any page, but hard to see how the pages relate or what to read next.

I think that having both wiki + git editing options (which both DocuWiki and WikiJS allow?) is way better than only Git.

D

Django Tue 15 Nov 2022 5:35PM

4 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
4 - All members of Social.coop should be able to edit the wiki
4 - Consolidate all operational information into a single document (unless it is sensitive)
2 - I like how the current wiki.social.coop looks—it just needs to be better maintained
2 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
2 - It's okay for just working group members to have permissions to edit

Choices overload!

Parse choices:

  1. Ideally we could consolidate non-sensitive wikis into a platform that we can SSO into (limited to membership)

  2. Otherwise rename to Handbook, and clearly label which Working Group to contact to submit edits to

J

John Tue 15 Nov 2022 5:35PM

5 - I like how the current wiki.social.coop looks—it just needs to be better maintained
4 - It's okay for just working group members to have permissions to edit
3 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
3 - Consolidate all operational information into a single document (unless it is sensitive)
2 - All members of Social.coop should be able to edit the wiki
1 - Rename the "wiki" to "handbook" to clarify that it is not universally editable

just giving it a quick review, but most of it seems fine, just some tweaking. I think that having this be the domain of those who are in the working group is appropriate.

AW

Aaron Wolf Tue 15 Nov 2022 5:35PM

5 - It's okay for just working group members to have permissions to edit
4 - I like how the current wiki.social.coop looks—it just needs to be better maintained
3 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
2 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - All members of Social.coop should be able to edit the wiki
1 - Consolidate all operational information into a single document (unless it is sensitive)

We should make it clear that anyone can submit changes via Git, which means they go through review and approval for merging, not just anyone edits. As long as that process is workable, I see less need for other tooling or setup, despite Git adding some level of challenge to the workflow.

Alternatively, a wiki is okay if particular versions can be marked as the latest approved versions that are put on the main page as the formal policies.

J

jicka Tue 15 Nov 2022 5:35PM

5 - Consolidate all operational information into a single document (unless it is sensitive)
4 - All members of Social.coop should be able to edit the wiki
4 - It's okay for just working group members to have permissions to edit
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
  • I agree that having a central place to look up all the information is a great idea.

  • Most of the wiki should be easily editable

  • Some parts of this wiki should only be editable after a vote (CoC changes for instance). I don't have an opinion if we should enforce this with a permissions system

  • As I'm not a programmer, I've never used git and I am not familiar with how it works. Using it for version control of a wiki would constitute a (at least small) barrier for people like me

MN

Matt Noyes Tue 15 Nov 2022 5:35PM

5 - Consolidate all operational information into a single document (unless it is sensitive)
3 - I like how the current wiki.social.coop looks—it just needs to be better maintained
3 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
3 - All members of Social.coop should be able to edit the wiki
3 - It's okay for just working group members to have permissions to edit
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js

Docs like the Code of Conduct should have two versions: a working draft, editable by any social.coop member, and an official version, approved by vote of the membership.

JN

Joshua Neds-Fox [@jnonfiction@social.coop] Tue 15 Nov 2022 5:35PM

5 - It's okay for just working group members to have permissions to edit
4 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
4 - Consolidate all operational information into a single document (unless it is sensitive)
3 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - All members of Social.coop should be able to edit the wiki

"Wiki" is descriptive of a feature and that's important but "Handbook" suggests authority and that's important too, so maybe... both? I really have no opinion on the look or maintenance of the current wiki.

D

Darren Tue 15 Nov 2022 5:35PM

5 - All members of Social.coop should be able to edit the wiki
4 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
1 - It's okay for just working group members to have permissions to edit
1 - Consolidate all operational information into a single document (unless it is sensitive)

I think having wiki/docs that anyone can update is an ace idea. We can keep the important official docs (bylaw, code of conduct etc.) published somewhere else when they are ratified if we cant easily control edit access.

V

Vica Tue 15 Nov 2022 5:35PM

5 - It's okay for just working group members to have permissions to edit
5 - Consolidate all operational information into a single document (unless it is sensitive)
4 - I like how the current wiki.social.coop looks—it just needs to be better maintained
4 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - All members of Social.coop should be able to edit the wiki

Happy for those more involved to lead on this and make the decision they think is most appropriate

DB

Doug Belshaw Tue 15 Nov 2022 5:35PM

5 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
5 - All members of Social.coop should be able to edit the wiki
4 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
2 - Consolidate all operational information into a single document (unless it is sensitive)
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - It's okay for just working group members to have permissions to edit

Handbook is a more inclusive term for those unfamiliar with how wikis work, although there might be an expectation for it to be "somebody else's job" to maintain it. That's why making it explicit that every member has edit access is important. I think moving platforms might help more people contribute to documenting the handbook.

AU

Ana Ulin Tue 15 Nov 2022 5:35PM

5 - All members of Social.coop should be able to edit the wiki
5 - Consolidate all operational information into a single document (unless it is sensitive)
3 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
3 - It's okay for just working group members to have permissions to edit
2 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained

This set of choices seems to skip over the foundational question of which content are we talking about here, and who is the intended audience and set of editors. Since my choices would be different for the two different scenarios, I'm finding it hard to give a meaningful ranking.

In any case, consolidating information seems the most important thing here, with secondarily making it possible for all members to co-maintain the content (which I think gives us the best chance at having good docs).

DH

Dick Hardt Tue 15 Nov 2022 5:35PM

5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
5 - It's okay for just working group members to have permissions to edit
5 - Consolidate all operational information into a single document (unless it is sensitive)
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - All members of Social.coop should be able to edit the wiki

I have no historical context so I'd be fine if my votes where ignored. Having it all be in one place, calling it a handbook, and only editable by the core team seem like good ideas. I don't have an opinion on the current wiki or if another platform would be better.

J

JohnKuti Tue 15 Nov 2022 5:35PM

5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
5 - Consolidate all operational information into a single document (unless it is sensitive)
4 - It's okay for just working group members to have permissions to edit
3 - I like how the current wiki.social.coop looks—it just needs to be better maintained
2 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
2 - All members of Social.coop should be able to edit the wiki

I think the decision about moving to another platform would be best taken by the people who are supposed to do the maintaining. Please remove the "blog" and "pages" parts of this site - they go against the idea of having a consolidated source of information, which is a really good one.

BS

Billy Smith Tue 15 Nov 2022 5:35PM

3 - It's okay for just working group members to have permissions to edit
2 - All members of Social.coop should be able to edit the wiki
2 - Consolidate all operational information into a single document (unless it is sensitive)
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - Rename the "wiki" to "handbook" to clarify that it is not universally editable

IANAWA, but

  • Use a permissioning system for the Wiki pages.

  • Each Working Group has pages that only a member of the Working Group can edit.

  • Each member can have personal pages that only that member can edit.

  • The Wiki Administrator can change those permissions, so all of the actions of the WA needs to be publicly logged, with access to the logs restricted to members of the coop.

  • All logs to be stored automatically off-site in a secure location.

These are Already-Solved-Problems.🙂

SJK

Stephanie Jo Kent Tue 15 Nov 2022 5:35PM

5 - Consolidate all operational information into a single document (unless it is sensitive)
4 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
3 - All members of Social.coop should be able to edit the wiki
2 - It's okay for just working group members to have permissions to edit
1 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained

Wide open editing could lead to problems, but it also should not be unduly restricted. There should be an easy application process with relatively low criteria - so as not to overempower the working group members or be exclusionary but to keep the number of editors reasonable and accountability more readily maintained. The permissions systems described by others and also a kind of ranking over which pages require more authority to edit seems wise.

ZS

Zee Spencer Tue 15 Nov 2022 5:35PM

5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
4 - Consolidate all operational information into a single document (unless it is sensitive)
3 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
3 - I like how the current wiki.social.coop looks—it just needs to be better maintained
3 - All members of Social.coop should be able to edit the wiki
3 - It's okay for just working group members to have permissions to edit

I really like changing the wiki to Handbook, regardless of it's editor-level; since I find that wikis are too general purpose and a Handbook (with chapters for different kinds of members) feels more tangible.

N

Neil - @neil@social.coop Tue 15 Nov 2022 5:35PM

5 - Rename the "wiki" to "handbook" to clarify that it is not universally editable
5 - All members of Social.coop should be able to edit the wiki
3 - I think we should move to another platform, e.g., DokuWiki or Wiki.js
3 - Consolidate all operational information into a single document (unless it is sensitive)
1 - I like how the current wiki.social.coop looks—it just needs to be better maintained
1 - It's okay for just working group members to have permissions to edit

I think we should have:

  • One public-facing handbook that is editable only by WG/Ops Teams, that works as an intro to socialcoop workings for newcomers.

  • One public-facing wiki, editable by any member. This is where working groups put their more day-to-day operational stuff.

JG

Jamie Gaehring Tue 15 Nov 2022 9:54PM

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:

NS

Nathan Schneider Wed 16 Nov 2022 12:33AM

Great points. I noticed these too!

NS

Nathan Schneider Wed 16 Nov 2022 12:26AM

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?

AU

Ana Ulin Wed 16 Nov 2022 1:05AM

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.

NS

Nathan Schneider Thu 17 Nov 2022 4:05PM

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.

J

jonny Wed 16 Nov 2022 10:24PM

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!

NS

Nathan Schneider Thu 17 Nov 2022 4:05PM

I love this:)

CB

Christina Bowen Fri 18 Nov 2022 4:18PM

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

BM

Boris Mann Thu 17 Nov 2022 4:18PM

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

CCE

Clark C. Evans Fri 18 Nov 2022 5:19PM

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.

NS

Nathan Schneider Fri 18 Nov 2022 6:02PM

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.

CW

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.

CCE

Clark C. Evans Fri 18 Nov 2022 7:43PM

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.

CCE

Clark C. Evans Fri 18 Nov 2022 8:25PM

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.

ES

Ed Summers Fri 18 Nov 2022 9:30PM

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

NS

Poll Created Sun 20 Nov 2022 2:58PM

Update on wikis—does this sound good? Closed Wed 23 Nov 2022 2:01PM

Based on this wonderful discussion and on my conversations in Matrix with the Tech Working Group, we appear to be arriving at the following solution. I don't believe this requires a formal policy proposal, as it is more a matter of implementation, which all working groups appear to agree with:

  • Consolidate all (non-sensitive) information about Social.coop operations in a single wiki at wiki.social.coop

  • Deploy a new wiki tool that is able to use Mastodon's single sign-on system, so all Social.coop members can edit (we are exploring DokuWiki, see https://socialcoopwiki.medlab.host/home). Rely on the wiki's version control and permissions to ensure that canonical versions of official documents are true to the text approved through our governance processes

Does this sound like a good direction? Any concerns?

Results

Results Option % of voters Voters
Looks good 19% 43 F KT C ZS DH AM K SB SR BS SJK CB DMK TR EM RH CW SS ES JA
Not sure yet 1% 2 AW M
Concerned 0% 1 MN
Undecided 80% 183 DS KF ST JD CZ BH LF JC BM NS SH G MSC CCC L EM MC TB SC JD

46 of 229 people have voted (20%)

LW

Laurie Wayne
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Great work, team! Thanks for figuring it out!

J

jicka
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

I agree this is the right direction to take. It'll make many things easier in the long run.

AW

Aaron Wolf
<span class="translation_missing" title="translation missing: en.poll_check_options.Not sure yet">Not Sure Yet</span>
Sun 20 Nov 2022 2:58PM

I support the consolidation and SSO direction. I'm concerned about effective-enough marking of canonical versions of documents. I lean against DokuWiki and urge the selection of a tool that uses Markdown and has a Git backend (though with good enough capacity to edit without interacting with Git directly).

TR

Tom Resing
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Sounds like you've explored the options, had the right discussions, and come up with an improvement to the current situation.

MN

Matt Noyes
<span class="translation_missing" title="translation missing: en.poll_check_options.Concerned">Concerned</span>
Sun 20 Nov 2022 2:58PM

"Rely on the wiki's version control and permissions to ensure that canonical version of official documents are accurate" -- I think it should be clear that "canonical" versions are voted on and the editable version needs to be put to a vote if people want it to become "canonical."

M

mariah
<span class="translation_missing" title="translation missing: en.poll_check_options.Not sure yet">Not Sure Yet</span>
Sun 20 Nov 2022 2:58PM

I have similar concerns as Aaron Wolf and Mark Noyes about markdown, and version control. Though, I like the general direction of consolidating.

CB

Christina Bowen
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

thanks for taking this on!

AU

Ana Ulin
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Thank you for moving things along and listening to all the input, @Nathan Schneider. This seems like a great direction.

C

Clayton (clayton@social.coop)
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Exciting!! This is going to be a big help.

TR

Tod Robbins
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Very excited!

KT

KC Terry
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

Based on the discussions so far, this seems like a good solution and improvement.

J

jonny
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

haven't used docuwiki, but happy to give it a try

SW

Sam Whited
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Sun 20 Nov 2022 2:58PM

I defer to the tech working group on this. FWIW I oppose the idea that others have had about specifically requiring Git/Markdown. As much as I also like those things and find it a comfortable editing environment, most people won't and we shouldn't constrain ourselves to use those as a backend just because a handful of techie users are used to it. As long as the system they pick allows us to export/move our documents later and is accessible I think it's up to the TWG.

NS

Nathan Schneider Mon 21 Nov 2022 3:05PM

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

NS

Nathan Schneider Mon 21 Nov 2022 3:09PM

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

AW

Aaron Wolf Mon 21 Nov 2022 7:42PM

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.

CCE

Clark C. Evans Wed 23 Nov 2022 4:20PM

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.

SR

Sam Rossiter Mon 21 Nov 2022 11:43PM

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

BM

Boris Mann Mon 21 Nov 2022 11:48PM

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.

AW

Aaron Wolf Tue 22 Nov 2022 2:27AM

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.

SW

Sam Whited Tue 22 Nov 2022 12:31PM

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

AU

Ana Ulin Tue 22 Nov 2022 6:10PM

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

J

jonny Tue 22 Nov 2022 3:07PM

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

AW

Aaron Wolf Tue 22 Nov 2022 5:35PM

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

ES

Ed Summers Sun 27 Nov 2022 1:42PM

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.

CB

Christina Bowen Thu 1 Dec 2022 7:50AM

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.

ES

Ed Summers Thu 1 Dec 2022 10:04PM

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?

NS

Nathan Schneider Thu 1 Dec 2022 2:46PM

@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

AU

Ana Ulin Thu 1 Dec 2022 6:53PM

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:

AW

Aaron Wolf Thu 1 Dec 2022 7:47PM

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

AU

Ana Ulin Thu 1 Dec 2022 7:56PM

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

AU

Ana Ulin Thu 1 Dec 2022 8:00PM

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.

ES

Ed Summers Fri 9 Dec 2022 1:05PM

For people following along this problem has been fixed.

SM

Scott McGerik Fri 2 Dec 2022 12:32AM

It took me several cycles of using Matrix before I got to the "space" and was able to join the wiki room.

NS

Nathan Schneider Fri 2 Dec 2022 3:43PM

I feel you—Matrix can be tricky. In our improved wiki we will provide clearer guidance!

AS

Andrew Shead Fri 2 Dec 2022 4:39PM

I strongly recommend consolidating all documentation on MediaWiki with edit access available to all community members, and administrative control access distributed amongst a Wiki Working Group. Contents of MediaWiki would be visible publicly.

MediaWiki is used across Wikimedia and elsewhere. All changes are recorded and can easily be rolled back to an earlier version should doing so become necessary.

MediaWiki is extremely powerful and easy to use with strong version control and places to Read, Talk, View history, easily see changes to the text, and communicate with one another.

I suspect that we can get MediaWiki as a service from our main service provider.

The hard part will be organizing our data in the most effective way, but whatever we do can be changed later.

ES

Ed Summers Fri 9 Dec 2022 1:13PM

I've been testing dokuwiki with our mastodon as a single sign on provider at https://wiki-dev.social.coop You can give it a try, but it is temporary, and just meant for experimenting.

The biggest issue is that I don't think Mastodon's API makes email addresses available, and the dokuwiki oauth plugin really wants to use emails to lookup users. I modified the plugin to assign an email based on the Mastodon username and the social.coop domain, which works. But you can't send emails to those addresses and you can't change it in your profile without breaking your ability to login.

I'm going to spend a bit more time to see if the oauth plugin can be customized to look up users with their login name instead of email. We can rely on these being unique from Mastodon.

If that doesn't pan out I wonder if asking people to register isn't so bad after all? It would still be an improvement on the situation with our git.coop wikis where people have difficulty jumping through all the hoops to register.

L

LibreEquity Sun 11 Dec 2022 8:56PM

I am still reading this whole thread but I'll say this anyway: (1) I like DokuWiki XWiki; it has very sophisticated & granular permissioning (2) I also like the idea of SSO, and have some basic experience setting up Keycloak (3) getting DokuWiki XWiki to work with Keycloak was difficult for me, although it was my first time setting up anything SSO-related (4) my sense is that a lot of open-source software avoids documenting SSO particularly well because they put it into their paid offerings. I plan to attend a Tech Working Group meeting soon so I can get more understanding of the big picture.

(Edit- apologies, I misremembered and confused DokuWiki with XWiki. There are differences between the two and my sense is they each have their strengths.)

L

LibreEquity Tue 13 Dec 2022 5:46AM

I think there should be a single wiki with page-specific access control. It can default to full edit, but particular pages could be locked or hidden from unauthenticated users. I think DokuWiki supports all of that. If not, XWiki definitely does. DokuWiki is simpler.

That said - I would discourage using even a private wiki page to store passwords (not that anyone was). For passwords I would suggest a separate system; a separate SOP. That's called "secret management". LastPass or BitWarden might be good solutions for that.

SSO might take longer to set up than people expect. It might work with one thing but not another, thereby making it not-SSO. It is still worth doing. I would just advise not to let snags on that front hold back progress on other fronts (eg using 1 wiki instead of 3).

NS

Nathan Schneider Fri 16 Dec 2022 12:17AM

I've made some major strides in consolidating our current material on wiki.social.coop. Please share any feedback.

The tech team is still struggling to find the right alternative wiki platform that would allow all members to contribute. But the current model at least enables people with git.coop accounts (generally, working group members) to contribute.

BS

Billy Smith Fri 16 Dec 2022 8:34AM

TY for the reminder about git.coop membership. :D

ES

Ed Summers Fri 16 Dec 2022 3:09AM

Just to clarify the struggle isn't so much the wiki (it would be relatively easy to bring up dokuwiki, mediawiki, etc) but how to do authentication without creating yet-another-login.

BS

Billy Smith Fri 16 Dec 2022 7:48AM

I don't really see this as a problem.

Anyone who wants can already look at the publicly available wikipages.

Editing/changing the wiki is something that most users don't need to do every day, so having a separate log-in would mean having to be deliberate about what you are doing. :D

For the London Hackspace wiki, the extra layer of protection helped reduce the attempts by spambots. :D

ES

Ed Summers Fri 16 Dec 2022 11:09AM

In case anyone goes searching for it I left some notes about the dokuwiki / mastodon integration test in this issue: https://git.coop/social.coop/tech/operations/-/issues/53#note_19784

NS

Poll Created Wed 11 Jan 2023 10:08PM

Are you good with moving to MediaWiki? Closed Sat 14 Jan 2023 10:01PM

Our Wiki Builders group (on Matrix) has been busy, consolidating wiki content into a single site. That work is currently up at https://wiki.social.coop.

Thanks to initiative from @jonny, we've been piloting a transition to a MediaWiki site, currently at https://wiki-dev.social.coop, including integrating good semantic standards (that are over my head). Registration for editing on the site is currently open. MW's fine-grained moderation tools will enable us to get the right balance, hopefully, between openness and security. But I feel good about erring on the side of openness, encouraging all members to participate in self-documenting the processes and wisdom of our community.

How does this progress sound to you? To be clear, this is a "sense check" on our progress, not a formal policy proposal. The results of this are not binding, but just meant to guide our work.

Feel free to register on the new site and add some knowledge you'd like to share. Give it a try!

Results

Results Option % of voters Voters
Looks good 15% 37 KF ZS AW SB SV MP BS I TR N RH M ED CD SS C AU AS BV J
Concerned 1% 3 NS D D
Undecided 83% 201 DS ST JD CZ BH LF JC JNM F BM NS SH KT C DH G AM MSC CCC L

40 of 241 people have voted (16%)

TR

Tod Robbins
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

looks great! let's keep the momentum going!

AS

Andrew Shead
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

Strongly in favour of MediaWiki, and pleased to see Semantic Wiki included.

J

jonny
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

in the words of spice, queen of dancehall: "yes a so mi like it" https://youtu.be/3yHmiixs3qI

I

Isabel
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

Exciting!

MP

Michael Potter
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

I supported MediaWiki for a couple of years some time ago, and I felt that it was clean-looking and relatively easy to use and maintain.

AU

Ana Ulin
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

Great progress, and Media Wiki is well-trusted and feels like a good choice!

BS

Billy Smith
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

I've not used MediaWiki before. :D

Experiments are always good. :D

SW

Sam Whited
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

MediaWiki seems overly complicated, and (I assume? It used to be anyways) difficult to run and maintain, but if the tech team thinks that's the way to go I defer to their greater knowledge.

J

JohnKuti
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

I'm adding the "operations" page to my watchlist.

NS

Nick Sellen
<span class="translation_missing" title="translation missing: en.poll_check_options.Concerned">Concerned</span>
Wed 11 Jan 2023 10:08PM

I think it's a great initiative, and should enable more participation. I'm pretty neutral regarding which wiki tool, so that part seems all good. Esp. if there are enthusiasts there.

The "concerned" part is from the tech perspective. I'd like to see clear acceptance from within the tech team that it has enough interest and support to keep it running (which might already be the case, just not mentioned here).

(Also wondering what happened with the dokuwiki initiative?)

SV

Sébastien Vigneau
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Thu 12 Jan 2023 1:07PM

Since Wikipedia uses MediaWiki, I assume it is well-maintained and follows current best practices. In addition, using it for our wiki will lower the cognitive load for users who want to contribute to both platforms.

D

Django
<span class="translation_missing" title="translation missing: en.poll_check_options.Concerned">Concerned</span>
Wed 11 Jan 2023 10:08PM

I like it, it seems very fast, looks good.

Just not sure if I missed something around secured pages and authentication, this looks like anyone can edit.

AW

Aaron Wolf
<span class="translation_missing" title="translation missing: en.poll_check_options.Looks good">Looks Good</span>
Wed 11 Jan 2023 10:08PM

Nothing's perfect. It's fine enough. I think SSO would be ideal.

D

Daniel
<span class="translation_missing" title="translation missing: en.poll_check_options.Concerned">Concerned</span>
Wed 11 Jan 2023 10:08PM

Concern only that it's not clear from this progress check whether SSO is "in scope" or not. I like the look of the pilot pages and I know mediawiki is commonly used, and appreciate the work done so far- but since a number of commenters above have spoken about wanting SSO, I'd like to know if that's in the plans as well.

AS

Andrew Shead Wed 11 Jan 2023 10:33PM

Kudos to @jonny for making this happen, and to @ntnsndr for the support. I'm positively impressed. Thank you all.

NS

Nathan Schneider Sat 14 Jan 2023 3:53PM

@Daniel Thanks for your concern. We are hoping to have an SSO setup for this in the future. I think that MediaWiki, as a highly standard, extensible tool, puts us in a good position for that. But currently SSO is a bigger challenge than just the wiki, and the Tech Working Group has been thinking through various options for months. I personally think SSO is important for us, and I hope we can find a comprehensive, elegant solution soon. But I don't think we want to hold up the wiki work to wait for that.

cc: @Aaron Wolf

BM

benjamin melançon Thu 19 Jan 2023 12:09AM

Great work doing this! Would love to see the best contenders for git-backed wikis because i'd like those on other projects. Mediawiki still feels

Or on the other hand, would Social dot coop consider hosting mediawiki wikis for members? 🙂

I corrected one typo on the front page last week, can people easily see that revision?

Are there content organization or navigation features we can turn on? Reproducing the current wiki is one thing but an improvement with autogenerated menus would be nice.

NS

Nathan Schneider Thu 19 Jan 2023 3:30PM

Thanks for fixing a typo! Yes, your correction can be seen here.

I agree we could use better content navigation. Suggestions (or direct experimentation!) are very welcome.

I don't think it makes sense for social.coop to host wikis for members. That drastically increases the expectations for maintenance, and it doesn't seem aligned with our core mission.