User talk:Jimbo Wales: Difference between revisions
→Break (WMF Engineering and the Wikipedia Community): it's impossible... but a few things would at least help. |
|||
Line 166: | Line 166: | ||
:In terms of "what level was the decision to undertake the project approved" I can only say that it quite properly was not at the board level. If you want my opinion as to where the right level of management for that sort of approval should be it should be with the relevant head of product. (I.E. a relatively straightforward product improvement doesn't need ED signoff, but individual developers shouldn't allocate resources without management review at the appropriate level). There can be reasonable deviations in specific cases (where the feature is very minor, or where it is very major, then a higher or lower level of approval would be fine). Given that general discussion, can you understand why I'm not sure why you are even asking this. |
:In terms of "what level was the decision to undertake the project approved" I can only say that it quite properly was not at the board level. If you want my opinion as to where the right level of management for that sort of approval should be it should be with the relevant head of product. (I.E. a relatively straightforward product improvement doesn't need ED signoff, but individual developers shouldn't allocate resources without management review at the appropriate level). There can be reasonable deviations in specific cases (where the feature is very minor, or where it is very major, then a higher or lower level of approval would be fine). Given that general discussion, can you understand why I'm not sure why you are even asking this. |
||
:Isn't this a better question: "What are the specific problems that people have with the Media Viewer and how can they best be communicate to the appropriate level of the WMF organization so that fixes and improvements can be implemented in a timely fashion?" That's the question that I'm asking you: what's the problem, written up unemotionally, so that I can make sure that the right people hear about it and respond appropriately.--[[User:Jimbo Wales|Jimbo Wales]] ([[User talk:Jimbo Wales#top|talk]]) 14:14, 22 July 2014 (UTC) |
:Isn't this a better question: "What are the specific problems that people have with the Media Viewer and how can they best be communicate to the appropriate level of the WMF organization so that fixes and improvements can be implemented in a timely fashion?" That's the question that I'm asking you: what's the problem, written up unemotionally, so that I can make sure that the right people hear about it and respond appropriately.--[[User:Jimbo Wales|Jimbo Wales]] ([[User talk:Jimbo Wales#top|talk]]) 14:14, 22 July 2014 (UTC) |
||
I consider the whole above discussion ample proof of why the whole process will simply never work satisfactory. Too many differing expectations, too much build around volunteers (software and website). You can never even come close to the efficiency of a company and at the same time you are expected to deliver better quality than a company. It's the most expensive development model there is on the lowest budget, the lowest velocity and exposed to an extreme amount of criticism. You need to be in full control and at the same time are at the mercy of a (and/or the most important) fraction of your user base. You need extreme amounts of input by the different stakeholders of the software, but if you are lucky a few stakeholders are represented in you testgroup of volunteers that are already too busy with other things. You need the most transparent communication and processes and at the same time get out of the way of everyone. You need to be Apple (One More Thing, iMac, iPhone) and Microsoft (Look this enterprise IE6 app that you never spent a dollar on in 10 years still runs on IE11). It is guaranteed to lead to conflict as soon as people stop understanding/respecting these extremely contradictory influences. In the past this used to be less of a problem. No money meant, too bad, good luck and see what happens, aka no expectations everyone is on their own. Now there is money and management and thus people have (wildly varying) expectations. |
|||
In general I do see a few problems though |
|||
* Making the project bigger than it needs to be: how and why did a lightbox imageviewer idea turn into file description page replacement before it's 1st public release ? Probably too ambitious and too much focus on long term. |
|||
* Using opt out as the deploy strategy, instead of gradual and repetitive invite (Invite is a nudge from the website to try something and is often employed by google). |
|||
* Feature development is overly focused on non-editors, but does often create new problems for these editors. There is no reward only 'punishment'. It's like giving a present to the youngest child and then letting it play with the oldest child. Don't be surprised if the older one crushes the toy. |
|||
* No in your face explanation of where the opt-out is located. Make that visible to 'editors'. |
|||
* Worse, no initial opt-out at all... |
|||
Other improvements: |
|||
* Don't poke the bear (do stuff that you know will give en.wp everything it needs to stomp you back in the ground) |
|||
* Explain the way the new feature works. Getting started tours should be requirements of every single new feature. |
|||
* Put a lot more attention on the ethical principles of the community, review the software on those criteria as well as the other criteria. |
|||
* Invest a lot more into identifying stakeholders (types of users). Forgetting institutional donations in MMV was not too handy for instance. That should have been known and documented, with possible justification based on strategy (Please inform the institutions that we are committed and show them these prelim designs for version 2 coming in august 2014). |
|||
* Make those things part of a public specification (Wether people comment on it or not). |
|||
* Make this a required material for every developer/product group: https://www.youtube.com/watch?v=z2exxj4COhU |
|||
These are some small things that would probably help just a bit. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 16:06, 22 July 2014 (UTC) |
|||
== Corporate folklore == |
== Corporate folklore == |
Revision as of 16:06, 22 July 2014
Welcome to my talk page. Please sign and date your entries by inserting ~~~~ at the end. Start a new talk topic. |
He holds the founder's seat on the Wikimedia Foundation's Board of Trustees. The three trustees elected as community representatives until July 2015 are SJ, Phoebe, and Raystorm. The Wikimedia Foundation Senior Community Advocate is Maggie Dennis. |
This user talk page might be watched by friendly talk page stalkers, which means that someone other than me might reply to your query. Their input is welcome and their help with messages that I cannot reply to quickly is appreciated. |
(Manual archive list) |
Software and the WMF vs. the English Wikipedia Community
There is a Request for Arbitration currently being considered: https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case#MediaViewer_RfC. The issue illustrates a problem that needs to be addressed, which is tension between the English Wikipedia community and the WMF staff. On the one hand, it is true that the Wikimedia Foundation owns the servers and so sometimes has to assert power. On the other hand, Wikipedia has operated, with a few exceptions, on the model of community consensus. The issue in point has to do with the Media Viewer software. An RFC was concluded as to whether Media Viewer should be enabled by default or disabled by default. The RFC concluded (consensus of the English Wikpedia community) that it should be disabled by default. It appears that a "regular" en.wiki administrator tried to set those options, and a conflict with a WMF staff member arose, in which the "regular" administrator was severely cautioned, and was threatened with desysopping for interfering with the Office. The issue about Media Viewer is very similar to Visual Editor. WMF staff and its developers attempted to push poorly tested software into production, and the community pushed back. The basic problem, as I see it, is that WMF staff is resistant to input by the community. There are a few situations, such as legal response to copyright violations, in which the principle of Office Action really must trump the community. The rollout of software is not one of the situations in which WMF must act unilaterally. Because of the complex and subtle relationship between the WMF as legal owner of the servers and the community as the purpose of the servers, Arbitration is not the ideal way to resolve this conflict. A cultural change would be preferred. We have already had one disaster narrowly averted with respect to Visual Editor. It does not appear that the WMF staff and its developers have learned that they should listen to the community about software. You, Jimbo Wales, are a board member of the WMF and its founder, and are the representative to the community of the WMF. Can you, Jimbo Wales, reason with WMF staff and remind them that, except in special cases such as Office legal action, their function is to serve the community (not to dictate to the community)? Robert McClenon (talk) 03:27, 16 July 2014 (UTC)
- I think this is a perfect case for ArbCom, personally. I only hope they are up to the task. There is an enormous issue here: does WMF engineering, with a budget of tens of millions of dollars and a professional interest in their expensive initiatives "succeeding," quote-unquote, have an ownership right to shove broken or unwanted software down the volunteer community's throats? This is not so important with MediaViewer, which works fine, but is a huge issue with badly broken toys like VisualEditor or the massive disruption that will be inevitable if Flow is allowed to be imposed. This is the time to figure this question out... Carrite (talk) 15:09, 16 July 2014 (UTC)
- The answer, quite obviously, is "yes". And ArbCom has no power to change that. But there really are two competing issues here. The first is that the implementation of technical enhancements should rarely, if ever, be determined by vote. Too many people (myself included) prefer the status quo, and that tends to result in stagnation. That is an issue for the community. The issue for the foundation is their reliance on the community for this site to work at all. So technical implementations that are broken (notifications) or likely to cause a massive uproar (Flow) carry the risk of eroding the community's trust and diminishing that community. A lot of that comes down to communication. Large swaths of people are going to be upset any time any of these changes are made. That is inevitable, and should not be used in and of itself as an excuse not to implement. From the community's perspective, I don't think MediaViewer is the hill we should want to die on. It is just as easy to open an image in a new tab to get the 'old look' and the feature does seem to be generally supported by our readers. Resolute 13:42, 17 July 2014 (UTC)
- MediaViewer is a proxy for the real fight, which as far as I am concerned is all about Flow — a real frankenstein monster created because the bureaucracy had a budget and needed something to do, with an absolutely gargantuan potential for disruption of the entire WP project. The fight needs to be fought (and lost) over the fairly benign MediaViewer — but a fight lost in such a way by a committed and aggressive ArbCom that Flow's damage is diverted from an English WP launch until it can be proven by practice elsewhere to be a substantial improvement. Obviously, there is inertia among those of us using the software leading to preference for old ways over new. Less obviously, there is a multimillion dollar careerist incentive for WMF Engineering to churn out something, anything new to justify their ever expanding budget. So, I beg to differ: YES, this is the hill where the fight needs to be made; because if the fight starts after Flow is already unilaterally imposed systemwide, the disruption will have already taken place and it will be too late. —Tim Davenport //// Carrite (talk) 17:24, 17 July 2014 (UTC) Last edit: Carrite (talk) 17:25, 17 July 2014 (UTC)
- Carrite this is an extremely unfair and false representation of the situation that does nothing to bring light and love and healing and progress and does much to create the kind of tensions that make progress difficult. You've got the motivations exactly wrong. We badly need software improvements, including improvements to our rather ridiculous system of discussing things with each other by editing raw wikitext (instead of a philosophically wiki but more technically sophisticated approach that allows us to do the same things but in an easier and more intuitive way) and so we are investing engineering in that. It isn't like we are just showering money on the tech team for no reason and then they have to make up a reason to spend it. Saying that is just simply and purely a personal attack on good people who are doing good work. Stop doing that please.
- Are there problems with disconnect between what editors want and what the developers are developing? Sometimes clearly yes. Sometimes that's because editors forget what readers want matters too. But sometimes it's just a dysfunctional disconnect and ALL SIDES have the capability through assuming good faith and entering into non-hostile dialog to work to change that. I encourage you to make your complaints in a positive and constructive way and point out better solutions. Insulting people and spreading FUD is just simply not ok.--Jimbo Wales (talk) 19:25, 17 July 2014 (UTC)
- MediaViewer is a proxy for the real fight, which as far as I am concerned is all about Flow — a real frankenstein monster created because the bureaucracy had a budget and needed something to do, with an absolutely gargantuan potential for disruption of the entire WP project. The fight needs to be fought (and lost) over the fairly benign MediaViewer — but a fight lost in such a way by a committed and aggressive ArbCom that Flow's damage is diverted from an English WP launch until it can be proven by practice elsewhere to be a substantial improvement. Obviously, there is inertia among those of us using the software leading to preference for old ways over new. Less obviously, there is a multimillion dollar careerist incentive for WMF Engineering to churn out something, anything new to justify their ever expanding budget. So, I beg to differ: YES, this is the hill where the fight needs to be made; because if the fight starts after Flow is already unilaterally imposed systemwide, the disruption will have already taken place and it will be too late. —Tim Davenport //// Carrite (talk) 17:24, 17 July 2014 (UTC) Last edit: Carrite (talk) 17:25, 17 July 2014 (UTC)
- This is clearly not the venue for me to speak frankly on this matter. My apologies for attempting to do so. Carrite (talk) 20:16, 17 July 2014 (UTC)
- Look, there is a time and place for generalized bitching and moaning. I personally recommend private email to friends as a good place for that. What I am asking for here is a dropping of emotional outbursts and a very practical set of requests in the form of an NPOV description of what you want. That's something I can take action on.--Jimbo Wales (talk) 14:02, 22 July 2014 (UTC)
- Let me chip in here, if only to communicate that it is not only a handful of usual suspects that are worried by WMF's handling of software updates. Jimbo Wales, you sit on the Board of Trustees. A legitimate concern has been brought up, and you dismiss it as 'insults' and "spreading FUD". There is no insult in saying that the VE deployment was characterised by utter incompetence, both in coding and in communication with the community, that has been documented ad nauseam. Thus, there is no insult in speculating that the same team might fail again. You are old enough to remember the joke "MS Windows - from the people that brought you edlin". And thus, there is no insult in speculating what the motivation might be of a team that in the past could not gather customer requirements, could not roll out software that works, and became defensive when massive bugs were pointed out. Feynman's "Safecracker meets Safecracker" is a classic on this: (quoted from memory) 'My boss asks me to drill a safe [...] I have no idea how to do that, but I'm the janitor. So I take my drill to the room with the safe and make zzzzzzz, zzzzzzzzzzzzz. --Pgallert (talk) 22:06, 19 July 2014 (UTC)
- Pgallert, you misunderstand me I'm afraid. I have no problem with legitimate concerns, and legitimate concerns are neither insults nor FUD. But "Frankenstein monster", "multimillion dollar careerist impluse" and the rest was simply not helpful for Carrite to have said for the simple reason that neither of those is either objectively true nor actionable. It is patently obvious that our antiquated way of holding discussions in raw wikitext is significantly inferior to what is possible, without losing any functionality. Flow is an effort to take what we already do and make it both easier for longterm highly proficient users and easier for newcomers - and it strikes me as clear that improvement will not be difficult given how horrible it is now. To reply to you, for example, one of the most common things that anyone would do in a discussion, I had to scroll up to the most recent section break and click edit then come down and cut and paste (or tediously count) indention levels and add a colon. I then have to sign my comment by either typing dash dash tilde tilde tilde tilde or typing out my username or something or waiting for a bot to notice that I didn't do it and do it for me. That's all completely silly.
- No amount of false ranting about the evil developers and their careerist goals (despite that they work for significantly less than they could get at Google or elsewhere in most cases!) is going to result in one line of better code being written. Constructive and loving feedback about what works and what doesn't in proposed designs, with clear and NPOV explanations of why, based on our intimate knowledge of the editing process is the way forward. That's why I will continue to critique those who engage in unnecessary dramatics and insults of good people. As I said to Carrite above, if he wants to have a "frank" discussion of how much he hates certain developers, he can do it with friends in private email. But please let's use this page to be productive.--Jimbo Wales (talk) 14:02, 22 July 2014 (UTC)
- That would only be true if the developers were sufficiently skilled to land themselves jobs at major corporations such as Google, which they clearly are not. Eric Corbett 14:19, 22 July 2014 (UTC)
- This is clearly not the venue for me to speak frankly on this matter. My apologies for attempting to do so. Carrite (talk) 20:16, 17 July 2014 (UTC)
- Someone should be by shortly to point out the WMF serves a much broader audience than the editing community. It won't actually matter if the software is fit for purpose. Saffron Blaze (talk) 15:26, 16 July 2014 (UTC)
- I don't really understand this comment. Software that is not fit for purpose does not serve readers or editors. Software that makes editing worse does not serve readers or editors. The only way I can make sense of what you are saying is as a straw man attack, i.e. making up a position that the WMF does not take and then refuting it. No one at the Foundation has ever said or thought, not even once, "It doesn't matter if the software is broken, because... readers!" That would be silly.--Jimbo Wales (talk) 19:27, 17 July 2014 (UTC)
- Perhaps this diff will help you understand. The point was... the needs of the 500,000,000 casual users are in effect being held out as the requirement for MV, which may be true, but only if MV actually serves their needs. Saffron Blaze (talk) 13:36, 18 July 2014 (UTC)
- Perhaps, but that does not excuse what appears to be an abuse of admin tools (or, more accurately, the threat to use them in an abusive fashion), which were also not granted via normal community processes. If WMF people are going to behave in that fashion, they should either be required to use clearly designated WMF usernames or go through normal community processes (RfA) to gain their tools. Anything else seems to be against the spirit of this project. Intothatdarkness 16:26, 16 July 2014 (UTC)
- [Some thoughts I also posted at the case page]: The "foundation" on which this is built is the Foundation. Sure Users, it is hoped by the Foundation and others come to this Project to write an English encyclopedia but upon the Foundation's legal and technical ownership and facilities, which has, as been seen in results, benefited the User's in doing so. This is not without demands on Users, however, Users must, according to the Foundation, for example, licence their work freely. Who determines what are attractive forces on donors to and readers of, as well as protecting and promoting the brand and the good will and other assets of the Foundation projects is placed in the Foundation, which has that purpose, not in a multitude of others who don't have the legal responsibility. As for Users, we all obviously showed up using the facility provided, and it's a well known and undisputed phenomena that changing technology is cognitively, emotionally, intellectually a challenge - and that free software is sometimes worth what one pays for it. It does not seem true that the Foundation does not consult widely and openly about the creation and deployment of free software. What anyone should do about the Foundation is go directly to the Foundation. If, for example, one wants them to no longer be adverse to commercial software then go lobby them to change course. Alanscottwalker (talk) 16:04, 16 July 2014 (UTC) Alanscottwalker (talk) 16:36, 16 July 2014 (UTC)
- User:Carrite says that this is a perfect case for ArbCom, if they are up to the task. I agree with Carrite's statement of the issue, but not with his conclusion that ArbCom is the right vehicle. I agree that it is time to figure the question. However, the assertion of "Office" privilege in what is not an "Office action" shows that some WMF personnel see themselves as the owners and not the servants of the community. Some WMF personnel clearly do not accept the will of the community and are willing to use their status to bully the community. If senior WMF personnel accept the will of the community, they may also accept the ArbCom as a representative of the community; but if senior WMF personnel accept the will of the community, they should remind other WMF personnel that they are there to serve the community, not to dictate to it. A cultural change is needed in the WMF. I am asking Jimbo Wales to explain to WMF staff. Robert McClenon (talk) 18:48, 16 July 2014 (UTC)
- Can User:Saffron Blaze explain in more detail whether the explanation should be make to the WMF or the community, and what it should be? Robert McClenon (talk) 18:48, 16 July 2014 (UTC)
- The WMF rep that is at the center of this articulated as much and I think he was addressing that at the editing community. It was essentially the needs of the many (users) trumping the needs of the few (editors). When he made the statement he didn't really address what those needs were so one might be left to consider this is a textbook example of the self-licking ice cream cone. Saffron Blaze (talk) 14:25, 17 July 2014 (UTC)
- I agree with User:Intothatdarkness that the threat of arbitrary use of admin tools and wheel warring is problematic. Should that abuse be dealt with by arbitration (which WMF might or might not accept), or by a cultural change? The latter would be preferred. Robert McClenon (talk) 18:48, 16 July 2014 (UTC)
- Culture change doesn't occur on its own, and without some sort of push I can't see the WMF giving up what it's gotten thus far (admin tools with no community comment or validation and what seems to be an unacceptably wide discretionary action zone) for free. I agree that culture change is to be preferred, but also accept that it might not come without an actual case or threat of action (removal of admin tools) on the part of ArbCom (which seems to be the only group that can do this). Intothatdarkness 20:53, 16 July 2014 (UTC)
- User:Alanscottwalker says that anyone who is concerned about the Foundation should go directly to the Foundation. I agree with him that changing technology is complicated. I partly agree and partly disagree with him when he says that the Foundation does consult openly and widely about the creation and deployment of software. The Foundation does discuss its plans for software openly and widely, but has a bad record with regard to accepting feedback. The backdown on Visual Editor was difficult and painful. Because the Foundation does not readily welcome community feedback, I am accepting Jimbo Wales on behalf of the community to go to the Foundation as the face of the Foundation. Robert McClenon (talk) 18:48, 16 July 2014 (UTC)
- Talking of going to the Foundation, perhaps it's time we blew the dust off Wikipedia:Petition to the WMF on handling of interface changes. It didn't go anywhere when it was put together last year, but could probably garner a fair few more signatures now. — Scott • talk 20:04, 16 July 2014 (UTC)
- "Welcome community feedback", depends on what you mean by welcome - make changes - or do everything 100 people say you must do only their way (but not all 100 people agree exactly what that is). As for Wheel, there was none, and as for Staff Permissions, take it up with the Foundation which is the granter of them, obviously because they think they need them to fulfill their obligations. -- Alanscottwalker (talk) 22:35, 16 July 2014 (UTC)
Here's what I think is the right way forward, and much thanks to those who have asked me to represent the community on these issues (which, of course, I very much desire to do). A great model is what happened recently with concerns about LaTeX support in mathematics. I asked the math community to give an NPOV summary of what isn't working and what they need, and a few people went out and worked with a larger group of people, and they came back with a great explanation and a specific set of actionable requests, which I was able to pass along to Lila in a constructive way. Of course there are still things that could break down between where we are now and actual implementation, but this is at least a powerful and appropriate way to start.
On the Media Viewer issue, it might be very very useful if someone or some group of someones could write up an NPOV summary of what the issue is. And the community could seek a way to better serve both readers and editors. This is the Wikipedia way with articles. Two people are disagreeing? Then the best thing is if some third person comes along and sees a way out of the disagreement by finding a compromise that both parties agree is better than either of their initial preferred options. "Mediaviewer good or evil?" is a question with no happy answer. "Mediaviewer: how to make it better for everyone than the old way" is a question that, if we can answer it, resolves the problem neatly and moves everyone forward with joy and relaxation.--Jimbo Wales (talk) 19:34, 17 July 2014 (UTC)
- I think this all sounds very sensible, although I think you may need to offer your guarantee that editors who engage in something like that will not simply be wasting their time. The underlying problem, I think, is a perception among editors that they are seen as an obstacle to "progress" and WMF staff are not really interesting in engaging with them until they are forced to. IMO, whether this perception is a good reflection of reality or not is besides the point. WMF ought to be scrupulous in ensuring that it carries editing communities with it and I think it is hard to mount an argument that this is the way things are. In this discussion, I think it can fairly be said that you are seeking engagement, but there is a stark contrast between this and the recent behaviour of WMF's deputy director. Formerip (talk) 22:31, 17 July 2014 (UTC)
- As an aside, could the process you suggest be easily undertaken using Flow? I'm not sure, but at the moment, it doesn't look like Flow is going to offer the flexibility to provide a space where editors can draft something in collaboration. Formerip (talk) 23:32, 17 July 2014 (UTC)
- @FormerIP: Hi, I believe you're referring to the current experimental-configuration, whereby only the original author of a flow-post (or an admin) can edit the post. This is currently a trial-setup, and they did some analysis of the use-cases, which is documented at mw:Flow/Editing comments. The rationale for it is given at mw:Flow/FAQ#Will we be able to edit other people's posts?. Whilst that experiment is ongoing, they're also considering creating a type of open-post that could be inserted anywhere in a discussion (a 'scratchpad' or 'sandbox' post). So, those are the 2 main possibilities at the moment (but alternative/new suggestions, are appreciated). There's also, of course, the option of doing the collaborative editing on a project-page, and having a Flow discussion on the talkpage. Feedback is welcome (and appreciated, they want wider constructive-input) ideally over at WT:Flow or mw:Talk:Flow (which is an active Flow page). HTH. Quiddity (WMF) (talk) 01:54, 19 July 2014 (UTC)
- Thanks, @Quiddity (WMF):, for the info.
- IMO, though, "We welcome your feedback" is not sufficient in terms of engagement. It is unfortunately obvious that WMF does always walk this limited walk in any case, but it doesn't really work, moreover, because the community's understanding of what WMF is doing naturally lags behing WMF's (particularly to the extent that it opts for incubation in seclusion). This means that if you just sit around waiting for community feedback, you will tend to get it at a stage in the process where it is not really convenient. So, with Flow, WMF seems to have begun considering the needs of Wikipedias only after having designed something that is not well-suited to their needs. Now you are at an awkward juncture of thinking about how to retrofix. It feels unlikely that this will result in software that is as good as it would have been had you been able to see ahead. The main thing that, I think, has to be insisted on, is that none of this is the fault of editing communities. Formerip (talk) 12:02, 19 July 2014 (UTC)
- @FormerIP: Re: "in seclusion" - This is the eternal difficulty - The Flow dev team has been getting feedback from many editors for over a year. But most editors don't have time (or inclination) to help beta-test new software. Additionally, many editors approach developing software with the perspective that by the time they are seeing it, it should be 'complete' and nearly-bug-free, and hence will often give only negative/angry feedback if they see early prototypes, or experimental ideas, or unpolished UIs, or missing features.
- [Tangentially, this mirrors the slow slide away from Eventualism, that worked so well for articles and project-content over the years, and is an ongoing concern for the retention of old and new editors.]
- Even the BetaFeatures, some of which have ~10,000 editors using them (across all 800+ wikis), often only have a few dozen editors giving feedback.
- They also run into the m:Not my wiki problem in a few ways, e.g. Editors are less likely (or able) to properly test software that isn't on their homewiki, and are less able to participate deeply in the process because of the separation (which global-notifications and crosswiki-Flow-discussions, will eventually help with). But at the same time, some editors are reluctant to have incomplete software anywhere on their homewiki.
- There are a number of ideas for ways to increase the quantity of editors who participate in software beta-testing/feedback: everything from better newsletters, to simple inhouse survey systems, to broader (or more targeted) announcements when an extension has been updated, to more specific requests for input on specific features, and others. All of these (and more) are being worked on or investigated, but most of them take time to code, and they all add to the many projects/tasks already clamouring for attention from each editor, so have to be done gently. [I'll stop there, before I tangent/ramble further. HTH.] Quiddity (WMF) (talk) 20:09, 19 July 2014 (UTC)
- There's a bit of WMF double speak at work there. What editors expect is that when a new piece of software becomes the default it should be "complete" and "nearly-bug-free". And that just hasn't been happening, witness the visual editor and now the image viewer. Eric Corbett 20:21, 19 July 2014 (UTC)
- And this is the problem in a nutshell; making non-optimal software opt-out rather than opt-in. When people know something is beta and they're trying it out, they don't moan if there are problems - indeed they often report them. Whereas - like with Visual Editor - if they think this is the standard way of working then they simply say "this is rubbish, it doesn't work". Whilst MV is clearly not as broken as VE was (at least it doesn't actually mangle content), it is not optimal for the editors that contribute the most to the encyclopedia. Black Kite (talk) 20:32, 19 July 2014 (UTC)
- @Quiddity (WMF):. I don't think it's realistic to think in terms of an identity between beta testing and engagement. Imagine my tailor called me up an told me he had made me a suit, so when would I like to come in and have my measurements taken and get a quote for the work. After I had gotten over the surprise of discovering that I had a tailor, I think I would decline the suit. I definitely don't want, or expect, software to arrive complete. What I really want is the opportunity to comment on it before it exists. If it even has a name I'd feel late on the scene.
- WMF's engagement process seems to go something like: "We don't care what you think ... No, we still don't care what you think ... Here's some buggy software ... Why aren't you pleased?" Flow appears to take this to another level entirely by not only excluding editing communities but being designed in willful ignorance that those communities even exist (i.e. how on Earth can you deliver software that is unable to handle basic Wikipedia talkpage processes?). Formerip (talk) 21:54, 19 July 2014 (UTC)
- Formerip, do I understand you correctly? You say here that you want to become involved before the product has a name, but after the decision has been taken about which one of the multiple collaborative-editing proposals will be used. I'm sure that can't be correct, because if it were me—and my only role in Flow is making sure that Quiddity has a long list of requirements from me—I'd care a lot less about what the name is, and a lot more about which one of these methods is chosen. I've seen at least four proposals that don't require giving newbies and IPs the ability to blank or vandalize other people's comments (common area per thread, common area per post, 'scratch pad', separate/transcluded page), and I like some of them a lot better than others. I don't keep up with the discussions very closely, but even I know that the necessity of providing some method for collaborative editing within Flow has been considered a settled fact for months and months now. The question is not "whether", but "which way", and if you care more about editing than about naming, then please think about different ways to achieve the goal and tell Quiddity what your favorite one is. Perhaps you'll come up with an even better proposal than the ones that other people have been looking at. WhatamIdoing (talk) 00:21, 20 July 2014 (UTC)
- No, you don't understand me correctly. Where did I suggest that I wanted to "become involved...after the decision has been taken about which one of the multiple collaborative-editing proposals will be used"? What I want is for editors to have the opportunity to be involved in interface development from the outset of any discussion. I'm perplexed that options to do with collaborative editing are only being considered at such an advanced stage in the process. Formerip (talk) 00:38, 20 July 2014 (UTC)
- People have been considering them since before a prototype for Flow existed. I've seen discussions about this for about a year. That is, I saw discussion on this question before the product even had a product manager assigned, which is to say that I saw discussions about this feature before it was possible to make decisions for the product. Discussions on core features that started, for the first time, today might be considered to happen "at such an advanced stage" (a dubious position, I think, but not unreasonable position, especially if you don't know anything about the state of the software). However, the fact is that discussions about collaborative editing needs are not starting now. The first time I personally saw this issue considered was about a year ago, but I pretty much ignored the product before then. (For all I know, those discussions started before the discussions happened to impinge upon my consciousness.) WhatamIdoing (talk) 01:13, 20 July 2014 (UTC)
- Can you point me to these discussions? I'd like to try to understand why they were ignored. BTW, by "too advanced" I don't mean "today", I just mean any time after a relevant decision has been taken. It's ridiculous that the core purpose of the software is only being uncovered during the testing phase. Even "today", there doesn't seem to be any firm silk-pursing plan. According to the page linked to by Quiddity above mw:Flow/Editing_comments, a scratchpad would "slow down the development and deployment process ... and be worse than existing functionality in some ways", while "Obviously, the ideal is 'not needing comment editing'". So, it seems like WMF may still be hoping that, in default of it having designed software that is fit for purpose, the projects will redesign their processes to be fit for the software. Formerip (talk) 11:48, 20 July 2014 (UTC)
- I think it possible that the reference might be to User_talk:Whatamidoing_(WMF)#Engaging_with_the_mathematics_editor_community, Wikipedia_talk:WikiProject_Mathematics/Archive/2013/Aug#Is_it_time_for_mathematicians_to_leave_Wikipedia? or Talk:Flow_Portal/Archive2#Maths. Deltahedron (talk) 15:51, 20 July 2014 (UTC)
- See now, here's the problem. There are quite a few people who don't think that the software is fit for purpose, which is (by definition) communication. Risker (talk) 15:06, 20 July 2014 (UTC)
- Without wishing to prejudge the issue, and I'm quite looking forward to hearing how they seem in retrospect, I would not have attributed any failure of those discussions to deficiencies in the software. Deltahedron (talk) 15:42, 20 July 2014 (UTC)
- Can you point me to these discussions? I'd like to try to understand why they were ignored. BTW, by "too advanced" I don't mean "today", I just mean any time after a relevant decision has been taken. It's ridiculous that the core purpose of the software is only being uncovered during the testing phase. Even "today", there doesn't seem to be any firm silk-pursing plan. According to the page linked to by Quiddity above mw:Flow/Editing_comments, a scratchpad would "slow down the development and deployment process ... and be worse than existing functionality in some ways", while "Obviously, the ideal is 'not needing comment editing'". So, it seems like WMF may still be hoping that, in default of it having designed software that is fit for purpose, the projects will redesign their processes to be fit for the software. Formerip (talk) 11:48, 20 July 2014 (UTC)
- As a participant in and observer of those discussions, WhatamIdoing, do you think they went well or badly, and why? What could have been done to make them more constructive? Do you think that Community Advocates should have been aware of the discussions earlier? Deltahedron (talk) 09:11, 20 July 2014 (UTC)
- People have been considering them since before a prototype for Flow existed. I've seen discussions about this for about a year. That is, I saw discussion on this question before the product even had a product manager assigned, which is to say that I saw discussions about this feature before it was possible to make decisions for the product. Discussions on core features that started, for the first time, today might be considered to happen "at such an advanced stage" (a dubious position, I think, but not unreasonable position, especially if you don't know anything about the state of the software). However, the fact is that discussions about collaborative editing needs are not starting now. The first time I personally saw this issue considered was about a year ago, but I pretty much ignored the product before then. (For all I know, those discussions started before the discussions happened to impinge upon my consciousness.) WhatamIdoing (talk) 01:13, 20 July 2014 (UTC)
- No, you don't understand me correctly. Where did I suggest that I wanted to "become involved...after the decision has been taken about which one of the multiple collaborative-editing proposals will be used"? What I want is for editors to have the opportunity to be involved in interface development from the outset of any discussion. I'm perplexed that options to do with collaborative editing are only being considered at such an advanced stage in the process. Formerip (talk) 00:38, 20 July 2014 (UTC)
- Formerip, do I understand you correctly? You say here that you want to become involved before the product has a name, but after the decision has been taken about which one of the multiple collaborative-editing proposals will be used. I'm sure that can't be correct, because if it were me—and my only role in Flow is making sure that Quiddity has a long list of requirements from me—I'd care a lot less about what the name is, and a lot more about which one of these methods is chosen. I've seen at least four proposals that don't require giving newbies and IPs the ability to blank or vandalize other people's comments (common area per thread, common area per post, 'scratch pad', separate/transcluded page), and I like some of them a lot better than others. I don't keep up with the discussions very closely, but even I know that the necessity of providing some method for collaborative editing within Flow has been considered a settled fact for months and months now. The question is not "whether", but "which way", and if you care more about editing than about naming, then please think about different ways to achieve the goal and tell Quiddity what your favorite one is. Perhaps you'll come up with an even better proposal than the ones that other people have been looking at. WhatamIdoing (talk) 00:21, 20 July 2014 (UTC)
- And this is the problem in a nutshell; making non-optimal software opt-out rather than opt-in. When people know something is beta and they're trying it out, they don't moan if there are problems - indeed they often report them. Whereas - like with Visual Editor - if they think this is the standard way of working then they simply say "this is rubbish, it doesn't work". Whilst MV is clearly not as broken as VE was (at least it doesn't actually mangle content), it is not optimal for the editors that contribute the most to the encyclopedia. Black Kite (talk) 20:32, 19 July 2014 (UTC)
- There's a bit of WMF double speak at work there. What editors expect is that when a new piece of software becomes the default it should be "complete" and "nearly-bug-free". And that just hasn't been happening, witness the visual editor and now the image viewer. Eric Corbett 20:21, 19 July 2014 (UTC)
- @FormerIP: Hi, I believe you're referring to the current experimental-configuration, whereby only the original author of a flow-post (or an admin) can edit the post. This is currently a trial-setup, and they did some analysis of the use-cases, which is documented at mw:Flow/Editing comments. The rationale for it is given at mw:Flow/FAQ#Will we be able to edit other people's posts?. Whilst that experiment is ongoing, they're also considering creating a type of open-post that could be inserted anywhere in a discussion (a 'scratchpad' or 'sandbox' post). So, those are the 2 main possibilities at the moment (but alternative/new suggestions, are appreciated). There's also, of course, the option of doing the collaborative editing on a project-page, and having a Flow discussion on the talkpage. Feedback is welcome (and appreciated, they want wider constructive-input) ideally over at WT:Flow or mw:Talk:Flow (which is an active Flow page). HTH. Quiddity (WMF) (talk) 01:54, 19 July 2014 (UTC)
I could, User:FormerIP, but it would be pointless, because your premise is wrong: "I'd like to try to understand why they were ignored". These discussions were not ignored. The need for this feature has been agreed to by all parties, including the devs for months. So if your goal is to find out "why they were ignored", you're doomed to failure: you're only going to find the devs saying "Yes, that's obviously necessary. The question is, which of these many possible methods, some of which do not include anyone editing anyone else's actual comments, would be best support collaborative work on article text?"
What hasn't been decided yet is "how"—not "whether"—to have a method of people being able to edit the same text.
Perhaps this will help:
- Done Everyone agrees that a method of working collaboratively on text is absolutely necessary for discussions.
- Not done yet Nobody agrees on the exact method of working collaboratively on text that will be best for collaborative editors.
The status of collaborative editing is "Not done yet". Your premise is that the status is "not going to do it", which is both very different and wrong.
The Flow team really needs people to talk about how to promote collaborative editing. For example, would it be good to have a structured system that indicates that the OP truly does want you to edit what s/he's written (or, conversely, that s/he doesn't)? "Just edit this" hasn't usually worked in my recent experience. If you go look through the recent archives of most major policies (WT:V, WT:CONSENSUS), you'll find few people actually editing the other person's, but instead putting up slight variations, one after another.
One of the problems with this "I'll just post my preferred version, without changing yours" approach is that it's actually hard to tell what has been changed from one version to the next, because you can't get a useful diff. Would you like a system that encourages people to actually edit the original proposal? Would you like one that makes it possible to get a diff on just the changes to the collaborative text? Would you like a system that makes it possible to import the collaborative history into the article, so that if you post a requested edit or help out with collaborative text on a talk page, and your text gets put in the article, then the attribution would be correctly represented in the article history?
People who can wrap their heads around the distinction between "the method I've been using" (e.g., editing someone else's comment) and "what I actually need to achieve" (collaborative editing as part of a discussion) would be really valuable in testing and discussions. WhatamIdoing (talk) 22:14, 20 July 2014 (UTC)
Break (WMF software discussion)
- I thank Jimbo for his kind words about the recent initiative over mathematics content tendering and editing: I am looking forward to seeing the next step in what I hope will become a productive engagement. However, I would be disturbed if it were seen as the model for that sort of engagement, rather than the exception. It took something like a year, on and off, for several people, all from the volunteer side of the house, to get that under way, using time and energy taken away from other contributions to the project and it's still not clear that it will have been worth while. In the meantime, WMF has a team of Community Advocates whose role is to facilitate communication between staff and all the communities in every project under the umbrella of the Wikimedia Foundation, to help ensure that both sides of this important equation are pulling together towards our common goal and to help volunteers get access to resources and information they need from the Wikimedia Foundation and to ensure that the Wikimedia Foundation remains aware of the character of its communities. Unfortunately right now they are unable to act in the way I had hoped, and many members of the community clearly expect: one of them stated "in the way things are currently set up, I am not able to advocate for you in the way that you request, and I have no authority to assign anyone to advocate for you in the way that you request. I can point you to resources; I can pass along your suggestions; I can generally get information. I cannot proactively help tease out requirements for math development from the community, and what I know about what is planned is all public information" [1]. Clearly whatever is getting in the way of the Community Advocates playing the role they asipire to play and the volunteer community wants them to play needs to be fixed, whether it be lack of resources, lack of information, lack of access or lack of authority. Deltahedron (talk) 15:13, 19 July 2014 (UTC)
- Deltahedron, I think this is very excellent feedback. The reason I use this as a model is not the "something like a year" that it took, but rather the "something like a month" (as I recall) from me suggesting the NPOV summary to me getting a commitment from Lila for resources. You are absolutely right that in this particular case (as in all particular cases) time will tell about the results but I'm very hopeful here. It's a lot better than the usual lack of communication and carping, that's for sure.--Jimbo Wales (talk) 13:12, 22 July 2014 (UTC)
- "Community Advocates" are company employees, bottom line. There needs to be formal organization of the volunteers and frank and realistic negotiations need to take place between the two groups, bearing in mind that objectives of each group are not necessarily identical. A "company union" is no substitute for a real union in hammering out a fair contract... The relationship right now is one-sided. Carrite (talk) 03:23, 20 July 2014 (UTC)
- I think that's unduly cynical: they are indeed employees, but their job involves liaison between volunteers and staff. For various reasons unknown to me they are unable to do that to the extent that I would have expected, but I would imagine that one of those reasons is that each group sees them as representative of the "others". Indeed, that's fairly usual for people in a liaison role. Fixing that would involve fixing the culture. Deltahedron (talk) 15:57, 20 July 2014 (UTC)
- More realistically, "fixing that", where "that" means community advocates not being able to pick up any project that any volunteer like Deltahedron wants them to take on, would require that there were far more of them. Right now, there are four community advocates supporting 800+ WMF projects, two million contributors, and half a billion readers. WhatamIdoing (talk) 22:23, 20 July 2014 (UTC)
- WhatamIdoing, I think that's right. Carrite's view is just false - it doesn't reflect the attitudes of the WMF nor the community advocates nor is there inherent tension between the Foundation's goals and the community's goals. When there are frictions, the solution is not to unionize and battle but to fix the underlying problem.--Jimbo Wales (talk) 13:12, 22 July 2014 (UTC)
- Firstly, having community advocates "pick up any project that any volunteer like Deltahedron wants them to take on" is not what I am asking for, and I think that I have discussed this often enough with community advocates, including WhatamIdoing, that she should know this. Just to repeat myself, I was asking for constructive proactive engagement. Is there any serious opposition to that? Secondly, "fixing that" referred to the problem that each group sees the advocates as representative of the "others". Deltahedron (talk) 06:48, 21 July 2014 (UTC)
- Before you get overwhelmed trying to support half a billion readers, I suggest that you focus on the most active 10,000, or the subset of those who have edited within the past three months, and make more use of your Mass message sender privileges. This would be analogous to members of the US Congress, who "support" several hundred thousand voters, focusing on the subset of those voters who are their biggest financial contributors. The most active content contributors are probably Wikipedia's biggest asset. Wbm1058 (talk) 23:47, 20 July 2014 (UTC)
- Interesting point. The biggest asset is probably the readers, whose actions are what makes Wikipedia a top-5 google-hit for almost every subject; the only role of the editors in that is the creation of the page in the first place. Risker (talk) 01:24, 21 July 2014 (UTC)
- I think it is a mistake to go down this path. The Foundation exists to serve the goal of building an encyclopedia. We are here to build it and we want the readers to read it. We can look for points of opposition and devaluation and we might find some if we try really hard. But I think it's a strain. As an editor, I value readers. As a reader, I value editors. In either role, I value the developers who do the technical work to make the rest of it possible. And the developers, in my personal experience, care very deeply about the readers and editors. It is important not to mistake errors or breakdowns in communications as evidence of a fundamental and irreconcilable difference in goals that has to be fought about.--Jimbo Wales (talk) 13:12, 22 July 2014 (UTC)
- Readers are the consumers of the product. That any business which loses its customers (money-paying consumers) likely won't continue its operations for long is a trivial point. I'm not sure what you mean by asset, but I was thinking of the primary meaning: Anything tangible or intangible that is capable of being owned or controlled to produce value and that is held to have positive economic value. One might argue that editors aren't owned or controlled, but perhaps they are ;0| Wbm1058 (talk) 04:16, 21 July 2014 (UTC)
- Sending out a mass message is not generally considered "proactive engagement". It would be insufficient to the point of irrelevance for Deltahedron's goal.
- What Deltahedron wants is for the (four) CAs to push the volunteer mathematics editors into holding long, organized, conversations about product requirements for mathematics software, so that detailed, actionable product specifications and a plan for implementing them can be created and adopted.
- This is not a bad idea at all, except:
- none of the CAs are technically qualified to hold this conversation,
- the most natural department for gathering software requirements is not the one called "Legal and Community Advocacy" department, and
- doing this—even just for this one project, not even counting Deltahedron's desire for this to be done more generally, to find and support many more ideas—the CA team would have to stop at least some of what they're already doing (e.g., answering the emergency contact systems and supporting community discussions about legal-related policy discussions) to make time for this.
- Again: it's not their job to collect product requirements, and it would not be possible to do this in general without a massive expansion of the staff. (Since Congress was mentioned above, I'll note that each US Representative has 18 official staff members, not just four.) Should somebody do this? Maybe: Product already collects requirements for software they're building, but they have historically relied on volunteers community members to approach them with ideas for which products to build. But maybe not: Maybe we don't want a culture in which paid staff crowd out volunteers by taking over tasks that volunteers have historically done (and done well), like talking about how the site software should evolve. Maybe we want to have these discussions when the community feels like it, instead of when some staff member gets an assignment to talk about something. I can see advantages and disadvantages to the general goal. WhatamIdoing (talk) 15:34, 21 July 2014 (UTC)
- I note that User:Whatamidoing (WMF) has as part of her job description "ensuring that readers and editors are represented in the decision-making process and that our planned software adequately reflects user needs". I applaud her frankness in explaining that it is not actually possible for her to do so, at least in the way I propose. What would be needed for it to become possible? Deltahedron (talk) 17:21, 21 July 2014 (UTC)
- Risker suggests that the "biggest asset is probably the readers": actually, I'm pretty sure it's the encyclopaedia, which is what we are building here -- "the only role of the editors in that is the creation": yes, and quite an important one I would have said. Deltahedron (talk) 17:25, 21 July 2014 (UTC)
- Quite. That was a rather strange and very revealing thing for Risker to have said. Eric Corbett 14:14, 22 July 2014 (UTC)
- Not strange at all from a narrow "head office" sort of view where you focus on money raised. It does, however, ignore the reality of product quality (which is created and maintained by those valueless editors). If the product is crap (or becomes crap), you lose customers (readers)...or they lose their willingness to feed the coffers. Intothatdarkness 15:10, 22 July 2014 (UTC)
- Quite. That was a rather strange and very revealing thing for Risker to have said. Eric Corbett 14:14, 22 July 2014 (UTC)
- Interesting point. The biggest asset is probably the readers, whose actions are what makes Wikipedia a top-5 google-hit for almost every subject; the only role of the editors in that is the creation of the page in the first place. Risker (talk) 01:24, 21 July 2014 (UTC)
- More realistically, "fixing that", where "that" means community advocates not being able to pick up any project that any volunteer like Deltahedron wants them to take on, would require that there were far more of them. Right now, there are four community advocates supporting 800+ WMF projects, two million contributors, and half a billion readers. WhatamIdoing (talk) 22:23, 20 July 2014 (UTC)
- I think that's unduly cynical: they are indeed employees, but their job involves liaison between volunteers and staff. For various reasons unknown to me they are unable to do that to the extent that I would have expected, but I would imagine that one of those reasons is that each group sees them as representative of the "others". Indeed, that's fairly usual for people in a liaison role. Fixing that would involve fixing the culture. Deltahedron (talk) 15:57, 20 July 2014 (UTC)
- I thank Jimbo for his kind words about the recent initiative over mathematics content tendering and editing: I am looking forward to seeing the next step in what I hope will become a productive engagement. However, I would be disturbed if it were seen as the model for that sort of engagement, rather than the exception. It took something like a year, on and off, for several people, all from the volunteer side of the house, to get that under way, using time and energy taken away from other contributions to the project and it's still not clear that it will have been worth while. In the meantime, WMF has a team of Community Advocates whose role is to facilitate communication between staff and all the communities in every project under the umbrella of the Wikimedia Foundation, to help ensure that both sides of this important equation are pulling together towards our common goal and to help volunteers get access to resources and information they need from the Wikimedia Foundation and to ensure that the Wikimedia Foundation remains aware of the character of its communities. Unfortunately right now they are unable to act in the way I had hoped, and many members of the community clearly expect: one of them stated "in the way things are currently set up, I am not able to advocate for you in the way that you request, and I have no authority to assign anyone to advocate for you in the way that you request. I can point you to resources; I can pass along your suggestions; I can generally get information. I cannot proactively help tease out requirements for math development from the community, and what I know about what is planned is all public information" [1]. Clearly whatever is getting in the way of the Community Advocates playing the role they asipire to play and the volunteer community wants them to play needs to be fixed, whether it be lack of resources, lack of information, lack of access or lack of authority. Deltahedron (talk) 15:13, 19 July 2014 (UTC)
Break (WMF Engineering and the Wikipedia Community)
The underlying problem is that the WMF engineering team think they should be able to dictate what the Wikipedia community chooses to enable/disable on the Wikipedia project. No one seriously thinks they do not have the right or power to make changes to the underlying software, that is what they get paid to do. However the EN-wikipedia project community takes the view that the community is the final arbiter of what parts of that software are on and visible by default on en-wikipedia. What should be the preferred and least objectionable version of wikipedia that the public sees. Now VisualEditor (and Flow to a lesser extent) are not 'reader' centric upgrades. They are aimed at the editing community who are frankly (and justified in my opinion) unforgiving of engineers who dont listen to feedback, dont understand what is and isnt a priority, and yet still insist on ramming their badly-designed and bug-laden babies down editors throats. Media Viewer is a slightly different kettle of fish in that it is a reader-centric upgrade. However there are still valid concerns with it, and the community decided it should be off by default until its in better shape.
The problem this causes for the WMF engineering team is that they *need* en-wikipedia to adopt their software upgrades to justify their budget and staffing. Its the biggest and most PR/newsworthy project. Its not satisfactory to them to say 'Well we have done all this but no one is using it'. This isnt really their fault, as there is a clear lack of oversight, targets & goals, project management etc etc. The only validation they get is seeing their work turned on on en-wiki. If the engineering team had proper leadership and oversight, they wouldnt be in the place they are now, having software after software rejected by the wiki-project's communities.
Its within Arbcom's scope to say 'This is our project, we will decide what we want to use of your software'. If the WMF does not want to accept that, then it needs to start acting professionally within its engineering teams and not like a bunch of amateurs. There is a proposal for an oversight committee that is a good start, but without dismantling some of the WMF's engineering fiefdoms, I dont really expect it to do much. Only in death does duty end (talk) 23:15, 17 July 2014 (UTC)
They deployed it too early. That's all. They did it again. Too many bugs. Too many important functions missing or poorly implemented. Again. Yes, there will always be troglodytes who resist any change, and editors who seem oblivious to the existence of that other stakeholder, the reader. Those people can always be ignored. But here there are many critical faults being reported by sane volunteers and the WMF's response is, "Aww, people always bellyache about new stuff. They just need to learn where the buttons are." Again. --Anthonyhcole (talk · contribs · email) 12:32, 18 July 2014 (UTC)
- I haven't followed the discussions on MediaViewer closely, but I did have it enabled in beta for several months before it was made mandatory. Were they still receiving complaints of broken or missing features that were legitimately broken and missing features as opposed to "it moved, I don't like it, put it back"? If yes, then I would agree launch was premature. As to the latter point, I agree somewhat with your characterization of WMF's oft-used response to community complaints, but I have to admit that we as a community have partially done that to ourselves. Many people - again, myself included - have railed against changes simply because they were changes. The amount of static we've helped to create has helped to drown out legitimate concern and feedback in some cases. Resolute 15:10, 18 July 2014 (UTC)
- @Resolute: Here's the list of open bugs. I think that they have an interesting idea, and they've made some major improvements... nonetheless, every developer (even for free software) has to face the harsh reality of the marketplace eventually. Wnt (talk) 00:02, 22 July 2014 (UTC)
I think there is more going on here. The thing is that the MediaWiki software is used in tens of thousands of web sites (some fairly important) outside of Wikipedia. I think it's important that the developers of MediaWiki be completely free to do whatever improvements they want/need without Wikipedia breathing down their necks. However, Wikipedians must be the ultimate decision-makers in whether we wish to upgrade to some new and (arguably) improved version - or whether we'd prefer to wait things out on a maintenance branch of our own until things stabilize enough to be used here. Ideally, things like the visual editor, the new media viewer and flow should be options that can be turned on and off - preferably by individual users of Wikipedia. Rather than turning something on by default and waiting for a slew of complaints - we should provide it as an option and carefully inform users that they can turn it on if they like it.
Obviously, there will come a time when some very ancient option that very few people still use needs to be dumped in order to streamline some newer functionality - but it should be easily possible to look at the user base statistics and say "Well - less than 1% of editors are using this - we can just dump it now."
The deal here is that both communities need the freedom to do their thing. That's what makes people happy. That's what allows innovation. If the software team produce a feature that's truly a massive win - then people will flock to use it. If they produce something that's basically just eye-candy, they won't. That's how you figure out what your users want. SteveBaker (talk) 14:23, 18 July 2014 (UTC)
- Let me ask a candid question. From what I read above it appears that Jimbo's position is much closer to the MV's team than to the editors'. Is that is indeed the case, how can he represent this community in the dispute? -- Alvesgaspar (talk) 20:05, 18 July 2014 (UTC)
- Perhaps you could explain in exactly which particulars you find my position to be "closer to the MV's team than to the editors" as a first step. I don't think that's true at all, but I also think that the whole "editors versus developers" meme is factually mistaken and the result of not having a robust view into all sides. What the developers need is non-insulting factual (NPOV) summaries of existing problems and desired solutions. A whole lot of AGF is called for.--Jimbo Wales (talk) 13:01, 22 July 2014 (UTC)
- Why would you think that Jimbo's role was to represent the community in this dispute?—Kww(talk) 15:34, 19 July 2014 (UTC)
- Because of the implicit invitation in the first comment of this thread and of his response above: ... and much thanks to those who have asked me to represent the community on these issues (which, of course, I very much desire to do). -- Alvesgaspar (talk) 16:00, 19 July 2014 (UTC)
One thing people are missing here is that "we don't like changes, why did you move this stuff around" is a legitimate complaint. Arbitrarily changing the user interface so the designers can feel they've accomplished something is one of the scourges of bad software design.
I'm also astonished at the suggestion that Wikipedians "compromise". What does it even mean to compromise with tearing something down and replacing it? Tearing down half of it and replacing the half?Ken Arromdee (talk) 16:06, 19 July 2014 (UTC)
- Indeed, all change comes as a cost. Sadly, the people making the change very often are not the ones paying the cost. Deltahedron (talk) 16:45, 19 July 2014 (UTC)
- Well the ArbCom represents the editor community, as it was elected by the community. Readers, who don't edit and thus don't vote, can only be represented by reputable neutral third-party-produced opinion polls and analysis of site traffic (page reads). Jimbo's request that someone write up an NPOV summary of the issues is reasonable, but is a distraction from other priorities for those who might take the time to do this in a quality way. I've already taken time to give feedback on Visual Editor and Flow, and am frustrated that I only got so far in discussions with product management before the conversation stalled. I would like to know who asked for the Media Viewer, and at what level the decision to undertake the project was approved. – Wbm1058 (talk) 20:20, 19 July 2014 (UTC)
- ArbCom, while elected, does not directly represent the editor community, as they all have opinions of their own. In fact, no one can be said to "represent the editor community". If representation of editors is what you want, an RfC would be closer, but still not close enough. KonveyorBelt 00:14, 22 July 2014 (UTC)
- What you are suggesting is that for Wikipedia, a direct democracy should be preferred over a representative democracy. But the WMF is saying that they have issues with the self-selected participation levels in our direct democracy-based requests for comment. If you don't like the way ArbCom handles this case, then you can vote them out of office. Wbm1058 (talk) 13:28, 22 July 2014 (UTC)
- ArbCom, while elected, does not directly represent the editor community, as they all have opinions of their own. In fact, no one can be said to "represent the editor community". If representation of editors is what you want, an RfC would be closer, but still not close enough. KonveyorBelt 00:14, 22 July 2014 (UTC)
I asked a couple of simple questions:
- who asked for the Media Viewer – and in what venue did they ask? please link to where discussion was initiated, if possible.
- at what level was the decision to undertake the project approved? Board of Directors? Executive Director? Head of Product Management? A product manager under him? Please link to where approval was given if possible
Anyone have answers? Wbm1058 (talk) 13:45, 22 July 2014 (UTC)
- Hi, I don't have answers to all of these questions but I could try to find out if I can understand the purpose of the questions. Why does it matter "who asked" and "in what venue"? Is it your view that it is always improper for the community to propose new features? Always improper for staff to propose new features? I just don't see how it could be of interest at this point to know who asked for it.
- In terms of "what level was the decision to undertake the project approved" I can only say that it quite properly was not at the board level. If you want my opinion as to where the right level of management for that sort of approval should be it should be with the relevant head of product. (I.E. a relatively straightforward product improvement doesn't need ED signoff, but individual developers shouldn't allocate resources without management review at the appropriate level). There can be reasonable deviations in specific cases (where the feature is very minor, or where it is very major, then a higher or lower level of approval would be fine). Given that general discussion, can you understand why I'm not sure why you are even asking this.
- Isn't this a better question: "What are the specific problems that people have with the Media Viewer and how can they best be communicate to the appropriate level of the WMF organization so that fixes and improvements can be implemented in a timely fashion?" That's the question that I'm asking you: what's the problem, written up unemotionally, so that I can make sure that the right people hear about it and respond appropriately.--Jimbo Wales (talk) 14:14, 22 July 2014 (UTC)
I consider the whole above discussion ample proof of why the whole process will simply never work satisfactory. Too many differing expectations, too much build around volunteers (software and website). You can never even come close to the efficiency of a company and at the same time you are expected to deliver better quality than a company. It's the most expensive development model there is on the lowest budget, the lowest velocity and exposed to an extreme amount of criticism. You need to be in full control and at the same time are at the mercy of a (and/or the most important) fraction of your user base. You need extreme amounts of input by the different stakeholders of the software, but if you are lucky a few stakeholders are represented in you testgroup of volunteers that are already too busy with other things. You need the most transparent communication and processes and at the same time get out of the way of everyone. You need to be Apple (One More Thing, iMac, iPhone) and Microsoft (Look this enterprise IE6 app that you never spent a dollar on in 10 years still runs on IE11). It is guaranteed to lead to conflict as soon as people stop understanding/respecting these extremely contradictory influences. In the past this used to be less of a problem. No money meant, too bad, good luck and see what happens, aka no expectations everyone is on their own. Now there is money and management and thus people have (wildly varying) expectations. In general I do see a few problems though
- Making the project bigger than it needs to be: how and why did a lightbox imageviewer idea turn into file description page replacement before it's 1st public release ? Probably too ambitious and too much focus on long term.
- Using opt out as the deploy strategy, instead of gradual and repetitive invite (Invite is a nudge from the website to try something and is often employed by google).
- Feature development is overly focused on non-editors, but does often create new problems for these editors. There is no reward only 'punishment'. It's like giving a present to the youngest child and then letting it play with the oldest child. Don't be surprised if the older one crushes the toy.
- No in your face explanation of where the opt-out is located. Make that visible to 'editors'.
- Worse, no initial opt-out at all...
Other improvements:
- Don't poke the bear (do stuff that you know will give en.wp everything it needs to stomp you back in the ground)
- Explain the way the new feature works. Getting started tours should be requirements of every single new feature.
- Put a lot more attention on the ethical principles of the community, review the software on those criteria as well as the other criteria.
- Invest a lot more into identifying stakeholders (types of users). Forgetting institutional donations in MMV was not too handy for instance. That should have been known and documented, with possible justification based on strategy (Please inform the institutions that we are committed and show them these prelim designs for version 2 coming in august 2014).
- Make those things part of a public specification (Wether people comment on it or not).
- Make this a required material for every developer/product group: https://www.youtube.com/watch?v=z2exxj4COhU
These are some small things that would probably help just a bit. —TheDJ (talk • contribs) 16:06, 22 July 2014 (UTC)
Corporate folklore
A piece published by the Harvard Business Review this week makes for interesting reading.
The historian held the keys to drawer after drawer of artifacts from every era of the company’s existence — sewing machines, product sketches, vintage ephemera, love letters from fans, even the world’s oldest pair of dungarees. It was stuff with a story to tell, and she used it precisely for that purpose. She traveled the world giving presentations that featured these artifacts to illustrate the company’s brand promise through a visceral experience that no brochure or blog post could match.
Given how fashionable storytelling is today, you’d think every market-centered company would have a person like this on staff to manage the collective memory of its brand. But in my experience, not many do, and that’s a shame. Artifacts and stories articulate a company’s identity, purpose, and value to customers and communities in a very real, powerful way. Making these past and present narratives accessible to current and future audiences is an important role because it captures the spirit of the organization and uses that to develop an even stronger brand. This role is so important, in fact, that companies should give it executive-level visibility, authority, and resources.
— Patti Sanchez, Why Marketing Needs to Hire a Corporate Folklorist, Harvard Business Review, 15 July 2014
As someone that's worked a little bit with business archives of brand companies, I know exactly what she's talking about. Any large company will have a fantastic wealth of material about its history to mine and present. However, our instance on it being verboten for businesses to officially edit articles about themselves means that we've shut off our access to this quality of information, condemning our articles on businesses to be shallow when they could be rich and engrossing. Of course, it's the word officially there that's the problem - everyone knows that businesses edit about themselves all the time. Look at the contributor history of any business article and within seconds you'll find undeclared company SPAs, or even paid editing accounts. A saner, healthier, and more accountable road would be to allow business editing subject to exactly the same content policies that the rest of us adhere to. That way would bring business articles into the sunshine and end the black market for editing them; and we could establish a new era of outreach, with Wikipedians in Residence working with or as those corporate folklorists to enliven and deepen our coverage of any business that was willing to participate. — Scott • talk 08:54, 18 July 2014 (UTC)
- This argument is entirely utterly completely 100% unpersuasive. "However, our instance on it being verboten for businesses to officially edit articles about themselves means that we've shut off our access to this quality of information, condemning our articles on businesses to be shallow when they could be rich and engrossing." It is very very easy for archivists and historians employed by brands to interact ethically with Wikipedia. There is no need for them to edit article space directly. And as we know from many many incidents over a long period of time (1) their edits will on average be tediously self-serving PR speak and (2) the press will chew them up for doing it, and rightly so.--Jimbo Wales (talk) 17:48, 21 July 2014 (UTC)
- Of course, Jimmy, because so very many of them have done that until now. And now that you've decided to publicly piss on them, they'll be even more motivated to take the time to learn our rules and participate here in a beneficial fashion. Flawless logic, Glorious Leader. It's also pretty rich for someone from the WMF to pass comment on "tediously self-serving PR speak", at which your organization excels. — Scott • talk 18:47, 21 July 2014 (UTC)
- Again, that doesn't make any sense whatsoever. I have always been very warmly supportive of people who want to approach us in a transparent and ethical fashion, allowing independent community members to make a determination about editorial matters. That isn't "pissing all over" anyone we actually want here. As for the rest, it's just noise rather than coherent arguments. (Tu quoque fallacy, look it up.)--Jimbo Wales (talk) 19:55, 21 July 2014 (UTC)
- How can you say that you welcome people approaching us in a "transparent and ethical fashion" when you support a system that forces business editors to become incognito? "Smithsonandco" gets blocked and has to change their name to "JoeLovesAirplanes123", at which point they're merrily unblocked by some admin, then off they go. Look at the renaming logs; it happens all the time. That's not tu quoque, it's just pointing out the gigantic logical disconnect between what you say you support and what actually happens. Your comment about "their edits will on average be tediously self-serving PR speak" is also telling: abuse of our articles for promotional purposes is an artifact of the black market produced by our own policies. These people can't engage with us fairly, so why is anyone surprised that the ones who bother to engage at all are the ones who unscrupulously take advantage of our hospitality?
- Trying to prevent it from happening is also pure Whac-A-Mole. High-profile articles may get some defense, but have a stroll around random business articles some time. Look at the names in their edit history. Follow the edits. Virtually none of the people collectively taking advantage of this project on a massive scale identify themselves (and the ones that do, in ignorance, don't last long). Contrast their being allowed to identify themselves as businesses. In which model would their edits be subject to more scrutiny? Up there I said "subject to exactly the same content policies [as] the rest of us", because that should be obvious. Would Business X be allowed to add weasel words or uncited claims to [[Business X]]? Of course not. For anyone to argue against allowing business editing on the basis that they would is to make a colossal straw man. If Business X wants it to be known that their widgets are made from the highest grade of unobtainium ever recorded, they can damn well provide a reliable source to say so or forget about it. Why not subject identified businesses to an even stricter grade of requirements than other editors? The sourcing requirements of BLP covers a whole category of article; turn that inside out and make a new policy for a whole category of editors.
- Prohibition is a failure, and Wikipedia needs a 21st Amendment. Mr. Wales, tear down this bright line. — Scott • talk 20:31, 21 July 2014 (UTC)
- While some of Scott's rhetoric is excessive (and I think self-consciously, even archly, so), there is merit to at least one of his observations: (1) We ask editors affiliated with a business and editing about that business to prominently identify themselves; (2) the most prominent way for an editor to display an affiliation would be in his or her username; but (3) if an editor wanting to be fully transparent (or just naively assuming that's the norm) creates User:CorporationXYZeditor, the account will be blocked almost immediately for a bad username. The community has recently declined to change that policy, so so be it, but it's an introductory awkwardness that arises more often that one might imagine (peek at any day's installment of WP:UAA for examples). Newyorkbrad (talk) 20:37, 21 July 2014 (UTC)
- Indeed, it is a policy that I have long thought unwise and not particularly helpful with any meaningful problems. There are other problems in how we deal with corporate editing, too. It would be nice to have a constructive conversation about how to improve that, but such conversations tend to be derailed very quickly by excessive rhetoric and, with you Brad, I believe that is likely self-consciously so.--Jimbo Wales (talk) 21:03, 21 July 2014 (UTC)
- While some of Scott's rhetoric is excessive (and I think self-consciously, even archly, so), there is merit to at least one of his observations: (1) We ask editors affiliated with a business and editing about that business to prominently identify themselves; (2) the most prominent way for an editor to display an affiliation would be in his or her username; but (3) if an editor wanting to be fully transparent (or just naively assuming that's the norm) creates User:CorporationXYZeditor, the account will be blocked almost immediately for a bad username. The community has recently declined to change that policy, so so be it, but it's an introductory awkwardness that arises more often that one might imagine (peek at any day's installment of WP:UAA for examples). Newyorkbrad (talk) 20:37, 21 July 2014 (UTC)
- Again, that doesn't make any sense whatsoever. I have always been very warmly supportive of people who want to approach us in a transparent and ethical fashion, allowing independent community members to make a determination about editorial matters. That isn't "pissing all over" anyone we actually want here. As for the rest, it's just noise rather than coherent arguments. (Tu quoque fallacy, look it up.)--Jimbo Wales (talk) 19:55, 21 July 2014 (UTC)
- Of course, Jimmy, because so very many of them have done that until now. And now that you've decided to publicly piss on them, they'll be even more motivated to take the time to learn our rules and participate here in a beneficial fashion. Flawless logic, Glorious Leader. It's also pretty rich for someone from the WMF to pass comment on "tediously self-serving PR speak", at which your organization excels. — Scott • talk 18:47, 21 July 2014 (UTC)
- This argument is entirely utterly completely 100% unpersuasive. "However, our instance on it being verboten for businesses to officially edit articles about themselves means that we've shut off our access to this quality of information, condemning our articles on businesses to be shallow when they could be rich and engrossing." It is very very easy for archivists and historians employed by brands to interact ethically with Wikipedia. There is no need for them to edit article space directly. And as we know from many many incidents over a long period of time (1) their edits will on average be tediously self-serving PR speak and (2) the press will chew them up for doing it, and rightly so.--Jimbo Wales (talk) 17:48, 21 July 2014 (UTC)
- Employees can write about this stuff, they just cannot do it for the first time in Wikipedia, according to a cardinal content rule, NOR. And they are welcome to share published information on the talk page. Alanscottwalker (talk) 11:38, 18 July 2014 (UTC)
- Whether or not they are usable in articles, images of "company folklore items" should be uploaded to Commons, which has explicitly rejected limitations on paid editing. The annotation pages for these images provide plenty of room for text explanations. Wnt (talk) 12:10, 18 July 2014 (UTC)
- Disclosure I am often a paid editor. The chief problem with the Bright Line is that PR professionals (not historians typically) only "get it right" about 20% of the time. In the face of a COI disclosure, volunteers only get it right about 60% of the time. (yes, I am making up/guessing those statistics). It's basically a coin flip whether the edit will be accepted, even if it is an overt COI edit, or an overt BLP problem.
- The Bright Line is intended to be a single simple rule that is not easily gamed by bad-faith editors hiding behind AGF as they make COI edits, but it is actually more effectively gamed than direct editing ever was.
- Historians would do better editing than PR professionals, however I have a few times received a book from a client written by a historian with the question "will our Wikipedia page look like this?" and found many discrepancies between the book and reliable sources. The corporate historian is recruited to create a slanted version of history CorporateM (Talk) 14:23, 18 July 2014 (UTC)
- Whether or not they are usable in articles, images of "company folklore items" should be uploaded to Commons, which has explicitly rejected limitations on paid editing. The annotation pages for these images provide plenty of room for text explanations. Wnt (talk) 12:10, 18 July 2014 (UTC)
- Employees can write about this stuff, they just cannot do it for the first time in Wikipedia, according to a cardinal content rule, NOR. And they are welcome to share published information on the talk page. Alanscottwalker (talk) 11:38, 18 July 2014 (UTC)
- Is anyone concerned that Scott appears to be proxying for a banned editor? - 2001:558:1400:10:AD5C:C6C0:2EE8:9093 (talk) 15:59, 18 July 2014 (UTC)
- About as concerned as I am with which banned/blocked identity-concealing individual you are, which is to say, not much at all. How about you evaluate Scott's words on their own merit, rather than over-eagerly sniffing a breadcrumb trail like a Loony Tunes bloodhound? Tarc (talk) 16:19, 18 July 2014 (UTC)
- Tarc, the IP is the banned editor. Per the link, he got someone to post the concept here, which in itself not the end of the world, and now he is going out of his way to be obnoxious about it. Newyorkbrad (talk) 16:45, 18 July 2014 (UTC)
- About as concerned as I am with which banned/blocked identity-concealing individual you are, which is to say, not much at all. How about you evaluate Scott's words on their own merit, rather than over-eagerly sniffing a breadcrumb trail like a Loony Tunes bloodhound? Tarc (talk) 16:19, 18 July 2014 (UTC)
- Guess the day isn't complete until Brad thinks he has uncovered 15 layers of socks hiding behind 9 proxies. Tarc (talk) 23:15, 18 July 2014 (UTC)
- Me? I couldn't tell a proxy from a parakeet. Newyorkbrad (talk) 23:19, 18 July 2014 (UTC)
- You sure its not a dead parrot? Spartaz Humbug! 00:41, 19 July 2014 (UTC)
- It's not the proxying for a banned editor that's the problem -- there's some slack allowed on this page for that, I infer -- it's the "Author Your Own Legacy" mindset that comes with it. Authoring your own legacy, or trying to, has a place I guess, but that place is not here, really. After all, Scott, the article you quote from is titled Why Marketing Needs to Hire a Corporate Folklorist. Marketing does, I'm sure. Marketing's great and everybody loves marketing, but it's peripheral at best to what we're trying to do here. "Illustrate the company’s brand promise"... not quite sure what that even means (Google Translate does not yet have Marketing-to-English) but I don't think we're here to illustrate anybody's "brand promise". And definitely not to "articulate a company’s... value to customers and communities" -- in any way, and definitely not in a very real, powerful way. Herostratus (talk) 05:34, 19 July 2014 (UTC)
- Guess the day isn't complete until Brad thinks he has uncovered 15 layers of socks hiding behind 9 proxies. Tarc (talk) 23:15, 18 July 2014 (UTC)
- It's not even that your idea is not worth discussing. It is. It's just that, if you want your ideas to get traction, a couple things to consider are not vetting them thru Mr Author Your Own Legacy and not immediately turning your point into an excuse to beat the same old drum with the same old arguments regarding unfettered corporate editing of the Wikipedia. This makes people suspicious of where you're going with this, and as a simple point of practical politics if nothing else it's unwise.
- As pointed out above, we would love donations to the public domain of corporate internal material (mostly photos, but maybe other materials as well) so we could use them. Photos of the insides of plants (not showing trade secrets of course), photos of notable living employees, photos of company-held historical objects, and so on. Any suggestion for getting these out of company archives is welcome. Providing it doesn't involve advocating sending the Wikipedia down the road to ruination, is all I'm saying.
- (For instance, I'd love to get photos taken from within the Ford plant of the 1932 Ford massacre of demonstrators (4 dead, 22 injured by gunfire). This'd be a fine aid to "managing the collective memory" and "capturing the spirit of the organization" I would think. I suppose the Ford Motor Company Folklorist (if there is one) might have a different idea of what captures the spirit of the organization, though... so I'm not gonna hold my breath on that... and there's the rub, or part of it...) Herostratus (talk) 01:06, 20 July 2014 (UTC)
- The above might have been worth replying to if it hadn't been opened with an insulting paragraph, but it was, so it isn't. — Scott • talk 01:15, 20 July 2014 (UTC)
- Where you see insult, I see good advice. Blustering into a debate misrepresenting other people by bringing up tired and discredited and irrelevant arguments is not helping you towards any goals that you might actually sensibly have. When you act like a jerk, people are not inclined to bend over backwards to find what is useful in what you are saying.--Jimbo Wales (talk) 19:57, 21 July 2014 (UTC)
- So much for "no personal attacks". You do us credit as a figurehead. — Scott • talk 20:34, 21 July 2014 (UTC)
- That isn't especially helpful. Please stop it before you put a Hex on the discussion. (And more seriously, please see my comment above.) Newyorkbrad (talk) 20:39, 21 July 2014 (UTC)
- So much for "no personal attacks". You do us credit as a figurehead. — Scott • talk 20:34, 21 July 2014 (UTC)
- Where you see insult, I see good advice. Blustering into a debate misrepresenting other people by bringing up tired and discredited and irrelevant arguments is not helping you towards any goals that you might actually sensibly have. When you act like a jerk, people are not inclined to bend over backwards to find what is useful in what you are saying.--Jimbo Wales (talk) 19:57, 21 July 2014 (UTC)
- The above might have been worth replying to if it hadn't been opened with an insulting paragraph, but it was, so it isn't. — Scott • talk 01:15, 20 July 2014 (UTC)
- (For instance, I'd love to get photos taken from within the Ford plant of the 1932 Ford massacre of demonstrators (4 dead, 22 injured by gunfire). This'd be a fine aid to "managing the collective memory" and "capturing the spirit of the organization" I would think. I suppose the Ford Motor Company Folklorist (if there is one) might have a different idea of what captures the spirit of the organization, though... so I'm not gonna hold my breath on that... and there's the rub, or part of it...) Herostratus (talk) 01:06, 20 July 2014 (UTC)
Summary — An editor suggested that WP:COI should be waived for the case of a company's agent adding company history information to an article about the company. The suggestion did not gain consensus. --Bob K31416 (talk) 13:26, 22 July 2014 (UTC)
Could you please stop user Robert McClenon
[2] sending us welcoming messages?--37.230.13.71 (talk) 23:10, 20 July 2014 (UTC)
Alles Müller, oder was?
Wikipedia: bringing you Mullergraphs since 2006. 188.27.81.64 (talk) 07:46, 22 July 2014 (UTC)
Lengthy IP Range Blocking affecting millions of T-Mobile Users for 2 posts by a spammer????
It seems some admins have not done due diligence before issuing lengthy range blocking on IP's. A case in point is here: http://en.wikipedia.org/w/index.php?title=Special:Log&page=User%3A172.56.0.0%2F18&type=block These IP's represent millions of T-Mobile users who are know blocked for 3 months. I understand the idea of preventing the type of spam as was done here: http://en.wikipedia.org/w/index.php?title=Rocky_Marciano&direction=prev&oldid=617954600
However Special:Contributions/Materialscientist overreacted to it by issuing a 3 month block affecting millions of T Mobile users. More common sense needs to be applied and some investigating of the IP instead of a knee jerk reaction. What's the purpose of sloppy adminship? A few days block would likely of been sufficient to stop the spamming done on one article only. The IP posted 2X and now millions are blocked for 3 months. If that is not poor adminship what qualifies as such? 208.54.35.169 (talk) 09:16, 22 July 2014 (UTC)
- Crafting a rangeblock is more of an art than exact science (especially after the fall of the Toolserver). Note that the spammer jumped from 172.56.0.0/18(?) to 208.54.0.0/(17-19?), and this happens to be the range of 208.54.35.169, who is complaining above about 172.56.0.0/18. 172.56.0.0/18 has a history of blocks. Materialscientist (talk) 10:59, 22 July 2014 (UTC)
- How about they just...create an account? I really wish we'd give up this sacred cow of IP editing as a right. Tarc (talk) 12:37, 22 July 2014 (UTC)
- Rocky Marciano has no semi-protection or pending changes at the moment, which would prevent obvious spam. How many pages does this spammer target? It is best to avoid locking out sensible editors for the sake of one idiot.--♦IanMacM♦ (talk to me) 13:09, 22 July 2014 (UTC)