2013/10/14 Vincent Massol <[email protected]>
On Oct 14, 2013, at 9:53 PM, Jeremie BOUSQUET <[email protected]> wrote:
Le 14 oct. 2013 20:58, "Vincent Massol" <[email protected]> a écrit :
On Oct 14, 2013, at 6:56 PM, Eduard Moraru <[email protected]>
wrote:
On Mon, Oct 14, 2013 at 6:53 PM, Vincent Massol <[email protected]>
wrote:
On Oct 10, 2013, at 2:55 PM, Hamster <[email protected]> wrote:
vmassol wrote > Can you explain what you mean exactly? :)
Why don't "we" open a "XWiki Site" and start posting all our
questions
there?
Nothing ventured, nothing gained…
Because as it's mentioned, it's not easy. People will vote in Area51 and only the most requested will be open.
Yes, but sleeping in a burrow does not improve our chances of getting more visibility of the project, does it? Neither does creating our own new underground establishment. If we plan on moving or doing anything in this direction, maybe the "forest" is where the action happens :)
I see 3 main reasons to move away from a mailing list for the users list:
1) Make it extra easy for users to post a question without being registered Posting without being registered could be an issue, unless you require an email address, a captcha or both. It's then already more complex than sending a (crappy) email from your phone ;)
Most people find it too complex to register to a mailing list. Sending the email is ok once you're registered.
What I mean is indeed to make it easy for a first time user to find how to post a question. And yes the registration could be done seamlessly by providing an email address/name and once the user has clicked submit send him an email that he needs to reply to to validate his question for example (to ensure the email is valid). Something seamless like this.
I don't remember having done something very different to register to mailing-lists ... Except that mailman UI is a bit old-school, it's relatively simple. What people maybe find more complex, is that they have to register to another web page, than the one of the list they're interested in.
2) Provide visibility for those who answer questions (i.e. earn points and rankings) and as a consequence especially who are the experts That is tough, not the implementation, but the way to make it meaningful and not frustrating... Some answers can be complex and require time to find, though in general they have the same weight than the "copy paste link" answer ( very good also, but less demanding). I find that systems that allow identifying the "best answer" are more useful.
This is what stackoverflow does (and several other forums I've seen) and it seems to work quite well. Finding questions/answers is a different topic from what I meant here. Search usually works quite well to find existing topics IMO.
I was not talking about search, I was talking about the fact that it may require time to "find the correct answer" for those who answer questions (not because of search tool, but because it can be complex, require some deep knowledge on some sujects, etc). Ranking and points can be fun and provide some visibility, it could also be seen as some incitement to judge only on "quantity" :) You can for example build great statistics by always answering to questions for which you now a wiki page has the answer, far better statistics than someone who focuses on the others (the ones that need you to explain, and why not create the missing documentation). I do not say that it doesn't work, but to me the "risks" are the same as with any rating/popularity system, it can be frustrating for individuals, depending on how it's implemented and most of all used.
3) Allow closing topics to know which one do not have a satisfactory answer so that people who wish to help know which threads they can help on Not so easy either, who's in charge ? (If the requester forgot to put "solved" in subject)... That could be large extra-work, to have this be meaningful.
This is used on a lots of forum apps that exist. The reporter should of course be allowed to say whether his question has been answered to. And the system could also allow committers/some contributors to close topics too by providing a reason to close it.
All those are great, but based on my (intranet and limited) experience, nothing is more easy than sending a mail.
Yes, sending an email is easy. Registering to a mailing list isn't. And searching for message isn't either since you need to find an archiving tool.
Sure but you don't register each time ... What I can say is that XWiki is particularly fine to search for emails from my contrib mail archive :) (thanks to livetable filtering + lucene/solr search).
Also even though sending an email is easy, replying to an existing thread isn't if you don't have the email locally to reply to. So if you're just a occasional user you don't want to receive all emails from everyone but you'd like to be able to reply to a thread from time to time. And you can't do that on a list.
Well, on a list by itself of course, but that's why stuff like nabble, markmail, etc, do exist, and they are fine for that. I don't know the conditions / constraints of these tools, but I wouldn't imagine contributing to a mailing-list that would not be backed by an archive. And that's why I created one in xwiki in first place ;-)
And the added-value of those features is useless if people do not use them, which you cannot force them to do.
(Ot : closing topics requires some thinking, many different possibilities exist) Forums are close and great, but somehow they are different and usually require more moderation activity. There are also a bunch of nearly empty unmoderated zombie forums on internet…
Why would they require more moderation than a mailing list? They require maintenance if you wish to do better than a mailing list simply because mailing lists don't offer those features! But if you do want these features then there's no choice anyway since ML don't offer them.
You said it above, registering to a list isn't so easy, and not so user-friendly. It naturally attracts mainly people REALLY interested in the topic (and when there is no other way to ask a question). A forum would certainly attract more people - that's the objective after all. So it will require more moderation... Because you have less "filtering" at the entry gate. I'm not saying it's bad, just that it might have to be taken into account for things to work smoothly.
"There are also a bunch of nearly empty unmoderated zombie forums on internet"… the same thing can be said for a lot of mailing lists ;)
Right :)
That being said I struggled against mailing lists at my office, seeing them as the most archaic way of sharing. But at the same time, they proved to work far better than the more sophisticated solutions... I can't really compare, different targets.
As a dev, I also like mailing list which is why in the previous thread on this topic, I mentioned that the best of both world would be a forum app that bridges with mailing list, if you can solve the issue of seamlessly sending to the list on behalf of the user (not so easy as proved by Nabble which is too complex and a lot of users don't understand why their nabble topics don't make it to the xwiki lists and why they don't get answers)...
The "problem" of nabble and such is that they act as mailing-list frontend/archive that do not "own" any mailing-list. So users need to register to the real mailing-list anyway, then register themselves to nabble. That's exactly the same issue I will have with the mail archive in xwiki, even if I implement the "reply" and registration in the most seamless fashion possible (and there are chances, to be honest, that it won't be better than nabble). Because to reply you need the email address of the user (the one of the mailing-list, that may not be the same than the one you used to register in xwiki), and in the worst case (corporate environment) you may need a password in order to post emails through outgoing SMTP server (I mean, you might need your email account password in order to send emails from your own account on the SMTP you target). Storing this "external" password in xwiki or somewhere could be considered a security hole, so you might want to ask for it interactively each time a user wants to post a reply ... Of course these (email address, password) could be stored in the user profile or any other place, but it's still like a "second" registration step. And if you used different email addresses to register to different mailing-lists ... A forum doesn't have this problem, it completely owns everything it manages. It might only need some outgoing server configuration if it manages some email notification, and use email to secure registration step once for all (as most applications do anyway). I don't see how to make this email archive / forum bridge more simple, except maybe putting some SSO thing in place so if you authenticate to xwiki, you're authenticated to your email server. But that, is not very simple to do, and you cannot count on it as a pre-requisite anyway. What could be interesting is to find a way to completely forbid a user to post a reply from the "forum/archive" UI, unless he IS registered to the mailing-list. I'm not sure it's feasible - I must admit I have no idea. But it would avoid the problem you listed. Maybe mailman implements some commands you could send by email (or other api), to check if a user is registered to a specific mailing-list. You only would define the mailing-list manager account once in the preferences. Mmm sorry I realize that I'm moving away from your original topic ... :)
IMO those are our main 3 use cases.
Then we can evaluate the options we have to fill those use cases:
A) Try to get a site on area51 B) Install a stackoverflow clone in our infrastructure (see http://meta.stackoverflow.com/questions/2267/stack-overflow-clones) C) Develop a solution based on XWiki D) Other
I don't like A) because the chances to get it is about 0.1% and even more important I strongly dislike the way they manage stackoverflow (I'm not able to provide answers to questions because at one point in the past I answered a question by sending a user to a URL that gave the exact answer to his question)… As a result this prevented me about 4-5 times from answering a question for which I knew the answer… There's also the question of not owning our own data.
C) is a lot of work but it could be possible because Jeremie is working on a use case relatively close to it. And the "eat our dog food" is quite nice and we can learn stuff in the process. XWiki fits nicely with the use case of a "Q&A site" IMO. It should be relatively easy to start with a simple QA app and progressively enhance it.
For me qa is different, and better be faq (possibly extracted from the list though it's difficult). For sure, if you add "reply" to the archive I work on, you're not far from a forum app. And you can "build" on it by adding nice features. But one should not forget that it's built on a mailing-list, and people only dealing with the "raw" emails should not get lost in the process (thinking here of all non standard formatting tags some UIs like to add in emails text... If you want formatting in emails, do HTML....).
Your email client is a good example of a faulty email client that wrongly replies to mails ;) (your answers are mixed with the text it's replying to)...
That was gmail for android ;-) In fact I just discovered that it expects empty line between new content and previous history, or else new content is assumed to be history. Also, it cuts the lines to some length but does not add needed "> " for these new lines ... I hope gmail web app does better (I'm using it currently) :)
For the mail archive, I have more time to work on it these days... But remaining work is quite big.
Cool!
Food for thoughts:
http://stackoverflow.com/questions/1576935/open-source-alternative-to-uservo...
I was wondering if xwiki ratings plugin could do the trick ...
Since one of XWiki's main use case is knowledge base, I still find it logical that we could expand on that to create a Q&A solution. Whether the store is in a mailing list system, inside XWiki's DB itself or even in JIRA is an open question...
On a related topic (old now), see http://dev.xwiki.org/xwiki/bin/view/Design/HelpDesk
Thanks -Vincent
The "easiest" is probably B). For fun I'm trying http://bitnami.com/stack/osqa locally.
Thanks -Vincent
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users