FourthWorld wrote:
I think that depends on how we define "technical Q&A".
Specifically, well bounded questions about whether certain things can be done and how to do them in LiveCode. StackOverflow has a pretty good guideline about the sort of question that is allowed and if it's allowed there it should probably be there rather than on a forum or mailing list - the efforts of community members applied in this way have much more long term value, because they can be rated by other members (voted up/down) and accepted as working by the original asker of the question. They can also be edited by others (with sufficient trust) to improve accuracy or referencing - it makes it into much more of a collaboratively created knowledge base than one-off questions and answers.
For more open questions, or real beginner "how do I go about creating a 2D game" type of questions which invite discussion, a forum or mailing list is the right place to go.
ForthWorld wrote:
I don't know why the Symbian staff soured on having multiple venues; seems unnecessarily self-limiting.
They didn't, they rejected the idea of telling people to go to a 3rd party site. They were perfectly happy for people to use StackOverflow, mailing lists, our forums, OEM forums, fan forums, meetups etc. The major problem was having too many fragmented communication channels for the size of the community, which was much bigger than the current LiveCode community.
ForthWorld wrote:
In contrast, Canonical's community management of Ubuntu actively encourages people to provide support in whatever venues they like, and RunRev seems the same. I'm sure they welcome Stack Overflow along with other similar venues for broadening the range of options for helping folks get the most out of LiveCode.
I said fragmented comms is a luxury for large and highly successful projects, this is a good example. The trap to avoid here is mimicking the strategy of someone successful when they've achieved a certain scale rather than what they did to get there. Jono Bacon of Canonical wrote a great book on community management and it recommends focussing comms channels. Helping people out wherever they happen to prefer to hang out should never be discouraged but also pointing them towards a common place where they can find a lot more people willing to help should only improve the quality of support they get.
This is the critical part - if lots of new users are coming to the platform because it has gone open source, where do they go for help? Should they just be left to find one of the many support channels for themselves, or should RunRev (and community members) guide them? If guidance is provided, what should that be? In general people want to ask questions wherever they're most likely to get a quality answer quickly. Right now, going on activity I'd say that's the mailing list but a horde of newbies coming to the mailing list would almost certainly kill it with too much traffic and repeat questions (because it's tough to search or read the archive and mailing lists become near impossible to follow past a certain post volume).
One area where RunRev will need to provide guidance on is how they manage contributors as distinct from users.
This is actually one of the biggest challenges. Where do new contributors come from if not the users? It's essential to keep contribution discussion (and it's more likely to be discussion than StackOverflow style Q&A) separate from user discussion to avoid noise for both but how do you tie them together enough such that it's not too big a jump to go from user to contributor. You're right, the RunRev team seem pretty clued up on this topic and I'm sure they'll have a plan.
I see no harm in letting people have what they want. The mistake Symbian's managment made was discouraging options; in contrast, RunRev encourages people to participate in any support venues they like.
The potential harm is a relatively small community is fragmented and the quality of help people get is reduced. Also, if you have poorly suited comms tools when a lot of new users show up then the level of repeat questions and moderation required wastes the time of the experienced few - they could be spending time answering new questions and instead they're pointing people to previous answers and moving posts to the right boards.
In fact, in addition to these forums and the user-livecode list, we've also had new communities spring up on Google Plus and Facebook as well, and regional user groups have begun to pop up in various places like the one we hold each month in SoCal. Adding Stack Overflow and other such venue to the mix only broadens the options available for helping folks get the most out of LiveCode, and I would imagine RunRev would welcome that.
I'm really not advocating the removal of any support channels, just focussing specific types of support in a places where individual contributors effort will provide the widest benefit.
Simon wrote:The tag thing was something you mentioned elsewhere, something about 1500 votes?
StackOverflow users get reputation points for asking and answering questions, editing and voting on answers. There is currently no "LiveCode" tag on StackOverflow. Adding a new tag to the site is a bit like opening a new board and requires a certain level of reputation (=moderation privilege) - specifically 1500. I've not been a major StackOverflow answerer (I use it all the time to find answers) because the platforms I've been most experienced with have had their own forums, so I'm still over 1000 short of that level. The most active users gain more than 1500 reputation in a week though, so it's not a significant barrier.
@Monte - I'm impressed with your taking the idea and running with it so quickly.
I haven't learnt enough about LiveCode to confidently answer many questions yet but I'll join in as soon as I get there. I also think it's worth trying to persuade other LiveCode experts to join the effort and also RunRev to "officially" point there as a support channel, at least as officially as they do with these forums, when there are a few more people on board with the idea of answering there.