Communication Channels


First axis : Tech people and non Tech people.

This first axis is about what kind of people are concerned with the communication, not about the subject itself.
We should make a difference between tech people who will easily adopt a new tool if it has advantages nad non tech people who will more likely stick to what they know.

At the same time some subjects only concerns tech people and those subject can be communicated via specialized tools. Subjects concerning at least some non tech people should be communicated in a way that encourages them to participate.

Second axis : Time

Let's make a difference between :
- what was communicated in the past and should be available now so that we can invest on it.
- what is currently on stage and should encourage people to participate
- what is concerning the future of chamilo and ideas we do not want to lose

Examples :

This gives us 6 kinds of subjects :

Communicated in the past for tech people : "Why the hell is that output beffering set to off ?", "How to write a new application"
Communicated in the past for non tech people : "How to change the language of your platform", "Where does the name Chamilo come from ?"

Communicated in the present for tech people : "What changes are being currently made to the package I depend on ?"
Communicated in the present for non tech people : "Dear member of chamilo, the new release has a lot of new functionality, please upgrade", "Help me I don't know how to install chamilo on my free webhost"

Communicated concerning the future for tech people : "We will port Chamilo to Ruby on Rails, what do you think ?", "What about using Zend Framework ?"
Communicated concerning the future for non tech people : "I would like to have a mobile version of chamilo", "Will it be possible to charge students via paypal with chamilo ?"


Currently we have mainly 5 channels of communication :
- Support website (Redmine ticket system) : great for tech people, accessible for non tech people. great for present, good for future, bad for past
- Support website forum
- Support website wiki
- IRC : great for tech and non tech people in the present when someone can help. awful for past or future. Most people are usually not on IRC at the same time
- Mailing-list : great for being noticed. good for quick answer-reply. bad for past and hard for future. There are also a lot of different mailinglist used, what complicates things. (core-dev, dev, security, webservices, documentation, translation ...) (the mailinglists are hard to find)
- Non tech forum on : currently crap because it lacks the main features of a good forum but could be good for discussion about future and announcements. Not a good system for notification unless coupled with rss/atom
- dev meeting : awesome for future BUT not very open to international community. There will virtually always be somone missing.
- Google docs

The problems we have

Currently the main problem we have are :
- the lack of a central room of discussion for non tech people (not only non-tech people but interaction/exchange of ideas between non-tech people and developers)
- the difficulty to follow all the discussions concerning a subset of the packages
- the bad feeling we have when we are noticed of something after it is done (especially if it has impact on our work)
- no overview of who is working on what and what is planned for the future

The proposals

- Use a mailinglist
- Use a chamilo course
- Use a (phpBB) forum for both technical and non technical users
- Keep the current working method: a combination of several tools (redmine for issues, forum / irc for discussions, mailinglist for notifications of important changes)
- Use the chamilo platform as a collaboration tool: courses/workspaces for the different packages or clusters of packages (where you can have a forum and post documents for a specific topic, make announcements, ... ). Everything posted can also be automatically mailed to the mailinglist for people who don't want to check the platform and everybody has an overview of the changes and new information on the packages they are interested in on their homepage) keep redmine as bugtracker (you can always link to important issues from forum and vv, use rssfeed?, ...). Keep the website as a commercial tool. In the future, when anonymous access is possible, the two can be integrated.
- if important things are dicussed on IRC (e.g. during the weekly dev meetings) the log needs to be post somewhere (where it is easy to find)

Next to clear procedures on wich tools to use for what, we need also a mentality change where we move away from one-to-one communication on private channels. And we need to be clear on who will be answering what. For the moment we have a lot of channels but enough examples of questions that are not answered.

The Postgresql Experience

According to this post : the postgresql community has been recently facing a similar problem when trying too choose between ML and Forums ... and they choose both (but withtout requiring people to follow both places)

The idea (for those who do not want to read ) is to have a forum presenting the messages and follow-up of the ML and if someone answer a mail in the ML, the forum automatically creates a reply to the topic. The other way around, when somebody post an answer to a topic, the ML receives an email.

We could use a subforum named "Mailing List" to do this with special rights to that sub forum (no editing, no removing, no moving, no bbcode, etc )

Discussion in ML

Here are some bits of the discussion found on postgresql ML (there is a lot more and some ideas have been refuses or drastically changed, plz read the postgresql ML for more info) :

I didn't know phpBB supported bidirectional mailing list support.

It doesn't. I have a subscription address that is piped into a PHP script that uses the phpBB3 APIs to do all you see.

A few points though. I think we'd need to disable smileys, bbcode, any form of rich text formatting, flash or embedded images. In short, plain text only, which is the policy on the mailing list. I think it would be more useful if each forum directly corresponded to a mailing list too. What I mean is that if there was a forum on the site which didn't match to a mailing list, only forum users could use it.

If someone were to send a reply on the forum all the bbcode would be stripped before emailing it to the mailing list to keep the mailing list "pure." Is that what you mean?

Also, if someone registers on the forum, do they get a major domo registration email? And if so, would this be set to receive no emails upon registration? I'm not clear as to how this step would work because, at the moment, mailing list subscribers have to subscribe on a list-by-list basis. So registration to the forum site wouldn't necessarily mean they'd want to join any particular mailing list. Similarly, could they unregister easily? And anyone who attempts to post to a mailing list they aren't subscribed to requires moderation, so we don't wish to exacerbate this.

No they are not registered on the mailing list, but they actually don't need to be, let me explain:
1. John Smith has a postgres related question and finds the forums, he signs up and posts his question.
2. His post is then emailed to the mailing list under a generic registered address like "mailinglist(at)postgresql(dot)com(dot)au"
3. Bob House reads Johns question on the mailing list and simply sends an email reply.
4. The email reply is piped into the forum and matches the topic based on the email subject (thats how it currently does it.)
5. John gets an email from phpBB along the lines of "Bob House has replied to your post, click here" (all forums do this) he reads the response and is happy.

This is the best balance of no-fuss and expert response, keeping in mind that:
  • John can still sign up to the mailing list like anyone else if he wants to.
  • All of John's forums communications are in the postgres mailing list archive now.

Implementation idea

  • Contacting the guys from postgresql * Nabble * (very promising, active for more than 5 years, currently in alpha)

Updated by Anonymous over 11 years ago ยท 7 revisions