Hey,
Not sure if anybody has seen this article yet: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-08-20/Op-ed
Thought it was interesting and possibly worth discussion.
--Tyler Romeo
On Tuesday, August 21, 2012 at 10:10 AM, Tyler Romeo wrote:
Hey,
Not sure if anybody has seen this article yet: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-08-20/Op-ed
Thought it was interesting and possibly worth discussion.
I responded on the talk page[1], taking credit for the elephants quote, apologizing for it, and providing a bit of context. I think the context changes the meaning and tone of what I wrote considerably. It sucks that it is used in this way -- to malign the efforts of my colleagues. Sorry.
[1]: http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AWikipedia_Signpos...
-- Ori Livneh ori@wikimedia.org
That was unfortunate - I've been ridiculed (by Max) for things I've said before as well, I feel your pain Ori.
That said however, I generally agree with this piece. I have more faith than the author seems to have that we are on the right track to doing better work in the future, but the points made are pretty valid. It's difficult, but very important, to observe mistakes made in the past as to not repeat those mistakes in the future.
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.
It is true that MZ has a tendency to be dramatic, but he's holding back a lot here to make a rational point, and I hope people don't write this off because of Max's propensity for being offensive and complaining.
- Trevor
On Tue, Aug 21, 2012 at 11:46 AM, Ori Livneh ori@wikimedia.org wrote:
On Tuesday, August 21, 2012 at 10:10 AM, Tyler Romeo wrote:
Hey,
Not sure if anybody has seen this article yet:
https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-08-20/Op-ed
Thought it was interesting and possibly worth discussion.
I responded on the talk page[1], taking credit for the elephants quote, apologizing for it, and providing a bit of context. I think the context changes the meaning and tone of what I wrote considerably. It sucks that it is used in this way -- to malign the efforts of my colleagues. Sorry.
-- Ori Livneh ori@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tuesday, August 21, 2012 at 12:04 PM, Trevor Parscal wrote:
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.
Yes, agreed. I've articulated my view here: https://meta.wikimedia.org/w/index.php?title=Experiments&diff=4046416&am...
Ori
Well said. Thank you for sharing.
- Trevor
On Tue, Aug 21, 2012 at 12:18 PM, Ori Livneh ori@wikimedia.org wrote:
On Tuesday, August 21, 2012 at 12:04 PM, Trevor Parscal wrote:
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.
Yes, agreed. I've articulated my view here:
https://meta.wikimedia.org/w/index.php?title=Experiments&diff=4046416&am...
Ori
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 21, 2012 at 12:04 PM, Trevor Parscal tparscal@wikimedia.org wrote:
That was unfortunate - I've been ridiculed (by Max) for things I've said before as well, I feel your pain Ori.
That said however, I generally agree with this piece. I have more faith than the author seems to have that we are on the right track to doing better work in the future, but the points made are pretty valid. It's difficult, but very important, to observe mistakes made in the past as to not repeat those mistakes in the future.
A few of MZ's points make a lot of sense. It's sad, unfortunate and pretty unacceptable that we're been shipping features with no anti-vandalism or spam protection. Some of the newer interfaces do indeed look pretty childish. AFT, in it's current form really doesn't provide a lot of useful feedback.
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. The original design was flawed in that it used wiki pages and wiki page revisions for storage, which leads to it being unusable at scale. We should take this as an example of why we should avoid featuritis as much as possible and that we should consider scalability in initial designs to be a crucial feature.
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 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.
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.
It is true that MZ has a tendency to be dramatic, but he's holding back a lot here to make a rational point, and I hope people don't write this off because of Max's propensity for being offensive and complaining.
I feel the Op-Ed takes a very negative approach at trying to solve what is effectively a communication problem. MZ's constructive points are very likely to be ignored because his negative and offensive approach makes it difficult to discuss his points without splitting the views into an us vs them debate.
- Ryan
On 21/08/12 22:01, Ryan Lane wrote:
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 think that there are both cases. Sometimes with a colleagues mind and others with a customers view. Also with fluctuations depending of the developer, the other person and the developer mood.
On Tue, Aug 21, 2012 at 12:04 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
One of the most important points here is about experimenting on users; and it should be taken seriously.
Loaded terminology. "Experimenting on wikis" is one thing, while "Experimenting on users" sounds BAD -- the lab rats will revolt! Obviously, testing changes to a web site means presenting alternatives to users of the web site and measuring outcomes.
(There is My preferences > Appearance > check "Exclude me from feature experiments"; though it's probable some artifacts will leak out, as happened for a few weeks in the bug he references.)
-- =S Page
On 22.08.2012, 0:20 S wrote:
(There is My preferences > Appearance > check "Exclude me from feature experiments"; though it's probable some artifacts will leak out, as happened for a few weeks in the bug he references.)
Unfortunately, anons have no preferences and most registered users don't know what is an experimental feature and what is not - they can't make informed decisions here.
On Tue, Aug 21, 2012 at 1:20 PM, S Page spage@wikimedia.org wrote:
(There is My preferences > Appearance > check "Exclude me from feature experiments"; though it's probable some artifacts will leak out, as happened for a few weeks in the bug he references.)
As the person who implemented that preference, I can tell you that the
reason we did so was because the lab rats indeed did revolt.
Experimenting on users - perhaps it is loaded, what I take from it though is the way we tend to not do enough testing or evaluation as to whether a change actually accomplishes it's objective before unleashing it on our users. There are many cases where this has failed, and in each of those cases we have lost the trust of our users.
- Trevor
While I don't agree with the negative sentiment around experimentation, I think there's value both in MZMcBride's op-ed, and in the comment thread that follows. He correctly calls out some of our long term organizational failings around product planning, resource allocation, execution, and follow-thru. It's almost as painful to read about LiquidThreads as it is to use talk pages today, eight years after the LT project was first proposed. Are we learning from our failures?
The criticism around AFTv5 in terms of product design (nevermind the code) is largely echoed in the comments, yet we seem rather sure that we're giving editors a tool of importance. My daily sampling of what's flowing into the enwiki db from the feature appears to be 99% garbage, with the onus being on volunteers to sort the wheat from the chaff. If we had a dead simple, highly function, and well designed discussion system (see LiquidThreads), wouldn't that be the ideal route for "high value" feedback from knowledgeable non-editors instead of an anonymous one-way text box at the bottom of the articles that's guaranteed to be a garbage collector?
The one thing the op-ed seems to miss is that one of the main goals of the foundation is to attract new editors and improve the editing experience. I think development in that direction (visual editor with a new parser especially) is hugely promising but we also need to remain cognizant of the needs of our community, take care in allocating resources, and integrate feedback lest our efforts mistakenly contribute to our retention problem.
On Tue, Aug 21, 2012 at 10:10 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Hey,
Not sure if anybody has seen this article yet: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-08-20/Op-ed
Thought it was interesting and possibly worth discussion.
--Tyler Romeo _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The criticism around AFTv5 in terms of product design (nevermind the code) is largely echoed in the comments, yet we seem rather sure that we're giving editors a tool of importance. My daily sampling of what's flowing into the enwiki db from the feature appears to be 99% garbage, with the onus being on volunteers to sort the wheat from the chaff. If we had a dead simple, highly function, and well designed discussion system (see LiquidThreads), wouldn't that be the ideal route for "high value" feedback from knowledgeable non-editors instead of an anonymous one-way text box at the bottom of the articles that's guaranteed to be a garbage collector?
I've been roundly critical of AFTv5; but there are good things to draw from the process, if not the outcome.
It was nice, for example, to see Oliver assigned to bridging the developer-editor gap. It hasn't been 100% successful but it has been pleasant to see the feedback from developers -> wiki.
That said there were downsides; like, the tool seemed to have conflicting aims (is it for editors? For recruitment?) and seemed to lack feedback from wiki -> developers (the tool itself has a number of obvious "flaws" for anyone used to dealing with the wiki eco system).
So; steps forward.
Tom
wikitech-l@lists.wikimedia.org