Discourse

[Harald Sitter]

On Thu, Nov 29, 2018 at 9:03 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
> On Wed, Nov 28, 2018 at 5:25 AM Lays Rodrigues <lays.rodrigues at kde.org> wrote:
> >
> > Let's not go in that way.
> > As a ~new person~ on KDE, 3 years only, we need to move to a modern web. At least in my point of view, I really think that using old stuff doesn't attract new people. In that I have a few ideas for some KDE websites go modern, but that is a project for the future.
> > Discourse is a way to do that. I don't have much idea on how is the cost to maintain such an application, but in the field to setup it, I don't
> > think that is hard since we just need docker and Postgres.
>
> Before we look into deployment, has an initial evaluation been done to
> determine how individual communities around specific applications
> would work with Discourse?

How would one best go about evaluating? Do we know what communities do
with the current forums? Do we have the original evaluation of how we
ended up with phpbb somewhere?

> Usually these communities only want to look at posts for their
> specific application, and in some cases we have customisations to
> support their specific usecases - which our existing forum supports
> (see https://forum.kde.org/viewforum.php?f=276 for instance).

Which customizations are there, what do they do, where is their code
and who maintains them currently?

> Once we're satisfied that's all okay and can accommodate everything we
> need, we then can look into deployment. At this point we'd:
>
> 1) 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
> 2) 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)

I've just had a look... Writing auth plugins is insanely easy. As in:
I probably spent magnitudes more time on our jenkins oauth plugin than
it would take to write any auth plugin for discourse ^^

> 3) Determine what's needed to import existing data we have

A full phpbb database dump from starters. Beyond that I am not sure
what existing data actually entails?

In fact, I am also not sure why everyone seems to consider importing
10 year old forum posts a given requirement here. We migrated away
from reviewboard with zero data migration, and the data that is in
reviewboard is largely much more relevant than posts on why changing
the wallpaper in Plasma 4.0 didn't work IMHO.
Data migration is hugely expensive in both human and computer time;
it's easy to say we want this, it's another thing to actually
practically make it happen. In fact, I know of a semi-recent forum
migration where a company that heavily relied on forums for user
interaction migrated by having users manually replicate threads they
wanted to keep into the new forum and after a couple of months threw
the old forum away. Often times the cost-benefit is just super poor
for data migration in general and most kinds of forums in particular.

That being said, if data can be easily migrated I say hooray. Whether
it deserves to be a requirement I am not so sure about.

> 4) Ascertain how best to structure things to make it easy for
> end-users to work with
> 5) Investigate what anti-spam options are available and how
> maintainable any customisations we need to support KDE specific
> workflows will be

Can you describe these workflows a bit?

There is this https://www.discourse.org/plugins/akismet.html not sure
it's sufficient though. One could always opt to write custom plugins
if necessary, that really depends on what we need though. AFAIK
discourse also has a fairly comprehensive REST API, so one could
possibly also approach it from the other end and have a micro service
hit spammers with a ban hammer after the fact.

> My main one 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)

https://github.com/discourse/discourse/blob/master/docs/SECURITY.md

HS