[This didn't send the first time, trying again] Re: Ryan Lane
That said, a number of the points are misguided. FlaggedRevs is a poor example to be used by either the foundation or the community. FlaggedRevs is a perfect example of how design by committee (where the committee is the community) utterly fails. FlaggedRevs should be used by both the foundation and the community as an example of a project that failed because the community designed something by committee and the foundation went along with those plans. We should never forget this lesson.
LiquidThreads was also originally community designed. The maintainer added every feature under the sun that the community requested, which lead it to become a bloated and difficult to maintain piece of software...
I most definitely agree - WONTFIXING a request that is a "bad idea" is just as important as fixing bugs, or implementing the good ideas. The art is of course in being able to determine what constitutes a "bad idea" and a "good idea". Its also important to keep in mind the community is full of many people with different conflicting goals, you can't blame them for requesting bad ideas or things they don't actually want. (Just to be 100% clear, I'm not saying that you (or anyone else) is blaming the community for that, just making the point)
I think the major problem with the Op-Ed is that he points the blame fully at the foundation when the blame is a combination of the foundation and the community. A major part of the problem is that the feedback from the community is almost always purely negative, and this Op-Ed is another example of that.
I would disagree that all feedback from the community is negative. I often get positive feedback from the community. Positive feedback in my experience seems to most often happen for small bug fix type changes, but I have seen it for larger changes as well. Then again I'm a volunteer, so which side of the us vs them fence I fall on seems to vary.
If a foundation project is solely receiving negative feedback, then perhaps that is the community trying to tell the foundation something.
The flip side of that is that the foundation communicates very poorly with the community. It's difficult to effectively communicate with the community because our communication tools suck. Our communication tools suck because it's very difficult to change them because it's difficult to get the community to agree with changes. Welcome to the vicious circle.
Quite frankly, the communication tools don't suck that much. It seems that no one really uses them. When was the last time a developer posted on the village pump asking for user feedback, or notifying users of a change, or otherwise talking to the users? We don't even have messages about upcoming deployments anymore [I guess that's because they're so frequent it might be considered spam?]. Sure there's the occasional message, but not much. Although jorm's op-ed didn't meet with a full 100% positive response, it did seem to be a good step in the right direction in terms of communication as far as I can tell from the comments it received.
One of the most important points here is about experimenting on users; and it should be taken seriously. I also believe strongly that, as the author suggests, we should treat editors as colleagues rather than customers.
This assumes that we aren't currently. I challenge the assumption. Can we get some evidence of that being the case? During the summer of research we worked directly with the community as colleagues. There's numerous other examples of this being the case.
I agree with MZ on this point. Furthermore it feels this problem has gotten worse with time. (On the flip side, there is an even more pronounced problem with the "community" treating us as service providers instead of colleagues - so it goes both ways)
-- -bawolff
I most definitely agree - WONTFIXING a request that is a "bad idea" is just as important as fixing bugs, or implementing the good ideas. The art is of course in being able to determine what constitutes a "bad idea" and a "good idea". Its also important to keep in mind the community is full of many people with different conflicting goals, you can't blame them for requesting bad ideas or things they don't actually want. (Just to be 100% clear, I'm not saying that you (or anyone else) is blaming the community for that, just making the point)
Indeed. The really difficult thing here is that every time a bad idea is WONTFIX'd it makes a community member feel that they are being ignored. Do it too many times and you have a lot of community members that feel this way. Don't do it enough and and the product suffers and then there's complaints about it being bloated, difficult to use, etc. It's difficult to win either way.
I think the major problem with the Op-Ed is that he points the blame fully at the foundation when the blame is a combination of the foundation and the community. A major part of the problem is that the feedback from the community is almost always purely negative, and this Op-Ed is another example of that.
I would disagree that all feedback from the community is negative. I often get positive feedback from the community. Positive feedback in my experience seems to most often happen for small bug fix type changes, but I have seen it for larger changes as well. Then again I'm a volunteer, so which side of the us vs them fence I fall on seems to vary.
Not all of the feedback is negative, but the majority is. This is actually fairly natural, though. All software has this problem. People tend to provide negative feedback far more often than positive feedback (think restaurants or seller reviews). What we need is more positive feedback telling us what's going right, rather than mostly hearing what's going wrong.
Positive feedback makes developers feel good. That may sound cheesy, but it's pretty demeaning when people give nothing but bad feedback. Positive feedback is far less likely to be ignored, and having a mix of positive and negative feedback makes it more likely that negative feedback won't get ignored due to numbness.
The flip side of that is that the foundation communicates very poorly with the community. It's difficult to effectively communicate with the community because our communication tools suck. Our communication tools suck because it's very difficult to change them because it's difficult to get the community to agree with changes. Welcome to the vicious circle.
Quite frankly, the communication tools don't suck that much. It seems that no one really uses them. When was the last time a developer posted on the village pump asking for user feedback, or notifying users of a change, or otherwise talking to the users? We don't even have messages about upcoming deployments anymore [I guess that's because they're so frequent it might be considered spam?]. Sure there's the occasional message, but not much. Although jorm's op-ed didn't meet with a full 100% positive response, it did seem to be a good step in the right direction in terms of communication as far as I can tell from the comments it received.
When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people.
We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner.
Thankfully, there's messaging and notification systems planned (and being built currently?) that will bring us part of the way there. Of course, MZ's Op-Ed harshly criticized the Op-Ed that discussed these systems, so it seems my point about this is kind of being proven ;).
One of the most important points here is about experimenting on users; and it should be taken seriously. I also believe strongly that, as the author suggests, we should treat editors as colleagues rather than customers.
This assumes that we aren't currently. I challenge the assumption. Can we get some evidence of that being the case? During the summer of research we worked directly with the community as colleagues. There's numerous other examples of this being the case.
I agree with MZ on this point. Furthermore it feels this problem has gotten worse with time. (On the flip side, there is an even more pronounced problem with the "community" treating us as service providers instead of colleagues - so it goes both ways)
Can you provide us with some examples? I'd like to see what's been happening so that I can avoid behaving similarly.
- Ryan
On 08/21/2012 06:29 PM, Ryan Lane wrote:
When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people.
We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner.
Just a quick note that the wikitech-ambassadors list https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is helping with this, and is going to be helping more -- I'll wait for Guillaume to lead the conversation about this, hopefully in the next 2 weeks.
2012/8/22 Sumana Harihareswara sumanah@wikimedia.org:
On 08/21/2012 06:29 PM, Ryan Lane wrote:
When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people.
We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner.
Just a quick note that the wikitech-ambassadors list https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is helping with this, and is going to be helping more -- I'll wait for Guillaume to lead the conversation about this, hopefully in the next 2 weeks.
You guys (and by that I mean "anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time"; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being "they're hundreds of them".
Well, let me tell you in plain English with no regard to political correctness: your excuse sucks.
It sucks mainly because automation was invented half a century ago - I've said this here before and I'm saying it again: it takes at the very most 2 days to write and test a script that can post a message to any number of pages. There could be thousands of projects, the effort from the poster would be the same.
It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2]. Those who know and want to use those alternative methods are discouraged by the scarce organization of the information.
Finally, it sucks because you basically expect people to look for your announcements and extract the information, when the whole idea of an announcement is to push the information from the originator to the receiver.
Sumana, my understanding of the "ambassador" concept is someone that takes the information from you and puts it on their home wiki(s). That's great, except it's unlikely you will find users from all the 200+ languages and even if you do, people quit, go on vacations etc., leading to information loss. An automated English message on the pump, translated on the spot would be much better.
Strainu
[1] text-producing projects are all language versions of Wikipedia, Wiktionary, Wikinews, Wikiquote, Wikibooks, Wikisource, Wikiversity and Wikispecies [2] The Romanian community recently decided to lock the Romanian-language mailing list because of the many people that were not aware what a ML is and were replying to every email asking not to be contacted again.
Well. duh.
A community will always give incremental features. This is the bazaar thing, where you can find everything, and is not a bad thing if the architecture support a bazaar (like a command line). When you are actually building a cathedral, you need a central entity that take all the input, and then proceed to do whatever he damn please.
PR as a role here, as you can tell people "we are taking all the input, studying it, and designing a system with the best ideas that make the more sense", actually reserving to you the role to design, not acting as a proxy for others.
http://theoatmeal.com/comics/design_hell
Bazaar is not always the solution.
On Thu, Aug 23, 2012 at 4:27 AM, Strainu strainu10@gmail.com wrote:
2012/8/22 Sumana Harihareswara sumanah@wikimedia.org:
On 08/21/2012 06:29 PM, Ryan Lane wrote:
When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people.
We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner.
Just a quick note that the wikitech-ambassadors list https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is helping with this, and is going to be helping more -- I'll wait for Guillaume to lead the conversation about this, hopefully in the next 2 weeks.
You guys (and by that I mean "anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time"; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being "they're hundreds of them".
Well, let me tell you in plain English with no regard to political correctness: your excuse sucks.
It sucks mainly because automation was invented half a century ago - I've said this here before and I'm saying it again: it takes at the very most 2 days to write and test a script that can post a message to any number of pages. There could be thousands of projects, the effort from the poster would be the same.
It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2].
Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so.
Those who know and want to use those alternative methods are discouraged by the scarce organization of the information.
Finally, it sucks because you basically expect people to look for your announcements and extract the information, when the whole idea of an announcement is to push the information from the originator to the receiver.
Sumana, my understanding of the "ambassador" concept is someone that takes the information from you and puts it on their home wiki(s). That's great, except it's unlikely you will find users from all the 200+ languages and even if you do, people quit, go on vacations etc., leading to information loss. An automated English message on the pump, translated on the spot would be much better.
Strainu
https://meta.wikimedia.org/wiki/Global_message_delivery (a bot operated by MZMcBride) can do exactly that.
It was used by the WMF engineering department to inform all of the projects about the IPv6 deployment in June (e.g. https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Juin_2012#Update_on_IP... ), and all non-Wikipedia projects about changes they needed to make to their main page in order for it being displayed properly on mobile devices (e.g. https://nl.wiktionary.org/wiki/WikiWoordenboek:De_Kroeg/archief19#Mobile_vie... )
This still relies on local Wikimedians translating that village pump message into their language, many are doing so with those announcements. And, as Ryan says, it is difficult to follow up on discussions in all those (ca. 600) village pumps, so those messages need to point back to a central venue for feedback.
And, this is obviously a channel which can only be used for announcements of some degree of importance. One might be tempted to create a separate "Wikitech ambassadors village pump" and have the bot post there. But the new broadcasting functionality that is being developed as part of the Echo and Flow projects will offer a much better solution (basically, as user on a Wikimedia project you will be able to subscribe to receive notifications from information channels across projects, and I'm sure that one of these channels could offer such tech updates).
2012/8/23 Tilman Bayer tbayer@wikimedia.org:
On Thu, Aug 23, 2012 at 4:27 AM, Strainu strainu10@gmail.com wrote:
2012/8/22 Sumana Harihareswara sumanah@wikimedia.org:
On 08/21/2012 06:29 PM, Ryan Lane wrote:
When I'm doing an ops change that is user facing I write a blog post and I post something to wikitech-l. I don't bother using village pump. There's a reason for that. There's a *lot* of village pumps. Hundreds. In different languages. I can't possibly handle that many different conversations in that many languages. Even if I only post to 2-3 of them, I still have to have the same conversation over and over again with different sets of people.
We need a global system for communication for things like this. Everyone should be a part of a single communication thread about changes. All posts in the thread should be able to be translated in a crowd-sourced manner.
Just a quick note that the wikitech-ambassadors list https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors is helping with this, and is going to be helping more -- I'll wait for Guillaume to lead the conversation about this, hopefully in the next 2 weeks.
You guys (and by that I mean "anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time"; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being "they're hundreds of them".
Well, let me tell you in plain English with no regard to political correctness: your excuse sucks.
It sucks mainly because automation was invented half a century ago - I've said this here before and I'm saying it again: it takes at the very most 2 days to write and test a script that can post a message to any number of pages. There could be thousands of projects, the effort from the poster would be the same.
It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2].
Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so.
Can you please point me to the location of the slides (if available)?
Those who know and want to use those alternative methods are discouraged by the scarce organization of the information.
Finally, it sucks because you basically expect people to look for your announcements and extract the information, when the whole idea of an announcement is to push the information from the originator to the receiver.
Sumana, my understanding of the "ambassador" concept is someone that takes the information from you and puts it on their home wiki(s). That's great, except it's unlikely you will find users from all the 200+ languages and even if you do, people quit, go on vacations etc., leading to information loss. An automated English message on the pump, translated on the spot would be much better.
Strainu
https://meta.wikimedia.org/wiki/Global_message_delivery (a bot operated by MZMcBride) can do exactly that.
Great! What's the holdup to using it more?
It was used by the WMF engineering department to inform all of the projects about the IPv6 deployment in June (e.g. https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Juin_2012#Update_on_IP... ), and all non-Wikipedia projects about changes they needed to make to their main page in order for it being displayed properly on mobile devices (e.g. https://nl.wiktionary.org/wiki/WikiWoordenboek:De_Kroeg/archief19#Mobile_vie... )
Hmmm, I remember the message, but I hadn't realized it was delivered by a bot at the time.
This still relies on local Wikimedians translating that village pump message into their language, many are doing so with those announcements. And, as Ryan says, it is difficult to follow up on discussions in all those (ca. 600) village pumps, so those messages need to point back to a central venue for feedback.
Agreed! Why not use a standard message for the feedback link, that could be translated once and reused?
And, this is obviously a channel which can only be used for announcements of some degree of importance. One might be tempted to create a separate "Wikitech ambassadors village pump" and have the bot post there.
I'm all in favor of "some importance" being less rather than more :) I don't think 10 or 15 messages per month would be considered too much, if the information is relevant to the project (i.e. don't send Wikisource-specific updates to Wikipedias)
But the new broadcasting functionality that is being developed as part of the Echo and Flow projects will offer a much better solution (basically, as user on a Wikimedia project you will be able to subscribe to receive notifications from information channels across projects, and I'm sure that one of these channels could offer such tech updates).
I don't know many details about those, but I do have 2 observations here. First, the fact that sometime in the future there will be a better solution should not stop us from implementing quicker fixes. Second, if there isn't a history of those somewhere easily reachable, people will quickly forget about notifications.
Strainu
On 23/08/12 16:02, Strainu wrote:
Second, if there isn't a history of those somewhere easily reachable, people will quickly forget about notifications.
Good point. If someone complains about an unknown new feature that wasn't announced and is directed to that channel, it should be possible to view previous announcements. Just like you can view old entries when subscribing to a new rss feed. (I don't know if that's already contemplated in the current plans)
Regards
On Thu, Aug 23, 2012 at 7:02 AM, Strainu strainu10@gmail.com wrote:
2012/8/23 Tilman Bayer tbayer@wikimedia.org:
On Thu, Aug 23, 2012 at 4:27 AM, Strainu strainu10@gmail.com wrote:
...
You guys (and by that I mean "anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time"; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being "they're hundreds of them".
...
It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2].
Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so.
Can you please point me to the location of the slides (if available)?
They're linked from the abstract: https://wikimania2012.wikimedia.org/wiki/Submissions/Movement_Broadcasting_-...
You guys (and by that I mean "anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time"; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being "they're hundreds of them".
Well, let me tell you in plain English with no regard to political correctness: your excuse sucks.
It's not an excuse. It's a problem to be solved. Let's discuss solutions, rather than laying blame.
It sucks mainly because automation was invented half a century ago - I've said this here before and I'm saying it again: it takes at the very most 2 days to write and test a script that can post a message to any number of pages. There could be thousands of projects, the effort from the poster would be the same.
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.
Also, when considering changes/features, it's important for each community to understand the needs of other communities as well. I think that's something that's completely ignored right now. Each community only cares around their own needs. Developers need to consider the needs of all of the communities, and in some cases need to balance the needs of communities against each other. It's best if all of the communities see the discussions and can be involved in a project as a whole, rather than only their portion of the discussion.
It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2]. Those who know and want to use those alternative methods are discouraged by the scarce organization of the information.
I don't think IRC or mailing lists are a good solution to the problem either. A global discussion system is. We need to consider the current situation, though. I think the ambassadors idea is a good interim solution, even though it's a massive game of telephone that's very likely to cause miscommunication and confusion:
https://meta.wikimedia.org/wiki/Talk:Tech/Ambassadors
This idea also doesn't let the communities be involved in the discussion with other communities.
Finally, it sucks because you basically expect people to look for your announcements and extract the information, when the whole idea of an announcement is to push the information from the originator to the receiver.
This is my problem with a bot that pushes a message out too. It's not two way communication. It's us sending a message out, then having no way to have a discussion.
Sumana, my understanding of the "ambassador" concept is someone that takes the information from you and puts it on their home wiki(s). That's great, except it's unlikely you will find users from all the 200+ languages and even if you do, people quit, go on vacations etc., leading to information loss. An automated English message on the pump, translated on the spot would be much better.
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.
- Ryan
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
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.
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
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.
I really feel that the blog is the best place for announcements like this. At least everyone can give feedback in the comments. It's a single communication location that has a relatively small amount of traffic that is very specifically focused on community matters.
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.
That's why I recommended the ambassador's route. It's the best interim solution proposed so far.
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.
I think the most important thing is to enable the communities to give feedback. There's a number of decent ways to notify the community of changes. The blog is likely the easiest route for that.
I think WMF->community communication isn't a good way to handle things, unless it's simply announcements. Many of the complaints raised can be linked to poor communication. We need two way communication.
- Ryan
On 23 August 2012 23:01, Ryan Lane rlane32@gmail.com wrote:
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.
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sory for the hassle.]"
:)
Michel
On 23/08/12 23:24, Michel Vuijlsteke wrote:
On 23 August 2012 23:01, Ryan Lane rlane32@gmail.com wrote:
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sory for the hassle.]"
:)
Michel
Yep. Just asking for the replies to be made at a dedicated page at meta seems a good solution. Much better than expecting everyone to follow the blog IMHO.
On 23 August 2012 22:24, Michel Vuijlsteke wikipedia@zog.org wrote:
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sory for the hassle.]"
+1
It's not two-way communication, but it sure beats zero-way communication. And is trivially upgradeable to two-way as the hypothesised community accretes.
- d.
Ryan Lane wrote:
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sorry for the hassle.]"
Seems reasonable. What's the procedure for doing this?
https://meta.wikimedia.org/wiki/Global_message_delivery
MZMcBride
On 23/08/12 23:24, Michel Vuijlsteke wrote:
On 23 August 2012 23:01, Ryan Lane rlane32@gmail.com wrote:
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sory for the hassle.]"
:)
Michel
Yep. Just asking for the replies to be made at a dedicated page at meta seems a good solution. Much better than expecting everyone to follow the blog IMHO.
On Thu, Aug 23, 2012 at 6:23 PM, Platonides Platonides@gmail.com wrote:
"Here's what we're proposing to do. [please note: this message was posted here by a bot. If you want to discuss this -- here's where it's at: ___. Sory for the hassle.]"
:)
Michel
Yep. Just asking for the replies to be made at a dedicated page at meta seems a good solution. Much better than expecting everyone to follow the blog IMHO.
This is exactly what I suggested in the other thread. Only instead of meta, I suggested mediawiki.org.
-Chad
2012/8/24 Ryan Lane rlane32@gmail.com:
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.
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
That's exactly what I'm trying to point out to you: the WMF telling people "here's what we're going to do" *on their home wiki* IS a huge improvement. Specifically, on ro.wp, instead of 4-5 people seeing these messages, 50+ people would see the messages on the Village Pump. That's a ten-fold increase in coverage with very little effort.
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.
I really feel that the blog is the best place for announcements like this.
How many people read the blog? How many people combined read the village pumps of the 10 biggest wikipedias?
There's a number of decent ways to notify the community of changes. The blog is likely the easiest route for that.
No, it isn't. The blog simply does not have enough reach and very likely will never have enough reach no matter what you do to make it popular. I could find tens of other reasons why it's not the best method, but I'll stick to just one: bog posts are at least 2-3 times longer than messages on village pumps. This means 3 times more time to translate.
I think the author of the original article said it best: "Agreement aside, we're seeing a disconnect right now between what the Foundation is spending resources on and the issues faced by the community." If we can't agree on the problem, we will have a very hard time finding solutions.
Strainu
I suppose, that a way could be a warning, into centralSiteNotice or into another similar space, optionally shown by a gadget/a Preferences set (default=disabled) into any page of any wiki. This warning should be brief, informative and focused on possible unespected results by software changes.
"Normal" users shuold not view anything; advanced users (sysops and layman programmers) will surely appreciate it a lot. I remember terrible headaches trying to fix unexpented, intriguing local bugs of out rich javascript set of local tools into it.source.
Alex brollo
2012/8/24 Strainu strainu10@gmail.com
2012/8/24 Ryan Lane rlane32@gmail.com:
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.
I haven't seen any small step solution that improves the situation, though. Unless there's two way communication then it's the WMF telling people "here's what we're going to do" without any way for them to give us proper feedback. We can't possibly host discussions with all of our communities, and it's really unfair to only select the biggest ones.
That's exactly what I'm trying to point out to you: the WMF telling people "here's what we're going to do" *on their home wiki* IS a huge improvement. Specifically, on ro.wp, instead of 4-5 people seeing these messages, 50+ people would see the messages on the Village Pump. That's a ten-fold increase in coverage with very little effort.
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.
I really feel that the blog is the best place for announcements like this.
How many people read the blog? How many people combined read the village pumps of the 10 biggest wikipedias?
There's a number of decent ways to notify the community of changes. The blog is likely the easiest route for that.
No, it isn't. The blog simply does not have enough reach and very likely will never have enough reach no matter what you do to make it popular. I could find tens of other reasons why it's not the best method, but I'll stick to just one: bog posts are at least 2-3 times longer than messages on village pumps. This means 3 times more time to translate.
I think the author of the original article said it best: "Agreement aside, we're seeing a disconnect right now between what the Foundation is spending resources on and the issues faced by the community." If we can't agree on the problem, we will have a very hard time finding solutions.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Aug 24, 2012 at 12:10 AM, Strainu strainu10@gmail.com wrote:
I think the author of the original article said it best: "Agreement aside, we're seeing a disconnect right now between what the Foundation is spending resources on and the issues faced by the community." If we can't agree on the problem, we will have a very hard time finding solutions.
Is this perceived "disconnect" explained anywhere with some detail? Even better if in the form of a compilation of ignored, non-prioritized or dismissed problems, projects, tasks, bugs, etc.
The WMF engineering plan is defined at http://www.mediawiki.org/wiki/Roadmap . It would be useful to know what is found to be missing, pointless or having the wrong priority. Not only to influence the plans of the WMF, but also to help current and potential contributors finding areas and tasks to contribute.
Also, is that the roadmap of the WMF team alone or a roadmap for the whole Wikimedia technical community, where anybody can get involved from occasional tester or feedback provider to maintainer and person in charge?
fwiw, my experience today trying to tell a community about a change we made:
we enabled WebFonts for my.wp:
https://gerrit.wikimedia.org/r/#/c/20727/1/wmf-config/InitialiseSettings.php
as requested in https://bugzilla.wikimedia.org/show_bug.cgi?id=34817
because it was assigned to me in Gerrit and looked like an easy change. So after merging and pushing out to cluster..
first i joined the IRC channel #wikipedia-my . It was empty.
Then i checked for a mailing list. It did not exist.
Then i went to the Wiki looking for the right place to drop a message.
I do not speak their language, actually i don't even have the right fonts installed:
http://my.wikipedia.org/wiki/Special:RecentChanges
I just tried Village_Pump, http://my.wikipedia.org/wiki/Wikipedia:Village_Pump but it appears empty afaict.
At this point i gave up and relied on the comment in Bugzilla being enough..
The last part took waaaay longer than the actual merge of course.
If i could have a matrix with links please, one for every project in every language with just the right places to leave comments on, i would more often do this...
On 24/08/12 23:02, Daniel Zahn wrote:
I do not speak their language, actually i don't even have the right fonts installed:
Filtering at Wikipedia namespace, http://my.wikipedia.org/w/index.php?namespace=4&title=Special%3ARecentCh... the local Village Pump is probably at: http://my.wikipedia.org/w/index.php?title=Wikipedia%3A%E1%80%9C%E1%80%80%E1%...
I just tried Village_Pump, http://my.wikipedia.org/wiki/Wikipedia:Village_Pump but it appears empty afaict.
At this point i gave up and relied on the comment in Bugzilla being enough..
The last part took waaaay longer than the actual merge of course.
If i could have a matrix with links please, one for every project in every language with just the right places to leave comments on, i would more often do this...
http://meta.wikimedia.org/wiki/International_names_for_Village_Pump http://meta.wikimedia.org/wiki/Distribution_list
(However, a Village Pump for mywiki is not listed there either)
BTW, we appreciated your kindness today in joining #wiktionary-es to notify the deployment of c21203 :)
On Fri, Aug 24, 2012 at 2:50 PM, Platonides Platonides@gmail.com wrote:
http://meta.wikimedia.org/wiki/International_names_for_Village_Pump http://meta.wikimedia.org/wiki/Distribution_list
Thanks, this is exactly what i was looking for. :)
Daniel Zahn wrote:
On Fri, Aug 24, 2012 at 2:50 PM, Platonides Platonides@gmail.com wrote:
http://meta.wikimedia.org/wiki/International_names_for_Village_Pump http://meta.wikimedia.org/wiki/Distribution_list
Thanks, this is exactly what i was looking for. :)
This is by no means necessary, but my experience with global message delivery has been that when you add a note about how you found that page ("I'm here because [[m:Distribution list]] said this was the appropriate place to post."), it dramatically helps in keeping the distribution list up-to-date. By giving people a pointer to your information source (and giving them a way to edit the list themselves, of course), you empower them, I've found. Just something to keep in mind.
Thanks, as always, for your work on these shell requests. Shell requests are notoriously perilous (poor Jens and the English Wikipedia...). Hopefully ^demon will make a proper configuration system in short order and this work can be given to the stewards. :-)
MZMcBride
Daniel, interesting experience. The case of requested configuration changes is rather simple though: they require consensus, so the place you were looking for is linked in comment 0. For the same reason, there's usually no need to tell the community, the reporter will take care of that.
Focused centralnotices, as proposed by Alex, are a definitely better system than spam on village pumps (which not everyone reads by the way).
Nemo
On Tue, Aug 21, 2012 at 3:29 PM, Ryan Lane rlane32@gmail.com wrote:
Indeed. The really difficult thing here is that every time a bad idea is WONTFIX'd it makes a community member feel that they are being ignored.
In fact users filing bugs feel really ignored when nobody reacts to their reports. Getting a WONTFIX means that someone cared enough in a context where there is no lack of issues to deal with. Making this point clear to anybody getting a WONTFIX is a first step toward a happy ending.
Do it too many times and you have a lot of community members that feel this way. Don't do it enough and and the product suffers and then there's complaints about it being bloated, difficult to use, etc. It's difficult to win either way.
Most people filing bugs do understand this, specially after someone explains this point to them once. They usually understand it even better when such explanation doesn't come necessarily from the powerful professional maintainer but from another peer with just a little more experience.
I think the major problem with the Op-Ed is that he points the blame fully at the foundation when the blame is a combination of the foundation and the community. A major part of the problem is that the feedback from the community is almost always purely negative, and this Op-Ed is another example of that.
The expression "the foundation and the community" is at the core of the problem. If there is one problem and two sides then it's too easy for any independent contributor to be in a different page than a WMF employee. In practice what everybody wants is one community and a myriad people with different levels and tonalities of engagement, expertise and focus.
Engaged and skillful developers not working for the WMF are as important for this biosphere as motivated ambassadors willing to test and follow new developments. In many or most cases they are in a better position to tell other contributors why something deserves a WONTFIX or more constructive criticism, and get a positive response. Of course this only works when core developers are sharing, discussing and working together at least with those most engaged contributors. And when those contributors feel informed and entitled to answer more junior (or more upset) community members.
In the context of the http://maemo.org community we have got plenty of chances to fall into non-productive fights between @nokia.com developers and upset users. Having some layers of empowered community members in between (including a Bugsquad team entirely made of volunteers [1]) helped a lot to build a common understanding and more constructive discussions.
[1] http://wiki.maemo.org/Bugsquad
On Tue, Aug 21, 2012 at 7:29 PM, Ryan Lane rlane32@gmail.com wrote:
I most definitely agree - WONTFIXING a request that is a "bad idea" is just as important as fixing bugs, or implementing the good ideas. The art is of course in being able to determine what constitutes a "bad idea" and a "good idea". Its also important to keep in mind the community is full of many people with different conflicting goals, you can't blame them for requesting bad ideas or things they don't actually want. (Just to be 100% clear, I'm not saying that you (or anyone else) is blaming the community for that, just making the point)
Indeed. The really difficult thing here is that every time a bad idea is WONTFIX'd it makes a community member feel that they are being ignored. Do it too many times and you have a lot of community members that feel this way. Don't do it enough and and the product suffers and then there's complaints about it being bloated, difficult to use, etc. It's difficult to win either way.
While that's certainly true some of the time, if a good reason is provided for wontfixing, there are also many users who will accept that not all bugs can be fixed, and will be happy someone took the time to look into the issue. (These types of users tend also to be the quiet type, so we hear about them less)
[..]
One of the most important points here is about experimenting on users; and it should be taken seriously. I also believe strongly that, as the author suggests, we should treat editors as colleagues rather than customers.
This assumes that we aren't currently. I challenge the assumption. Can we get some evidence of that being the case? During the summer of research we worked directly with the community as colleagues. There's numerous other examples of this being the case.
I agree with MZ on this point. Furthermore it feels this problem has gotten worse with time. (On the flip side, there is an even more pronounced problem with the "community" treating us as service providers instead of colleagues - so it goes both ways)
Can you provide us with some examples? I'd like to see what's been happening so that I can avoid behaving similarly.
Honestly, I think its easier to see there is a problem when you look at how community treats developers, rather then developers treat the community. I think individual developers by in large do a good job here, it is more in the planning stages (and possibly deployment) where things go wrong.
When you mention negativity, I think that is a symptom of the "service provider mentality" problem. After all, your internet service provider would really have to go above and beyond the call of duty before you called them up and told them what a good job they did. While I don't think the feedback is all negative, I do notice that sometimes it seems the third party re-users of MediaWiki tend to be more understanding and polite than the Wikimedia users.
I'm not a Wikipedian, nor have I ever been. I follow enwikipedia politics only so much as what happens to make the Signpost. So the following may be misguided. However, with that said I think a strong contributing factor is the way that foundation projects targeting enwiki are just done, without first asking the community for permission first. From what I understand moodbar, article feedback, etc were all deployed without gathering consensus first. Gathering consensus helps ensure that the individual wiki communities feel like they own their communities, that they are in control. From this I believe would result in a more "colleague" relationship with the community as opposed to a service provider relationship. Having consensus for doing the enwiki targeted projects would also help give the foundation legitimacy in what it does.
That said, I'm not advocating getting consensus for every little change. Security and performance concerns always have and always will be the realm of the developers. Similarly I don't believe new features in mediawiki that are on by default need consensus - generally such features are non-controversial, and there's a lot of them. If something gets enabled for everyone, we're usually pretty confident that people will like it, and that it doesn't need much explaining. Similarly extensions, or config changes that are going to all wikis do deserve some sort of notice, but again for the same reason as new MW features, I don't think consensus in general needs to be sought (There are of course exceptions I'm sure. And individual communities should perhaps be able to reject such deployments, but the onus should be on the community to reject). However, when one starts focusing on a single wiki, I really believe one should get permission from that wiki first.
That of course has a downside - What if foundation hires X people to develop feature, and enwikipedia rejects it. After all features aren't free, and that would represent a wasted investment. I think such an "employees need consensus" policy would have the side effect of forcing employees to really make sure that what they are doing vibes with what the community wants.
-- -bawolff
p.s. Since I don't follow enwikipedia, or developments targeted there very closely, this email will be very embarrassing if Moodbar et al folks actually did gather consensus before deployment
About colleagues vs. customers: I don't think it can be considered a misunderstanding by the community, it's largely due to what the WMF really wants. The WMF, as the article puts it, doesn't [necessarily] want to work better with the existing community (-> colleagues) by providing what's felt useful /for them/ to get things done; instead, it largely assumes that what's disliked or even plainly harmful now is actually good, if it can attract a new demographic of users which will like it (-> new customers). And more: changing the demographic by ignoring the existing one is sometimes the very aim of changes; community is assumed broken (it scares people off), consensus even more so (we can't get anything decided, we need "leaders" – surely not pre-emptive consensus), nobody is indispensable (we have a big turnover, we only need to improve "_new_ editors retention"). And yes, this sometimes borders social experiments (eugenetics? :-) ). I'm not going to prove all this*; it's nasty to "the community", but there's also a lot of truth in it and all in good faith.
Nemo
(*) I could quote individual WMF developers or officers but that would be tough and unnecessary: it's the official strategy, just seen from a different perspective (by stretching it a bit perhaps).
The idea that we are trying to attract new users at the detriment of the existing ones is putting words in our mouths, but I do know what you mean. The good news is that many of us are very conscious about these issues.
Here are some excerpts, for instance from the VisualEditor software design document[1]:
- "Visual editing should first improve the usability of the most common tasks. Less frequent tasks may still be performed using a source code editing mode." - "Visual editing should enhance, not degrade, the ability to inspect what was changed between revisions." - "At the very least, a visual editor should not make more work for administrators and editors who are reviewing edits done by others."
VisualEditor isn't alone in these beliefs, but I realize also that they are not held widely (yet) enough either.
[1] http://www.mediawiki.org/wiki/VisualEditor/Software_design#Objectives
- Trevor
On Wed, Aug 22, 2012 at 3:11 PM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
About colleagues vs. customers: I don't think it can be considered a misunderstanding by the community, it's largely due to what the WMF really wants. The WMF, as the article puts it, doesn't [necessarily] want to work better with the existing community (-> colleagues) by providing what's felt useful /for them/ to get things done; instead, it largely assumes that what's disliked or even plainly harmful now is actually good, if it can attract a new demographic of users which will like it (-> new customers). And more: changing the demographic by ignoring the existing one is sometimes the very aim of changes; community is assumed broken (it scares people off), consensus even more so (we can't get anything decided, we need "leaders" – surely not pre-emptive consensus), nobody is indispensable (we have a big turnover, we only need to improve "_new_ editors retention"). And yes, this sometimes borders social experiments (eugenetics? :-) ). I'm not going to prove all this*; it's nasty to "the community", but there's also a lot of truth in it and all in good faith.
Nemo
(*) I could quote individual WMF developers or officers but that would be tough and unnecessary: it's the official strategy, just seen from a different perspective (by stretching it a bit perhaps).
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 2012-08-21 at 15:29 -0700, Ryan Lane wrote:
The really difficult thing here is that every time a bad idea is WONTFIX'd it makes a community member feel that they are being ignored. Do it too many times and you have a lot of community members that feel this way.
My naïve hope is that you can make people feel slightly better by elaborating on decisions (which might take a minute of the developers' or triagers' time though), even on a rather generic level.
As an example, when I close "exotic" enhancement requests as WONTFIX in projects I'm active in, I try to add a comment in the style of "Thanks for sharing your idea. Unfortunately there are currently no plans to provide this in the native application, as your idea likely would only be useful to a smaller amount of users. However it could become an extension which could be provided by third party developers, but not by the core developers themselves. Hence closing as WONTFIX for the native application."
My two cents, andre
On 21/08/12 23:50, bawolff wrote:
LiquidThreads was also originally community designed. The maintainer added every feature under the sun that the community requested, which lead it to become a bloated and difficult to maintain piece of software...
I most definitely agree - WONTFIXING a request that is a "bad idea" is just as important as fixing bugs, or implementing the good ideas. The art is of course in being able to determine what constitutes a "bad idea" and a "good idea". Its also important to keep in mind the community is full of many people with different conflicting goals, you can't blame them for requesting bad ideas or things they don't actually want. (Just to be 100% clear, I'm not saying that you (or anyone else) is blaming the community for that, just making the point)
This is an important point. Pretty much everyone here can "accept" a bug (by coding the feature), but when to "reject" it? I'm sure there's a number of "bad-ideas" bugs which nobody closed. Because "who am I to decide on this?", "this might be implemented in an extension if it's really needed...", etc.
I don't think it's a problem for "clearly wrong bad ideas", IMHO they are properly closed (even then, I prefer that several people chime in saying so before closing, showing that there is consensus in not doing it). But there's a gray area inbetween. Some even had commits or got implemented.
(LQT had a lead developer, so it would have been much easier, but I wanted to center into the general case)
wikitech-l@lists.wikimedia.org