Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hoi, I am happy for you that you think the reader experience is so great in the devils advocate mode. In reality when I read a Wikipedia article because I want information all too often I hate what I get. The fact that it is the best around does not make me like the lack of clarity, the inconsistency of where information is found. All too often articles are written to overcome the power struggle around NPOV and suffer as a result. Erik indicated that WMF has written software predominantly for editors and not for readers. All our projects suffer as a result from not getting to our intended audience and not achieving what we aim to achieve; share in the sum of all knowledge. Remember, our projects are first and foremost about providing information / knowledge to people. We are stuck in the process of producing the data that may once become information. More focus on our end-users, even to the extend of marketing our data is what will get us significantly more readers and consequently achieve our goals more successfully. Thanks, GerardM On 22 August 2014 07:54, rupert THURNER rupert.thur...@gmail.com wrote: Am 22.08.2014 04:18 schrieb Erik Moeller e...@wikimedia.org: On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.p...@gmail.com wrote: I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard. I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it. This all presupposes that we collectively sign up for this whole shared power idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits. If we sign up collectively for shared power, then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations. erik, let me ask a little in a devils advocate style: is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up. in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this. two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience. the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished. the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years. as somebody delivering software i understand your feelings quite well. you get dug into a hole and do not know a good way to get out. introducing additional levels of complexity is a well known strategy. but we all know from our daily lives that we do tend to not like these levels and bureaucracy. erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
one more general level solution would be having more steps: proposing a solution to the community (checking for support), inviting willing testers, after positive feedback introducing to all logged in users, and after positive feedback propagating on the site as a whole. Once the initial support for an idea is established, we can take for granted that the change should happen - but it should be up to feedback to see if the solution is ready, and not up to the developers' calendar (we've all seen what happens when the schedule is the in the case of visual editor premature launch). I think that WMF perhaps takes way too little use of our community as testers, commentators, supporters. If the community was more involved in development plans, it would also not be surprised by solutions which perhaps are important and wise in the log term, but still should not jump out of the box and be perceived as forced. I don't think it makes any sense to perceive WMF as just a servant. But how should we perceive the community? Is it a disorganized mass with no uniform voice, that should be shepherded into accepting solutions? Is it a valuable resource? Is it a full partner in planning, testing and implementing the solutions? I think that a lot of the latter is missing, and the fault is on both sides. But it is mainly up to WMF to change it, as WMF has the structures, staff, and resources to propose procedures there. just my two cents, anyway. dj pundit On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER rupert.thur...@gmail.com wrote: Am 22.08.2014 04:18 schrieb Erik Moeller e...@wikimedia.org: On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.p...@gmail.com wrote: I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard. I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it. This all presupposes that we collectively sign up for this whole shared power idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits. If we sign up collectively for shared power, then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations. erik, let me ask a little in a devils advocate style: is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up. in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this. two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience. the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished. the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years. as
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Thu, Aug 21, 2014 at 10:54 PM, rupert THURNER rupert.thur...@gmail.com wrote: is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up. (...) erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)? Rupert, I always like a good devil's advocate, especially when it doesn't sound devil-ish at all. ;-) Let's start with some facts: - The MediaViewer rollout was very smooth until the deployments to German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case). - As a user, it's trivial to disable Media Viewer. Not quite as easy as we want it to be, but literally a scroll-down and click away, which is more than you can say about most MediaWiki preferences. It's also trivial to skip on a case-by-case basis -- just open an image in a new tab. - Even on de.wp, if you read the comments from people supporting the feature, in the poll leading up to Wikimania (a minority, but not a tiny one - 72 voters in the poll [1]), you'll notice that the reader/editor distinction isn't such a clear one. While many users voted on behalf of readers, others pointed out that they themselves like the fast access to the picture and switch back and forth as needed (opening images in the background when they want to skip the viewer). That was also what we heard from folks at Wikimania, for example, and the generally low opt-out rates support it. - The criticism isn't just about that -- it's about a large number of mostly individually small issues. Generally, the idea that we effectively munge some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it. Users who oppose the feature do not always do so strictly for personal reasons, or many of them would probably be fine to disable it for themselves; they often have criticisms that go beyond their own needs and extend into areas like re-use, licensing information, and creating an environment that draws people into contributing. Editors are not blind to the needs of readers, they just have a low tolerance for imperfections and would prefer to see a product that already addresses all these concerns at the time of release. We understand all that. We've read virtually every comment (surveys, feedback page, votes/RFCs, etc.). I'm not normally as familiar with every product WMF works on but by now I know many of the internals of the damn thing (though Mark probably thanks the GNU deities daily that I've not submitted any patches yet). Change aversion is often [[loss aversion]] - people prefer avoiding losses to making gains, which is why the positive benefits of a new feature tend to be overshadowed quickly by any shortcomings, even if they are (objectively speaking) comparatively small and easily addressed. It's true that we (WMF) should have done more early on to specifically help with template cleanup -- we made some efforts to add machine-readable data to key templates and rally community help, but they were insufficient. This is not strictly an engineering problem - the CommonsMetadata extension works just fine, the documentation is clear, etc. It's an outreach effort that should have accompanied the rollout more systematically. With that said, the needed fixes to templates are fairly trivial (we just worked with de.wp to implement one), while immediately resolving issues with license display for large numbers of files, and help many other applications beyond the viewer. In addition, as previously noted [2], we're testing some pretty significant changes of the UI, including a much more prominent integration of the File: page link, identifying it clearly as the canonical source of metadata. We're not saying You're wrong, we're right - just that we understand the issues pretty well, and we think the main concerns can likely be addressed fairly quickly (and some already have been). In general, we believe that there needs to be at least some allowance for iterating on a release, rather than forcing an immediate revert. If we reason things through together, try things out, look at the results, and we're wrong, well, let's just turn the thing off completely rather than making half-assed config changes in one wiki. Mind you, in responding to the poll on
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 08/21/2014 07:17 PM, Erik Moeller wrote: It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits. Along the same lines (by my reading) a week ago... On 08/14/2014 02:57 AM, Erik Moeller wrote: If you want a WMF that slavishly implements RFCs or votes to disable features upon request, you'll need to petition to replace more than just one person. In fact, you should petition to reduce the staff dramatically, find an administrative ED who has no opinion on what to do, and exclusively focus on platform-level improvements and requests that clearly have community backing. I'd enjoy reading about these very different futures. As a mostly casual observer/fan of the various organizations and individuals of Wikimedia, the futures don't seem necessarily different. On looking forward -- big developments such as Wikidata (some kind of semantic wiki database; yay!), Visual Editor (WYSIWYG editing), Multimedia Viewer (more usable Commons; of these MV addresses the smallest slice of the corresponding ur-wish), and Flow (more usable talk pages) each reflect wishes expressed by many Wikip/medians for almost as long as Wikipedia and Commons have existed, probably your expressions and experiments being among the very earliest. On resources, making reasonably fast progress only on features with strong community backing would require a large paid staff, preferably larger than what exists now. In my limited view, WMF isn't especially visionary nor is it especially authoritarian. What it has uniquely is the ability to do relatively massive fundraising, and thus bring concentrated resources to bear. I don't care about deployment disputes, and probably would never be aware of them if I didn't follow this list and know some more active Wikimedians socially. Hopefully some process is worked out that all in some years see as a great innovation, or minimally, that all can forget there was any dispute about. But I am kind of concerned about what I perceive as an underlying theme, with deployment disputes as a side effect: WMF as a product development organization, some of the most passionate users of its products as obstacles to innovation and optimization. That may be how other top n websites are operated, but that's also how more numerous former top n websites operated (of course I have no data). In the case of commons-based peer production sites like Wikimedia ones, that dynamic seems especially risky on one hand, and on the other, not leveraging the their strengths. If communities aren't looking forward and anticipating where we want to be 3, 5, 10 years from now (presumably facilitated by WMF; I admired the strategy process some years ago but admittedly didn't follow it closely enough to have an informed opinion) that's a serious gap to close. I expect all to muddle through, but seriously I would love to read about (and see fully realized perhaps in new commons-based peer production projects without organizational history) what exciting things WMF would do if users weren't of concern (except as revealed by aggregate data and experiments), and what a somehow user-direct-democracy version would do. For my reading/observing satisfaction, I'd like them to have very different results. Maybe former would quickly implement lessons from gaming, some described by http://www.raphkoster.com/2014/08/12/wikipedia-is-a-game/ (I'd enjoy seeing them all tried in some commons-based peer production system)? Maybe latter would use all that power to reform itself into being predominantly friendly and welcoming (harder to imagine, but I'd love to be surprised)? Or maybe the reverse!? Mike ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Compare person data
Hoi, There is another benefit, when Wikidata is KNOWN to have good data as it is actively comparing its data with other sources, people will get more confidence in the quality of Wikidata. Thanks, Gerard On 21 August 2014 16:26, WereSpielChequers werespielchequ...@gmail.com wrote: re the birth anomalies, we have been running a process for several years now that looks for people alive according to certain wikipedias and dead according to up to 80 others. The format works well and has been broadened to various other anomalies such as being dead but not born. https://meta.wikimedia.org/wiki/Death_anomalies_table The key thing to remember is that when Wikipedias differ you need reliable source to settle the difference. Wikidata may or may not make this sort of thing easier, but my suspicion is that resolving anomalies will improve Wikidata as well as Wikipedia. Regards Jonathan (WereSpielChequers) On 19 Aug 2014, at 22:05, wikimedia-l-requ...@lists.wikimedia.org wrote Message: 1 Date: Tue, 19 Aug 2014 09:04:17 -0400 From: MZMcBride z...@mzmcbride.com To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: Re: [Wikimedia-l] Compare person data Message-ID: d018c23a.422b...@mzmcbride.com Content-Type: text/plain;charset=UTF-8 Gerard Meijssen wrote: What is needed is a report that looks good enough for now and a public ie visible place to put it. Neat idea! There's https://www.wikidata.org/wiki/Wikidata:Database_reports, of course. In my experience, users don't really care what the report is titled or how it looks; they're much more concerned with accurate and up-to-date (read: actionable) report data. One of the benefits of using a wiki page is that wiki pages have pre-built notification structures (watchlists, RSS feeds, IRC feed, and e-mail). To this end, depending on who the relevant audience is of this report, updating multiple pages on local wikis may be a lot more fruitful. MZMcBride ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 08/22/2014 01:54 AM, rupert THURNER wrote: is the conflict not only triggered by a deliverable which was not good enough? Part of the difficulty of that statement is that the very /definition/ of good enough will necessarily vary from individual to individual, with a non-zero segment of editors defining it as absolutely perfect and matching /my/ requirements exactly (and another, just as large segment, calling for any improvement to X is a gain). Regardless of one's opinions on the power dynamics of the situation, or on how to best serve the short- and long-term needs of the community, it seems to me evident that you cannot allow any one segment of the community what amounts to veto power to any attempts at improvement. So the difficulty becomes simply one of finding a way to adjucate. It seems to me that *any* movement in that direction is an improvement, so long as it does not devolve in a simple game of numbers. It needs informed opinion, not popularity polls. -- Marc ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Thanks to the Wikimedia Projects, including for the great idea of the so-called navigation blocks.
Hi all, as you may have seen on the English wikipedia and elsewhere, there are navigation blocks implemented templates like these: * https://en.wikipedia.org/wiki/Template:GNU * https://en.wikipedia.org/wiki/Template:FOSS * https://en.wikipedia.org/wiki/Template:Star_Trek Now, recently, I've contemplated some strategies for allowing people to navigate among various topical https://en.wikipedia.org/wiki/Fan_fiction and https://en.wikipedia.org/wiki/Fan_fiction#Crossovers on my home site, and ended up concluding that implementing such navigation blocks would be the best solution. So I did just that: * http://www.shlomifish.org/humour/Selina-Mandrake/#star_trek_nav_block So I'd like to thank the English wikipedia and other Wikimedia projects, which I've been using, linking or referring to, or even contributing to a little (see http://en.wikipedia.org/wiki/User:Shlomif ) for inspiring this feature and for being wonderful in general. You guys rock! Stay smashing! (And become even more so.) Regards, Shlomi Fish P.S: here's a cute kitten as a token of my gratitude: http://imgur.com/NmQOgTH -- - Shlomi Fish http://www.shlomifish.org/ http://www.shlomifish.org/humour/bits/Can-I-SCO-Now/ - “Can I SCO Now?” There is no IGLU Cabal! None of them could pass the Turing test. But strangely enough a computer program they coded, could. Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 22 August 2014 14:42, Marc A. Pelletier m...@uberbox.org wrote: Part of the difficulty of that statement is that the very /definition/ of good enough will necessarily vary from individual to individual, with a non-zero segment of editors defining it as absolutely perfect and matching /my/ requirements exactly (and another, just as large segment, calling for any improvement to X is a gain). Just recently I had someone seriously claim bah, if Flow doesn't include [obscure feature I like] it won't be fit for purpose in all seriousness. Regardless of one's opinions on the power dynamics of the situation, or on how to best serve the short- and long-term needs of the community, it seems to me evident that you cannot allow any one segment of the community what amounts to veto power to any attempts at improvement. I think it's indisputably clear that, no matter the level of and efforts toward consultation, people will loudly claim it wasn't enough. - d. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Access by Wikimedia volunteers to WMF records about them
I wrote the email below to Lila and the WMF Legal department asking for access to records (and reports) they hold on me, but I'm sad to say that after 3 weeks waiting, I have yet to receive an acknowledgement. As a Wikimania London volunteer I had a moment to speak with Jan-Bart, and some of my Wikimedia Commons uploads were even featured as part of a presentation by WMF Legal on their successes in the past year, so there was plenty of opportunity for us to have the friendly chat I suggested. Can someone recommend if there is a WMF policy on transparency that volunteers can rely on for questions like mine, or does the law in the USA give me any specific rights of access to records or reports the WMF may keep on me that would mean that WMF Legal would do more than stay silent in response to reasonable requests from its established volunteers? Thanks, Fae -- Forwarded message -- From: Fæ fae...@gmail.com Date: Sun, 3 Aug 2014 13:49:45 +0100 Subject: Request for disclosure of all WMF records relating to Fae To: Lila Tretikov l...@wikimedia.org Cc: legal le...@wikimedia.org, Jan-Bart de Vreede jdevre...@wikimedia.org Dear Lila, The Wikimedia Foundation keeps information such as management summaries about me, which have never been shared with me. [Redacted example material] Could you please ensure that all records that the WMF has retained about me are copied to me? It would seem fair that I have the opportunity to both understand what the WMF management and board have available to refer to when discussing my activities for Wikimedia, and that I have a chance to both correct any mistakes in this personal data, or to ask that inappropriate material gets permanently removed from WMF databases. I will be active in both the Wikimania hackerthon and conference in the coming week, should you or an employee wish to informally review this request with me in person, along with my reasons for making the request at this time. ... -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Access by Wikimedia volunteers to WMF records about them
Hi Fae, in the Netherlands it is quite common for this kind of reqeusts to take several weeks (the government usually allows itself up to six weeks to even acknowledge receipt). Given the fact that the legal department was over their heads busy in the past weeks, I am not very surprised it is taking a bit longer. I would first suggest a bit of patience, and maybe send a kind private reminder - before jumping to conclusions. I know 3 weeks sounds like a really long time, but in these times of the year, it really doesn't sound like a long time at all for something that sounds like an unusual request. Maybe it woudl be more constructive continue this conversation if there is a flatout refusal or acceptance? I am confident that you will also update us if you receive a positive response. Best, Lodewijk 2014-08-22 17:06 GMT+02:00 Fæ fae...@gmail.com: I wrote the email below to Lila and the WMF Legal department asking for access to records (and reports) they hold on me, but I'm sad to say that after 3 weeks waiting, I have yet to receive an acknowledgement. As a Wikimania London volunteer I had a moment to speak with Jan-Bart, and some of my Wikimedia Commons uploads were even featured as part of a presentation by WMF Legal on their successes in the past year, so there was plenty of opportunity for us to have the friendly chat I suggested. Can someone recommend if there is a WMF policy on transparency that volunteers can rely on for questions like mine, or does the law in the USA give me any specific rights of access to records or reports the WMF may keep on me that would mean that WMF Legal would do more than stay silent in response to reasonable requests from its established volunteers? Thanks, Fae -- Forwarded message -- From: Fæ fae...@gmail.com Date: Sun, 3 Aug 2014 13:49:45 +0100 Subject: Request for disclosure of all WMF records relating to Fae To: Lila Tretikov l...@wikimedia.org Cc: legal le...@wikimedia.org, Jan-Bart de Vreede jdevre...@wikimedia.org Dear Lila, The Wikimedia Foundation keeps information such as management summaries about me, which have never been shared with me. [Redacted example material] Could you please ensure that all records that the WMF has retained about me are copied to me? It would seem fair that I have the opportunity to both understand what the WMF management and board have available to refer to when discussing my activities for Wikimedia, and that I have a chance to both correct any mistakes in this personal data, or to ask that inappropriate material gets permanently removed from WMF databases. I will be active in both the Wikimania hackerthon and conference in the coming week, should you or an employee wish to informally review this request with me in person, along with my reasons for making the request at this time. ... -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Specifying office action in edit summary?
Hi all, I'm sorry to repeat, but I would like to hear some thoughts on this question. Also added a clarification for one of the lines. On Thu, 21 Aug 2014, at 22:26, svetlana wrote: Hi all. I understand the Engineering folks used superprotect instead of /undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that? I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily? This is worded poorly, I mean - or can entire namespaces be protected and the new user right was intended as a means to easily revoke mediawiki:* access? Svetlana. svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Specifying office action in edit summary?
I think the problem is that your question does not really relate to the subject line, Svetlana. Office actions are specifically directed at content (e.g., removal of specific content for copyvio reasons or court orders). Office actions are almost never undertaken by Engineering staff; it's usually Legal Community Advocacy staff, or rarely another administrative staff member. What you are talking about is something that has only been done very occasionally over the years by Engineering/Operations staff/sysadmins. There has been no designated manner in which those actions should be flagged. One must remember that until the last few years, the majority of individuals who could have taken (and in some cases, did take) such serious action were volunteer sysadmins, so labeling it a WMF action would not have been correct. We also have to remember that many of the systems that developers and engineers work with on a daily basis do not permit edit summaries, so adding what for many of us is an automatic and routine comment is for some of them a rare and unusual event. (Perhaps they should set their work account preferences to be reminded to include an edit summary?) Risker/Anne On 22 August 2014 11:50, svetlana svetl...@fastmail.com.au wrote: Hi all, I'm sorry to repeat, but I would like to hear some thoughts on this question. Also added a clarification for one of the lines. On Thu, 21 Aug 2014, at 22:26, svetlana wrote: Hi all. I understand the Engineering folks used superprotect instead of /undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that? I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily? This is worded poorly, I mean - or can entire namespaces be protected and the new user right was intended as a means to easily revoke mediawiki:* access? Svetlana. svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Proposing a solution to the community should not be the start of the process of involving the community. Developers are better qualified than non-developers to say whether a prom can be solved, and how it can be solved. But the most important steps in the process include deciding what could be improved or replaced, and crucially what priority various changes could have. Developers aren't necessarily the best people to decide that, sometimes their view is an outlier. For example someone took the decision that the Article Feedback Tool was a higherh. How many developers feel bitten when they have an edit conflict? The first stage in the dialogue should be to discuss the coding philosophy. Currently we have some coders who believe that our mission is global, and that we need to support anyone who can get onto the internet; lets call that the EBay/Amazon/Facebook strategy. Others believe that our software should be the best that it could bewe are only going Regards Jonathan Cardy Message: 3 Date: Fri, 22 Aug 2014 08:48:14 +0200 From: Dariusz Jemielniak dar...@alk.edu.pl To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Subject: Re: [Wikimedia-l] Next steps regarding WMF-community disputesabout deployments Message-ID: cadespgvbvtkhp61enkhyx5c-esncfoftpx8f2yv8nqg+jd2...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 one more general level solution would be having more steps: proposing a solution to the community (checking for support), inviting willing testers, after positive feedback introducing to all logged in users, and after positive feedback propagating on the site as a whole. Once the initial support for an idea is established, we can take for granted that the change should happen - but it should be up to feedback to see if the solution is ready, and not up to the developers' calendar (we've all seen what happens when the schedule is the in the case of visual editor premature launch). I think that WMF perhaps takes way too little use of our community as testers, commentators, supporters. If the community was more involved in development plans, it would also not be surprised by solutions which perhaps are important and wise in the log term, but still should not jump out of the box and be perceived as forced. I don't think it makes any sense to perceive WMF as just a servant. But how should we perceive the community? Is it a disorganized mass with no uniform voice, that should be shepherded into accepting solutions? Is it a valuable resource? Is it a full partner in planning, testing and implementing the solutions? I think that a lot of the latter is missing, and the fault is on both sides. But it is mainly up to WMF to change it, as WMF has the structures, staff, and resources to propose procedures there. just my two cents, anyway. dj pundit On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER rupert.thur...@gmail.com wrote: Am 22.08.2014 04:18 schrieb Erik Moeller e...@wikimedia.org: On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.p...@gmail.com wrote: I am curious to hear your thoughts about the proposed Technology Committee. That idea has some community support and had been discussed at some length on the WMF Board Noticeboard. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Access by Wikimedia volunteers to WMF records about them
Hi Fae/Everyone Just to be clear, although the text below is factually correct it implies that the two of us talked about your request at Wikimania, which we did not. We talked for a total of around 60 seconds, most of which was spent on me explaining that I was looking for someon in a hurry, that fact is not relevant with regards to your request so I am not sure why you mention it. The topic below is not within the scope of my governance responsibility and I should not be involved in this all. So please don’t involve me :) Thanks, Jan-Bart PS: As this is me ‘setting the record straight” the odds are small to zero that I will respond to a follow up…. see above On 22 Aug 2014, at 17:06, Fæ fae...@gmail.com wrote: I wrote the email below to Lila and the WMF Legal department asking for access to records (and reports) they hold on me, but I'm sad to say that after 3 weeks waiting, I have yet to receive an acknowledgement. As a Wikimania London volunteer I had a moment to speak with Jan-Bart, and some of my Wikimedia Commons uploads were even featured as part of a presentation by WMF Legal on their successes in the past year, so there was plenty of opportunity for us to have the friendly chat I suggested. Can someone recommend if there is a WMF policy on transparency that volunteers can rely on for questions like mine, or does the law in the USA give me any specific rights of access to records or reports the WMF may keep on me that would mean that WMF Legal would do more than stay silent in response to reasonable requests from its established volunteers? Thanks, Fae -- Forwarded message -- From: Fæ fae...@gmail.com Date: Sun, 3 Aug 2014 13:49:45 +0100 Subject: Request for disclosure of all WMF records relating to Fae To: Lila Tretikov l...@wikimedia.org Cc: legal le...@wikimedia.org, Jan-Bart de Vreede jdevre...@wikimedia.org Dear Lila, The Wikimedia Foundation keeps information such as management summaries about me, which have never been shared with me. [Redacted example material] Could you please ensure that all records that the WMF has retained about me are copied to me? It would seem fair that I have the opportunity to both understand what the WMF management and board have available to refer to when discussing my activities for Wikimedia, and that I have a chance to both correct any mistakes in this personal data, or to ask that inappropriate material gets permanently removed from WMF databases. I will be active in both the Wikimania hackerthon and conference in the coming week, should you or an employee wish to informally review this request with me in person, along with my reasons for making the request at this time. ... -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Access by Wikimedia volunteers to WMF records about them
To avoid tangents, here is my email trimmed to the 2 key points with no background: Can someone recommend if there is a WMF policy on transparency that applies? Does the law in the USA give rights of access to records or reports the WMF may keep on volunteers? Fae ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Specifying office action in edit summary?
Risker wrote: Office actions are almost never undertaken by Engineering staff; it's usually Legal Community Advocacy staff, or rarely another administrative staff member. How should an Engineering Staff member indicate that he'd like an edit undone and not done again? Through an Office Action? One'd think that an edit summary is the only way. Why is it not being used? An undo with appropriate edit summary would also avoid a need in escalating the issue - local sysops would consciously hold off their edit. If they went against an office action, introducing superprotect /then/ could make sense (although I would personally iterate through 2 undos with a massive warning in the second one). Now, in your reply, why do I fail to see a reason why such approach was or is not used? Could you please clarify? Risker wrote: What you are talking about is something that has only been done very occasionally over the years by Engineering/Operations staff/sysadmins. There has been no designated manner in which those actions should be flagged. This doesn't appear to be a problem to me. Sysops surely read edit summaries. (Note how Erik doesn't use a (WMF) account either - he wrote a message and appended 'this is a wmf action' to the end, which /WAS ENOUGH/. Risker wrote: One must remember that until the last few years, the majority of individuals who could have taken (and in some cases, did take) such serious action were volunteer sysadmins, so labeling it a WMF action would not have been correct. OK, some context - doesn't really apply to this case. In this case it was not a volunteer sysadmin. Risker wrote: We also have to remember that many of the systems that developers and engineers work with on a daily basis do not permit edit summaries, so adding what for many of us is an automatic and routine comment is for some of them a rare and unusual event. (Perhaps they should set their work account preferences to be reminded to include an edit summary?) Our Eng Staff don't know how to use wiki software is perhaps a way to tell why they forgot to do it, but it doesn't mean that doing it wouldn't've been a good idea. I might perhaps even suggest going and removing superprotect, and actually going and using an edit summary /instead/, now. It's late, but better late then never. svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
