Hey All,
This new feature has caused a bit of flack on English Wikipedia; which gives me a bit of a platform to bring up some issues that have been rolling round in my brain recently. A lot of the criticism on Wiki has been overly harsh - so I want to try some constructive feedback here on the mailing list :)
Firstly, congrats to the developers on putting together a nice, easy to use tool. It's not to my taste (FWIW) but there is effort and care put into the tool - and whatever anyone says or moans; kudos for that. I'd *love *to see those involved consider tweaking and improving the Wiki interface/theme/UI to make it more modern and nice :)
The second point to make is that this is also a somewhat "misguided" tool. It has been pitched as a way to promote inter-editor friendship and increase editor retention. The issue here, of course, is that WikiLove does not really address the problem that affects new editors (or experienced editors) and drives them away. Those problems are to do with editor interaction, poisonous atmosphere, lack of communication - but not the sort that can be solved by slapping a "template" on the page. No, that problem is really only solvable by going the other way - to make a determined effort to leave personal and thoughtful messages (I hope I am not preaching here; I make a huge effort to do this myself).
The way that this ended up appearing to be pitched as a "golden solution" has not gone down too well because it appears as if the developers are not "getting" the problem (when actually I am certain they are doing so; and realise this is just one small part in the whole picture).
The other problem is that it somewhat undermines and trivialises what a barnstar is. Sure they can be handed out freely as it is - but it does take a small modicum of effort. In my year back editing Wikipedia I have received 7 barnstars from editors for my activities. I specifically recall what they were all for - and behind each is a piece of effort, time or trial that I am extremely proud of. Not least because someone else out there thought "yep, this guy has done a good job here".
The point of that somewhat lengthy paragraph is this: trivialising Barnstars removes their current purpose (a relatively difficult to obtain piece of quiet pride). This would be fine if their new "purpose" was as-or-more important. But as mentioned above I don't think it is.
From a personal perspective, then, it is disappointing to see WikiLove using
Barnstars. But I am getting off topic.
The other thing that has grated is this: for the most part us editors appreciate developer attention (and we do not show that enough, sorry). However English Wikipedia is also strongly *independent *and makes its own decisions. Major changes to how the software works, or to the UI (especially if it affects the social infrastructure too) is instantly controversial and should be discussed with the community.
Very little discussion ocurrred r.e. rolling this out. For example no trial was offered, no "Request for Comment" was taken to guage community opinion. I know these are our processes and a significant part of the blame lies with the editors - but even so announcement of the feature suddenly seemed to "appear"on-wiki the day before :) (that may not be an accurate picture - but for most that is how it appeared).
It was only *after* deployment that is was explained that the extension is amazing customisable on-wiki (a really thoughtful idea. You guys need to write more extensions like this, awesome stuff). So, more miscommunication.
This comes to the crux of the issue; I think the feature probably will be accepted by the community, with some tweaking. But communication issues have turned some people heavily against it (mostly, I suspect, because they genuinely feel no one was able to give feedback prior to roll out).
I've seen this happen before numerous times - Wiki does something. Or a dev does something. There is miscommunication and people who would probably see eye-to-eye are growling at each other across tables. The established Wiki editors feel put out and the developers feel under-appreciated (did I mention: WikiLove guys!). [Ironically *the same problem* is a big part of the editor retention issue on-wiki]
It comes down to a lack of understanding of the processes, attitudes and "languages" involved in both the developer and wiki communities.
So the question that this leads me to is this: what can we do to improve communication between these two groups. How can we vocalize the communities thoughts, ideas and independence. How do we get the creativity and versatility of the developers in front of the community.
Do we need some sort of group to cross this boundary and focus on smoothing out these hiccups?
Fire away :)
Tom
On 1 July 2011 03:45, Howie Fung hfung@wikimedia.org wrote:
Everyone,
Earlier today, we deployed WikiLove Extension [1] to the English Wikipedia. We also made some minor changes to the Article Feedback Tool as well.
For those who are interested, the following url may be used to view how Wikilove is being used:
http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&limit=500&...
Please provide feedback on the Wikilove talk page [2].
Thanks!
Howie
[1] http://www.mediawiki.org/wiki/Extension:WikiLove [2] http://www.mediawiki.org/wiki/Talk:WikiLove< http://www.mediawiki.org/wiki/WikiLove_1.0%3E _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Fri, Jul 1, 2011 at 12:32 PM, Thomas Morton morton.thomas@googlemail.com wrote:
Those problems are to do with editor interaction, poisonous atmosphere, lack of communication - but not the sort that can be solved by slapping a "template" on the page.
Editors fight because we throw them into an arena. Arenas have lots of benefits, but they're a tad stressful for most. When we open up something that's not an arena, we'll get to keep the editors who like our mission but hate our bloodsport.
The other problem is that it somewhat undermines and trivialises what a barnstar is.
For what it's worth, I used the tool today, I LOVED it-- but it did occur to me that others would be troubled by the 'barnstar inflation' effects. Not a big deal to me at all, I loved the tool, I didn't even think to mention the barnstar inflation concern in my feedback-- but we should listen up to see if that's a prevalent concern.
However English Wikipedia is also strongly *independent *and makes its own decisions. Major changes to how the software works, or to the UI (especially if it affects the social infrastructure too) is instantly controversial and should be discussed with the community.
So, seriously no criticism of the developers who did this-- it's great. I too would have rolled it out immediately, I too didn't think it would be controversial.
If we have a controversial change we think is a good idea, then the solution would be to let "large" projects independently decide of their own free will whether to implement a software change. Some projects are very small, they just want the default. En and de are two languages that I think _are_ very strong in their traditions of authorial independence, and I'm sure there are many others that also have strong, functioning self-governance capable of making these decisions.
I wouldn't beat myself up over in this case-- it's small change, it seemed like even worse-case it would just be 'unpopular', not controversial.
So the question that this leads me to is this: what can we do to improve communication between these two groups.
We have to "wikify" the the foundation processes and the development processes. Currently, we're a cyborg-- a mass of living cells melded to a US 501(3)(c) corporation and it's staff. Slowly, gradually, without upsetting the applecart, we have to "wikify" the functions performed by the professionals.
That doesn't mean we get ride of the foundation or the professionals-- we just interact with the better and try to erase the barriers between the groups.
My suggestions for better communication are: * Staff and devs should do as much of their work in public except in cases of SERIOUS, NO-CHOICE. As much as possible, show emails, show code, show everything. This will help the community understand what's happening, why it's happening, and how it came to happen. * In some cases, teams might use a "community conduit" person-- someone from the community responsible not for directly advising the team, but for neutrally soliciting advice from the community on the current direction. * Let a project "turn the key". If you give a car, you put a ribbon on it and let them turn the key. You don't kidnap and sedate them so that they can wake up an already-running car. Project communities enjoy "here's the new thing, take it for a spin", they don't enjoy "You'll have it and you'll like it". Let the authorities of a local project 'turn the key', don't force it upon them.
Again, I didn't see Wikilove as being controversial-- but since it was, at least in part--- this is how we do better next time. Alec
On 2 July 2011 13:01, Alec Conroy alecmconroy@gmail.com wrote:
Editors fight because we throw them into an arena. Arenas have lots of benefits, but they're a tad stressful for most. When we open up something that's not an arena, we'll get to keep the editors who like our mission but hate our bloodsport.
This is a marvellously concise summary of the problem.
(If you don't post this stuff to a blog, you should.)
- Staff and devs should do as much of their work in public except in
cases of SERIOUS, NO-CHOICE. As much as possible, show emails, show code, show everything. This will help the community understand what's happening, why it's happening, and how it came to happen.
Development is being consciously moved to this model, because the devs have realised that repelling the volunteers is a bad idea.
A lot of the community upset about every little thing is just "why wasn't I consulted?" [1] Sometimes this is appropriate and reasonable, sometimes it really isn't.
- d.
Development is being consciously moved to this model, because the devs have realised that repelling the volunteers is a bad idea.
That's *great* news!
A lot of the community upset about every little thing is just "why wasn't I consulted?" [1] Sometimes this is appropriate and reasonable, sometimes it really isn't.
I partially disagree here; the community are the people building Wikipedia - so anything extensively modifying the social dynamics or interface is something they are intimately interested in. To have it modified with minimal notification.... I can understand why it leaves a bad taste in the mouth of some.
Sure, whoever in this thread said "whatever discussion takes place someone will always moan", but in this case it was basically announced "you;re getting this new feature". It disgruntles editors that they appear to have minimal input into what tools/changes the software gets.
I imagine this feeling is worse on the smaller projects who are desperate for re-engineering of certain aspects of MW to suit their needs.
Tom
On Fri, Jul 1, 2011 at 8:32 PM, Thomas Morton morton.thomas@googlemail.com wrote:
So the question that this leads me to is this: what can we do to improve communication between these two groups. How can we vocalize the communities thoughts, ideas and independence. How do we get the creativity and versatility of the developers in front of the community.
As far as communication goes, I think the way communication and publicity occurs on Wikipedia is a bit hit-and-miss. Sometimes people are aware of the sheer size and diversity of Wikipedia, and the need for adequate communication and discussion of something with notices left in the right places. But even when something has been widely publicized and discussed, you will still get people turning up and saying "I wasn't aware of this" (which is why it is useful to have a summary of the notifications to point them towards, so they can realise where they should be paying attention). It doesn't really apply to developer-community interaction, but an attempt to cover the spectrum of publicity efforts is here (which I started a while ago):
http://en.wikipedia.org/wiki/Wikipedia:Publicising_discussions
Trouble is, I'm not sure how many people are aware of that advice. I do get the impression that a lot more of the centralised discussions get wide participation now, but it is always a balancing act between publicizing too much and too little (not everything needs lots and lots of notices). This is best summed up by what the page currently says:
From 'Wikipedia:Publicising discussions': "Most discussions will only
use a few of the publicity methods shown. Normal discussions do not always need large amounts of input. A balance needs to be struck between gaining sufficient input for consensus, and overwhelming a discussion with too much input. Similarly, publicising minor discussions makes it more difficult for editors to identify the major discussions where their comments are more important."
It would be really good to be able to follow the number of hits a page is getting in terms of *where* people came from to arrive at that page, and hence get an idea of which forms of notification work best, but I'm not sure that is technically possible or can be made public for various reasons (if it was, it could involve ranking the links in 'what links here' by how many hits they were generating).
For developer-community interactions, the main problem is usually that developers do work off-wiki and may be working to different specifications to that that some editors on-wiki would prefer, and it is not always clear how much flexibility there is, and whether developers are following their preferences or whether it is software and/or time and available resources that is constraining them. But an important point for developers to pick up on is no matter how brilliant the work they do, it won't get used if the community it is written for don't like it, or react against it due to poor roll-out methods.
Carcharoth
On 7/1/2011 2:32 PM, Thomas Morton wrote:
Very little discussion ocurrred r.e. rolling this out. For example no trial was offered, no "Request for Comment" was taken to guage community opinion. I know these are our processes and a significant part of the blame lies with the editors - but even so announcement of the feature suddenly seemed to "appear"on-wiki the day before :) (that may not be an accurate picture - but for most that is how it appeared).
It was only *after* deployment that is was explained that the extension is amazing customisable on-wiki (a really thoughtful idea. You guys need to write more extensions like this, awesome stuff). So, more miscommunication.
I've seen this happen before numerous times - Wiki does something. Or a dev does something. There is miscommunication and people who would probably see eye-to-eye are growling at each other across tables. The established Wiki editors feel put out and the developers feel under-appreciated (did I mention: WikiLove guys!). [Ironically *the same problem* is a big part of the editor retention issue on-wiki]
Personally, I don't see why "community discussion" and "consensus" is required for each and every change or addition to the software. Sometimes, bold action is truly the only way to move the encyclopedia forward, especially in the face of those who generally don't like change. Many times, the community in general does hold back many additional innovations the developers may come up with solely for the sake of "process". This article parallels such conflict between "process" and "development":
http://radar.oreilly.com/2011/05/process-kills-developer-passion.html
-MuZemike
This reminds me somewhat of the Vector rollout, I've just today come across another example of why we need to upgrade newbies to Monobook once they start editing. Monobook has a rather useful "Email this user" option in the sidebar. I suspect Vector has something hidden away in a dropdown menu, but if so I couldn't immediately find it and I was expecting it to be there. If one on one advice is indeed the best way for some newbies to learn, them Email is probably one of the better ways for newbies to get feedback.
Another reason why we should at least test making Monobook the default for newby editors - no objections to it being the default for readers if they were the people it was designed for.
WereSpielChequers
On 3 July 2011 18:24, MuZemike muzemike@gmail.com wrote:
On 7/1/2011 2:32 PM, Thomas Morton wrote:
Very little discussion ocurrred r.e. rolling this out. For example no trial was offered, no "Request for Comment" was taken to guage community opinion. I know these are our processes and a significant part of the blame lies with the editors - but even so announcement of the feature suddenly seemed to "appear"on-wiki the day before :) (that may not be an accurate picture - but for most that is how it appeared).
It was only *after* deployment that is was explained that the extension is amazing customisable on-wiki (a really thoughtful idea. You guys need to write more extensions like this, awesome stuff). So, more miscommunication.
I've seen this happen before numerous times - Wiki does something. Or a dev does something. There is miscommunication and people who would probably see eye-to-eye are growling at each other across tables. The established Wiki editors feel put out and the developers feel under-appreciated (did I mention: WikiLove guys!). [Ironically *the same problem* is a big part of the editor retention issue on-wiki]
Personally, I don't see why "community discussion" and "consensus" is required for each and every change or addition to the software. Sometimes, bold action is truly the only way to move the encyclopedia forward, especially in the face of those who generally don't like change. Many times, the community in general does hold back many additional innovations the developers may come up with solely for the sake of "process". This article parallels such conflict between "process" and "development":
http://radar.oreilly.com/2011/05/process-kills-developer-passion.html
-MuZemike
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Vector has it in the sidebar too, let's not forget Vector was modelled after Monobook :P
On Mon, Jul 4, 2011 at 4:41 AM, WereSpielChequers < werespielchequers@gmail.com> wrote:
This reminds me somewhat of the Vector rollout, I've just today come across another example of why we need to upgrade newbies to Monobook once they start editing. Monobook has a rather useful "Email this user" option in the sidebar. I suspect Vector has something hidden away in a dropdown menu, but if so I couldn't immediately find it and I was expecting it to be there. If one on one advice is indeed the best way for some newbies to learn, them Email is probably one of the better ways for newbies to get feedback.
Another reason why we should at least test making Monobook the default for newby editors - no objections to it being the default for readers if they were the people it was designed for.
WereSpielChequers _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Vector has "email this user" but only if you expand the toolbox. If newbies look for it under "Interaction" they won't find it. Personally I think that Emailing someone is more about interaction than it is a tool. But Monobook neatly sidesteps the issue by making it a clear choice in the sidebar rather than hidden away in dropdown menu.
If we are going to implement the board resolution on Openness we should either upgrade Vector to make editing more open for newbies, switch the default back to monobook, or at least change the default setting for Appearances in Vector from " Enable collapsing of items in the navigation menu in Vector skin" being preticked to default to unticked. But we shouldn't rely on Newbies setting such an option themselves.
WSC
On 4 July 2011 06:50, Ancient Apparition fridaesdoom@gmail.com wrote:
Vector has it in the sidebar too, let's not forget Vector was modelled after Monobook :P
On Mon, Jul 4, 2011 at 4:41 AM, WereSpielChequers < werespielchequers@gmail.com> wrote:
This reminds me somewhat of the Vector rollout, I've just today come across another example of why we need to upgrade newbies to Monobook once they start editing. Monobook has a rather useful "Email this user" option in the sidebar. I suspect Vector has something hidden away in a dropdown menu, but if so I couldn't immediately find it and I was expecting it to be there. If one on one advice is indeed the best way for some newbies to learn, them Email is probably one of the better ways for newbies to get feedback.
Another reason why we should at least test making Monobook the default for newby editors - no objections to it being the default for readers if they were the people it was designed for.
WereSpielChequers _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- James _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
This issue hasn't been raised in the past, I personally think talk pages are a better medium of conversation, in an email only one person can help unless the mesage is sent to a list, i.e. this list. We should be encouraging new users to engage in talk page discussions, not emailing other users. IMO, emails are only there for privacy, if a user wants help they should be posting on the relevant noticeboard or talk page. Monobook is quite laggy and ugly and a lot of the helpful user scripts aren't compatible with it, but I digress.
On Mon, Jul 4, 2011 at 5:47 PM, WereSpielChequers < werespielchequers@gmail.com> wrote:
Vector has "email this user" but only if you expand the toolbox. If newbies look for it under "Interaction" they won't find it. Personally I think that Emailing someone is more about interaction than it is a tool. But Monobook neatly sidesteps the issue by making it a clear choice in the sidebar rather than hidden away in dropdown menu.
If we are going to implement the board resolution on Openness we should either upgrade Vector to make editing more open for newbies, switch the default back to monobook, or at least change the default setting for Appearances in Vector from " Enable collapsing of items in the navigation menu in Vector skin" being preticked to default to unticked. But we shouldn't rely on Newbies setting such an option themselves.
WSC
On 4 July 2011 06:50, Ancient Apparition fridaesdoom@gmail.com wrote:
Vector has it in the sidebar too, let's not forget Vector was modelled
after
Monobook :P
On Mon, Jul 4, 2011 at 4:41 AM, WereSpielChequers < werespielchequers@gmail.com> wrote:
This reminds me somewhat of the Vector rollout, I've just today come across another example of why we need to upgrade newbies to Monobook once they start editing. Monobook has a rather useful "Email this user" option in the sidebar. I suspect Vector has something hidden away in a dropdown menu, but if so I couldn't immediately find it and I was expecting it to be there. If one on one advice is indeed the best way for some newbies to learn, them Email is probably one of the better ways for newbies to get feedback.
Another reason why we should at least test making Monobook the default for newby editors - no objections to it being the default for readers if they were the people it was designed for.
WereSpielChequers _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-- James _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Personally, I don't see why "community discussion" and "consensus" is required for each and every change or addition to the software.
I agree, actually. Indeed had this been taken to community discussion I doubt we would have the tool - it's probably better (considering the customisation) to have been landed with it with little discussion and for the community to figure out how best they can use it.
Because it can be useful.
Sometimes, bold action is truly the only way to move the encyclopedia forward, especially in the face of those who generally don't like change.
Yes; the key problem is assessing when roadblocks are there purely because of a few curmudgeons or because the community simply does not want X.
Indeed the community wants lots of Y, and it probably sticks in a few peoples craw that instead they got X :)
In this case the objections are genuine, and related to a crucial argument (i.e. the "FacebooK" thing) that has not yet been resolved. For those utterly opposed to socialising Wikipedia (under genuine arguments, I feel) this risks coming across as an attempt to impose such things de-facto.
Not the case at all, of course, but all I am saying is that if lines of communications had been opened the devs would have been aware of the touchy subject and could have taken steps to show how this didn't step on toes/issues.
Ideally better communication wouldn't have blocked deployment, just smoothed the way :)
Many times, the community in general does hold back many
additional innovations the developers may come up with solely for the sake of "process". This article parallels such conflict between "process" and "development":
http://radar.oreilly.com/2011/05/process-kills-developer-passion.html
Exactly; which is why any line of communication should be two way - because as much as the developers tend to lack access to the communities feelings the reverse is true - the community lacks insight into the developers. Programmers (of which I am one!) are pretty good at progress and subverting process for the betterment of things (a form of "Ignore All Rules") and dialogue back into the community can only help improve that.
Tom
On 1 July 2011 20:32, Thomas Morton morton.thomas@googlemail.com wrote:
Very little discussion ocurrred r.e. rolling this out. For example no trial was offered, no "Request for Comment" was taken to guage community opinion. I know these are our processes and a significant part of the blame lies with the editors - but even so announcement of the feature suddenly seemed to "appear"on-wiki the day before :) (that may not be an accurate picture - but for most that is how it appeared).
It could be effectively switched off by local admins if there were enough objections.