Considerations When Choosing a Discussion System - Shure USA

Sound reinforcement systems are utilized universally in boardrooms, education and the corporate workplace, whilst councils and parliamentary meetings combine a rich mix of demands and limitations. The main requirement, as with any meeting, is that the people in the room are heard clearly and understood. However, problems may arise during the meetings when they are held in large rooms with poor acoustics. This is exacerbated by the fact that the same meeting space may be required to host a meeting of 10 people one day, and 100 the next. In both of these situations, each participant needs to be heard clearly and understood.
 

VISSONIC contains other products and information you need, so please check it out.

Considerations for a Discussion System

As seen on any televised Parliamentary meeting, many people talk at the same time. Ideally, the chosen discussion system provides the functionality to establish an order to the sequence of speakers in the meeting. The system should provide the operator with a choice of modes so the meetings can continue naturally (Voice operated, manual, automatic). Moreover, the speaker may need to be introduced to the group so that the meeting attendees can identify who is speaking, their political affiliation or other information. Additional features required of discussion systems include agenda management, voting and more. Added to this is the requirement for free seating topology that allows a meeting member to sit anywhere in the room and log on to the system with a card or pin that loads their unique identification and history information.

Many discussion systems fall down at the input stage. The key aspect of a system is the microphone, and the signal integrity is only as good as the microphone that the speaker is using. No matter how expensive or high-quality the speakers or amplifiers are, poor quality microphones will produce poor quality audio, and most projects fail or find problems when they choose inexpensive microphone systems. Not only is the sound quality poor, the components are also low quality and the mics often lose their integrity and begin to sag and droop. The base of the stem and the head of the microphone are frequently adjusted to cater for different speakers, this flexibility is crucial but also the Achilles heel.

 

So, I have seen so many situations where democratic discussions are desired, be it local / national politics or worker coop. However, we always get stuck with the fact there is no good discussion system, nothing without pollution from Google, Facebook, etc (or in Japan, this thing called “Line”, just as bad as any)

Mailing lists are cheap and abundant but there are severe limitations and NNTP (newsgroups) seem dead, almost.

Then again this Discourse - it is so damn expensive to host and I have been wondering why - it seems this beast is so complicated, requiring the use of docker to install all components.

I know that most of our discussions are text based and this should not be this complicated!!

So I wonder, if we can just write an extremely lightweight discussion system in which all discussions are stored in Git and all pages are “statically generated” with a compiler that runs each time a new git message comes in. Then all we need is Apache web server hosting static pages and accepting text uploads?

Maybe I should try Scheme or Haskell to write something

That’s really not a fair characterisation of Discourse.

The Discourse team have spent a huge amount of time to make it easy to deploy and maintain. Docker helps with that (permitting almost interruption free one-button online upgrades and simple clean rebuilds to get you back up and running quickly)

If you have basic Linux skills it takes about 30 minutes to an hour to install and get up and running.

The instructions are here: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

I run 3 sites and each uses a very cheap VPS. I do all the SA myself. My coop runs several more.

In 4 years of running Discourse the only downtime I’ve had has been due to my error or that of my VPS hoster and even then we are talking a total of minutes. It’s ROCK solid.

This is not correct. You can get away with 1GB but I would recommend 2GB. You will need at least 20GB but this really depends on what kind of content you intend to post, number of users etc etc

If you can’t afford the cost of Discourse official hosting (yes it is fairly pricey but someone’s got to pay all the devs for all that work) and don’t have the technical skills to install and run an instance yourself (it’s not that hard though and you can learn!) then there are other options at lower price points. I can introduce you to three options depending on your budget.

I’m puzzled by the spam problems you have had @jamie, this site has about one spam post every two months, 13 spam posts in two years.

I’m sure you have some horror stories of MediaWiki or phpBB sites being utterly destroyed by spam bots in the past, I sure do…

Discourse really doesn’t appear to have this problem, however I was expecting it to be really bad, based on past experience… so we have configured the Discourse servers we host to sit behind an anti-spam gateway server:

dig mx community.coops.tech +short
10 mx.webarch.net.

Perhaps this is taking a load off Discourse, that server is running SpamAssassin.

For outgoing and incoming we are doing this on the VM hosting Discourse itself, see these (old and in need of serious update) Ansible tasks:

And this works fine once configured.

For small activist or community non-profit groups I don’t think Discourse is a practical option, this is why I spent a while writing a Flarum Ansible role, I just need an organisation to test it with now .

So I have replies along 2 lines:

Discourse

I’ve installed this before and it was pretty easy. Most of the pain was sorting out external and that will apply to anything. Yes, some of the options can get complex but the anti-spam measures are good. Like most things in life, a good discussion site is more complex than it looks and in my (limited!) experience Discourse keeps a good balance between keeping key stuff in core and letting people push the rest into optional extensions.

Storing stuff in git

If you want to learn more, please visit our website Videowall Controller.

So this is actually something we have been looking into, but not for discussion, for data. For one of our projects we store the data in a git repo - register/lists at main · org-id/register · GitHub - so it’s really open. We then have a nice browsable front end at http://org-id.guide/

But the problem of course is, as already said, requiring Git / GitHub use will be a massive barrier to some people. Depending on what the target audience is, this will be more or less of a problem. It’s a problem for people who want to edit Org-Id. To tackle that, we are working up some ideas about ways we can present nice UI’s to non-tech people that then helps them save the data.

I’ve actually seen several people store data in Git, and so we are working up a general purpose tool to help with this use case. Er, it’s so new there isn’t any documentation yet and we haven’t blogged about it, but that will all come soon. GitHub - DataTig/DataTig

In the mean time, happy to chat to anyone interested in this idea, and let me know if people see other store-data-in-git projects.

Also not discussion, but along the same lines I have previously seen a static site builder service that then gave you a Web UI to edit content and turned it into GitHub PR’s. If people are interested I can go dig out the link.

Really?! To whom?! Hilarious!

It means, in general, if at a minimum you know how to change directory and return the file contents of the current one you will likely have no problem achieving it within the estimated time.

If your Linux knowledge exceeds that you will likely find it very easy.

It’s true the forum has a system that gathers very basic metrics on user behaviour and releases additional features to them as they demonstrate through positive engagement that they can be trusted.

It is there to help moderators and admins combat misuse etc. not abuse users rights. How better to deal with onboarding of unknown randoms from across the internet?

Moreover, the software is open source so you can read every line of code if you are concerned.

Bottom line: if you don’t trust the organisation running a site just don’t engage; especially if your unique pattern of likes is going to cause you to lose sleep …

I was not thinking that the users will start to directly write to it - although this might be great for testing and those who only have command-line access

There is no reason you can’t have multiple different UI’s to work with the same data for the benefit of users with different needs like your friend - that’s true of any discussion site. Discourse has an API, we could do a CLI tool

I am sure there are so many javascript-powered web interface programs we can use to allow writing messages from the web browsers.

The problem is how do you do access control to the repository, whether it is hosted. There will need to be some kind of server access component. (And you can’t just have open access, if there is that and it gets popular it will get spammed.)

I was imagining all that we need to is to convert JSON data coming from the front-end to structured data in Git.

JSON is structured data That’s what we store our data as - register/lists/gb/gb-coh.json at main · org-id/register · GitHub

Yet another possibility might be to have a client that has the cloned git repo in itself for superior text search capabilities and archiving and off-line capabilities!

True, and I’ve seen several issue trackers that work on that basis. But then your back to the tech barrier issue again.

It’s true the forum has a system that gathers very basic metrics on user behaviour

That also provides a very nice user feature where it keeps track of what I’ve read and shows me new stuff. “if you don’t trust the organisation running a site” - I would hope that us co-ops of all people could work on this trust problem

There are a few key issues I think that would be a challenge to crack with a git based system

• Notifications - how does someone get notified if someone replies to one of there posts?
• No access levels like Discourse has and no post-moderation - once someone has access they can change everything. And if you rollback spam/abuse, it will still be in git history. In Org-id we pre-moderate all submissions using GitHub pull requests but you probably don’t want that for a discussion site!
• No private chat messages - a feature we have used on this board

I think to take this project forwards, the first thing is to decide what level of tech knowledge it will require from it’s average engaged user (not a sys-admin). Because what is chosen there will go on to affect a lot of the system and design choices.

Honestly, I kinda feel that if the answer is “no special tech knowledge should be required” I suspect that by the time various components have been added to provide the features people expect your going to be back to something that’s just as complex to install as Discourse anyway [ the original problem statement ]

ps. This other statement about “forking” discussion sites - I’d think carefully about how that would be perceived by users before pushing that too heavily. People feel a personal ownership of things they write on discussion sites in a way they don’t about code they push. I know that technically once something is on the public internet, it can be copied, but that’s not how a lot of non technical people see things and you will get some odd reactions from people around that.

TL;DR I think I’m basically saying if you want this to be accessible to non-tech people, use Discourse or an alternative like Flarnum and if installation is still a problem lets work on that.