Infrastructure/Evaluation/Discourse: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 18: Line 18:
* Scalable search for amount of posts we have
* Scalable search for amount of posts we have
* Tagcloud
* Tagcloud
* Gallery (for krita; unclear of what is exactly required here)
* Retain all data from current forum
* Retain all data from current forum


Line 71: Line 72:
end-users to work with.
end-users to work with.
</blockquote>
</blockquote>
One would presume the structure could be very/entirely similar to what we have currently.  Discourse offers a fairly similar view, scalable to many different subforums (e.g. https://discourse.ubuntu.com/). It may be wise to also revisit the overall structure and possibly merge some forums though.


== Anti-Spam ==
== Anti-Spam ==

Revision as of 13:16, 4 December 2018

Discourse

Ongoing evaluation of Discourse for Forums / Mailing List needs.

https://www.discourse.org

Proposal thread: https://markmail.org/thread/rnmyc5upbxdqoug5

Pile of Requirements/Desires

  • Easy and quick to use spamer nuke feature
  • Mark threads as solved
  • Forum banner / Newsbar banner
  • Guided posting wizard
  • Profile Icons to show OS/Distribution
  • Brainstorm (post voting)
  • Identity Integration (auth)
  • Scalable search for amount of posts we have
  • Tagcloud
  • Gallery (for krita; unclear of what is exactly required here)
  • Retain all data from current forum

Stack Eval

Look into the actual technology stack they use (seems to be Rails based in this case) to make sure there aren't any potential snags there

Ben took a quick look: My main one [concern] here is the lack of any options for installation other than Docker which makes no sense for a Rails application. Looking into their Docker image installation script I see that they build both Nginx and Imagemagick themselves (and stepping outside of package repositories is generally a bad idea). Imagemagick is of grave concern as this project has had numerous security advisories in the past and I see the version they're using isn't the latest one. I have further concerns for Nginx as they include a third party compression module, Brotli, whose codebase hasn't been touched in 2 years (plus it's a compression method, so you have the risk of CRIME/BREACH attacks).

Auth Options

Evaluate what support it has for authentication options (Identity requires LDAP at the moment, but will move to OAuth2 at some point using a custom API)

Data Import

Determine what's needed to import existing data we have

We have phpbb 3.0 which is supported to migrate from. There may be problems with custom mods adding custom stuff to the database (notably the OS/distro icon would not be migrated obviously). It may be good to actually have a schema to look at. Also, hard to tell how well this will work in practice without giving it a try with an actual db dump from the production phpbb forum.

Guide

Structure

Ascertain how best to structure things to make it easy for end-users to work with.

One would presume the structure could be very/entirely similar to what we have currently. Discourse offers a fairly similar view, scalable to many different subforums (e.g. https://discourse.ubuntu.com/). It may be wise to also revisit the overall structure and possibly merge some forums though.

Anti-Spam

Investigate what anti-spam options are available and how maintainable any customisations we need to support KDE specific workflows will be

TODO

  • Figure out how our current forums' spam protection works.
  • Talk to upstream about their awareness of docker security responsibility and the specific issues Ben highlighted on the mailing list.
  • Get some test setup and figure out how to structure stuff (as in: how to mimic subforums etc)
  • Look into how the various subforums utilize phpbb and if that still works with discourse
  • Figure out what to do about the custom mods we have on phpbb (generally we'd want to get rid of as much as possible to increase maintainability etc?)