Can we just use talk as our wiki instead of dokuwiki?

Continuing the discussion from Wiki Permission Denied Error page:

Talk (and discourse) has been working great!
Dokuwiki is having problems, two different systems with two different login and different problems. The Dokuwiki theme does not match the theme of Talk and the rest of *.hackspae.ca.

Can We/I migrate all the pages from Dokuwiki to Talk as wiki pages?

The new TALK wiki pages would then be searchable when someone is looking for an answer, everyone with an account on TALK could update the wiki pages, We can create a new category for the wiki pages so it is clear that anyone can edit these pages. Spam control is already set up, Internal linking is easy, history is easy, Support for the system is easy. I like editing TALk pages more than Dokuwiki pages. Once place to look for information, etc…

From the looks of it I can do migration via the discourse REST API. I would only take in the top level edit (what the current page looks like) and not the history of the page.

I am looking for a conversation and consensus.
The wiki is infrastructure and has been around since the start of VHS. This job would take longer than ~4 hours to undo, it is not a task that can be decided by do-ocracy. Please don’t start this project unless there is consensus.

Thoughts, comments, suggestions?

I’m not terribly fond of this idea for a few reasons, but I won’t complain too much it if others really like it.

Rationale:

  • Advanced Wiki formatting (tables / etc) doesn’t seem to be possible with discourse. For things like the laser cutter material settings table, we sorta need these.
  • Change history doesn’t seem to be kept (I may just not know where to find this!) Funvill has showed me I do not in fact know how to find this.
  • I prefer the wiki-type system for organizing information, though this may not be the case after playing with talk-style-wiki-pages for a while. Maybe if we port one complex page as an example, it could serve as a test article?

That said, I would advocate an alternate approach: authenticate dokuwiki against our discourse users database. That way, signup / spam / etc goes through the existing chokepoint. I can look into implementing this, but I’d need privs for talk + vancouver.vanhack.ca servers.

1 Like

Unless there is a downside I don’t see beyond sentimental reasons, I think
it sounds logical.

GitHub has a way of doing it, see: Writing on GitHub - GitHub Docs

First Header  | Second Header
------------- | -------------
Content Cell  | Content Cell
Content Cell  | Content Cell

More info about tables

History of edits to pages are kept in Talk
For example this post has 22 edits Packing up the bunker (Move out and clean up committee)

Click the pencil button on the post
image

And you will get a page like this

That would work for me.

Good to hear about the history thing. Sometimes I find discourse’s UI not terribly discoverable :P.

For table support, it looks like that type of thing is still in progress on discourse, so may not be an issue for long.

I don’t believe the Discourse wiki system is a proper replacement for a dedicated wiki.

  • The wiki is designed to keep track of and catalog all pages, making categorization and linking pages easy.
    See Sitemap [Vancouver Hack Space]
    If we were to use Discourse, then there would be significant overhead in properly categorizing everything so that it’s findable again. This is a barrier-to-entry in both creating a page (because there is extra effort involved), and reading wiki pages (because if something hasn’t been categorized properly, then they would be required to know what they’re searching for instead of just exploring)

  • As a wiki, users generally know that they can edit pages and how it works. New users won’t intuitively know that they can participate in a forum post that way, and may feel slightly uncomfortable doing so.

  • A wiki is more or less static, and encourages users to explore and read a bunch of pages. A forum system (even if it’s technically a wiki) is linear, and the paradigm is for users to read the last few topics, and then only start participating going forward. The history tends to fade away into obscurity.

  • Spam control is now set up on Dokuwiki, too. Anyone can register and immediately start editing pages.

  • The theme for Dokuwiki is different from Talk is different from Wordpress. If somebody cares, it is possible to download or edit new themes for all three of these services to match. As far as I know, no one cares enough to work on this.

  • Along the same lines, there are different accounts for Talk, Dokuwiki, Wordpress, Google Calendar, and the membership system. This is unfortunate, but plugins could be developed for all of them to authenticate through API to whichever service we decide should be the overall account system. I’m also not convinced that “master account” should be Discourse, but that’s a different topic.

  • Custom extensions are reasonably easy to write into dokuwiki (because it is an easy system). Custom extensions for a wiki on Talk have a barrier to entry because you have to understand how the forum code works before you can work on the wiki code. See here and here*.

  • A wiki only works if everyone uses it. I see a some repeat questions that are answered on wiki pages, but it’s not the go-to information source for most people. This is kind of catch-22 where people have to use the wiki before it becomes useful.

  • Editing Talk pages bumps them, which would be pretty annoying for a wiki.

My conclusion:

Discourse is the new hotness, so it’s tempting to try and migrate everything we have to the new platform, but realistically, it is not the right format for a wiki.

.


*This hack is named in a tongue-in-cheek fashion and shouldn’t be taken seriously.

** Related note: I will argue in favour of a wiki, but maybe not Dokuwiki in particular. It has quirks that I’m not a huge fan of, and wouldn’t mind migrating to some other (proper) wiki platform.

1 Like

If anyone is interested in exploring the use of LDAP to have a shared authentication system between the services, I’d be happy to do some coaching/exploration/light sysadmining.