2012/8/23 Ryan Lane rlane32@gmail.com:
Writing a bot that handles two way communication is not a simple problem. Especially when you consider that talk pages can be formatted in any way imaginable. Having an automated bot to post something is perfectly fine if we want to talk /at/ the communities, but it's not a solution if we want to talk /with/ the communities.
Your idea is a great one, except... I was going to say "you can't see the forest for the trees", but actually it's the other way around. I think you're too focused on the big picture (communicating with the community) to see that smaller steps can help a great deal.
Sure, it's great to have lots of peopled involved in the discussion leading to a big change, but it's not bad at all to have some people involved in the decision making, but _everybody_ in the loop about the decision taken. Think of it as law-making: some people gather, discuss and take a decision, which is then made public for all interested parties before it comes into force.
As I said to Tilman: don't ignore or postpone small fixes just because you're waiting for a great new version sometime in the future.
If we can't crowdsource this, then it's never going to happen. This is how our community scales. We have less people on the entire Wikimedia staff than we have projects (by a very large number). We can't possibly hire enough people to properly cover discussions in every single project.
This makes sense and is probably the right solution for the Community->WMF channel. However, the 2 directions need not be perfectly symmetrical. It is far more important for the WMF->Community channel to be reliable, timely and deliver the message as close to the destination as possible. There are many reasons for this, the most important one being that the WMF takes decisions that affect the community, but not the other way around.
Strainu