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

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

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

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

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

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

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

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

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

Like the idea of having wiki editing thats more open.

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

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

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

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

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

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

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

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

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

Perhaps this could be a path forward:

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

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

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

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

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

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

Nathan,

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

Clark

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

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

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

I agree with you here.

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

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

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

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

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

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

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

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

DokuWiki has excellent version control, but not with Git.

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

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

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

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

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

Agreed on all points.

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

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

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.

For people following along this problem has been fixed.

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

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

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.

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.

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

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

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.

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

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.

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

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

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

@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

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.

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.

Update! Thanks to the efforts of @Flancian @jonny @Ed Summers @3wordchant and others from the TWG, we now have a new wiki! It's a MediaWiki system, which catches us up to the state of the art of wiki-dom.

Also, more ambitiously, this is the first app that uses our new auth.social.coop user-management system. This is still being tested, but stay tuned for its rollout across the ecosystem.

This took longer than expected, but it was done right. I'm really proud of our team for getting us this far through a collaborative, thoughtful process.

Jump in at https://wiki.social.coop.

@Nathan Schneider

How do i login?

I couldn't find the registration link.

@Billy Smith hi Billy! we hadn't yet enabled user registrations. Would you like to give it a try now and help us test? :) The 'log in' link in wiki.social.coop should take you to an auth.social.coop URL where you can choose 'register'.

@Flancian In terms of strategy for the future: Should we allow anyone to register, or should we manage registration centrally, as the main means of membership management? I just want to make sure we don't create a pattern now that we will regret later?

@Nathan Schneider yes, very good point :) I think the most stable configuration would be:

1. We hook up the existing registration form process into creating an auth.social.coop user for new signups -- this could be a manual step at first.

2. We do a one-time import (backfill) of all active instance users into auth.social.coop, maybe CSV based.

A possible variation would be:

1. We move our registration process to be auth.social.coop based -- in particular if we find e.g. a Keycloak plugin that can afford us enough flexibility.

In any case I agree leaving registrations wide open is probably not what we want in the medium term -- happy to disable them anytime, I just thought it'd lower friction for any users interested in wiki editing now like Billy.

@Flancian

Able to register and log-in fine. :D

@Flancian Always happy to help with beta-testing. :D

Is it possible to fix redirects? https://wiki.social.coop/How-to-make-the-fediverse-your-own.html should go to https://wiki.social.coop/wiki/How_to_Make_the_Fediverse_Your_Own now; instead it redirects to the wiki homepage.

@benjamin melançon Tagging @jonny who has been the wiki guru!

@benjamin melançon I agree with the intent of redirecting, but where did you see this link to the .html page? Fixing links whenever we can would be a low tech solution.