Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
thank you erik, and martin for this! currently more than 600 persons express that this story should be resolved by reverting to the state before it started: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Superschutz . while i thought originally who cares, i do think now beeing sorry is expressed best by gesture not words. rupert On Tue, Aug 19, 2014 at 9:37 PM, Martin Rulsch martin.rul...@wikimedia.de wrote: Thank you, Erik, for your clarifications and understanding. Personally, I hope that most anger will calm down now although not everyone will agree with everything that was said or done (e.g. ignoring RfCs under some conditions, using superprotect instead of counting on local procedures to stop wheel warring) and we all can concentrate again on “working together to make Wikimedia projects are more welcome place for readers, authors, and anyone”. As this can only be done with mutual discussions, I'm looking forward to the intensified inclusion of the communities for future software developents as announced. Whether stewards can help here, I cannot tell, but I would abstain myself from getting involved for obvious reasons. Cheers, Martin 2014-08-19 21:12 GMT+02:00 Erik Moeller e...@wikimedia.org: Hi folks, This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html .. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward. I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it. I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page. Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a better hack to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint. Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions: - We intend to undertake a review of our present processes immediately and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices. - As the WMF, we need to improve the process for managing changes that impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users. - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict resolution process. The goal would be to make a final, cross-wiki determination regarding this specific feature, in partnership with the community, within at most 90 days. With regard to the German Wikipedia situation, we’d like to know if stewards want to at all be involved in this process: In a situation like this, it can be helpful to have a third party support the conversation. Stewards are accountable to valid community consensus within the bounds of the Foundation's goals [3], which seems to be precisely
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Tue, Aug 19, 2014 at 2:18 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote: Nonetheless, I'm having difficulty understanding how these two statements: the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, We’re absolutely not saying that WMF simply wants to be able to enforce its decisions can be reconciled. Hi Andy, I think it's clear that we need to develop a social contract that works for both parties. It doesn't work for communities if WMF simply declares an independent decision after a vote or RFC takes place (and yes, we have done so in this instance, and in others in the past). And from WMF's point of view (for reasons we have already articulated several times), it doesn't work to expect that WMF will implement every vote or RFC as-is without negotiation or discussion, and without room to take other factors into account. When we talk about WMF's role, we need to distinguish between technical processes and outcomes. In order to ensure consistency (including on issues like release planning, communications, bug reporting, etc.), WMF needs to manage the configuration and deployment _process_ (e.g. we flip the switches). In order to be able to exercise its leadership role in technology, it needs to have a say in the _outcome_, even if/when there are RFCs/votes asking us to disable a feature. That to me is what the shared power guiding principle means -- we have clear roles and responsibilities, and we share in the decision-making. When we disagree, we need to figure things out together, hear each other, and reason constructively. We don't have good conventions to do that right now. The community vote - WMF responds yes/no or community vote - WMF responds with compromise process is deeply insufficient and one-sided. It's a win/lose process rather than a process for working together. We need to avoid getting to this place to begin with, but we also need to have better answers when we do, as I'm sure we inevitably will again from time to time. This is what we're kicking around on the process ideas page: https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas Specifically, for something like Media Viewer, a lot of the issues we've had to work through relate to community-created technology (!) like custom templates used for certain purposes. In these situations, sometimes the answer may be Actually, what you did here with a template is a horrible idea and you probably shouldn't be doing it that way -- and it's very hard for us to have these conversations honestly if it's in an oppositional context with a group of 200 people. And sometimes we need to support use cases that the community cares very much about, even if our initial reaction is Do we _really_ have to do this?. I think it needs to be much more tightly coupled, co-dependent working relationship through the product's lifecycle so we can work together honestly and with shared expertise. That's true for VE, Flow, etc. as well -- we've tried the light touch community liaison model but I think we need something that brings us even closer together in day to day working practice. And my experience with Wikimedia volunteers is that there are almost always people willing to give their time if they feel it's actually valued in the process. Not tens of hours a week of course (that's why we have paid staff), but enough to stay informed and participate. I could imagine having a process where, for any given project, there's a nomination and lightweight election process that lets people participate in associated communtiy task forces, which have weekly check-ins with the product team and actually meaningfully influence the roadmap. Is this something that people think could work? Has it worked well in other contexts? I think the inter-dependent relationship on technology is really important to appreciate here -- it's something that's very unique to us (because of the countless templates, tools, customizations, etc. created by community members that interact with software we build). You can't have it both ways -- a crazy amount of customizability by the users themselves _and_ a very traditional relationship with software development (ship a finished product to us and then we'll talk -- meanwhile let me add some parameters to this custom template that I expect your product will support from day 1). Erik [1] http://strategy.wikimedia.org/wiki/Task_force -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ 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 Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller e...@wikimedia.org wrote: [1] http://strategy.wikimedia.org/wiki/Task_force I meant to say - the one example where we've tried targeted task forces that I can think of was this one, as part of the strategy process years ago. IIRC some of the task forces were pretty productive, though the integration of their work in the final end product was inconsistent. If product-related task forces actually were part of the process of influencing the backlog, examining data/findings, adding potential requirements, etc., that might be a compelling way to work together. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ 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
Erik, 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. Pine On Aug 19, 2014 11:55 PM, Erik Moeller e...@wikimedia.org wrote: On Tue, Aug 19, 2014 at 11:48 PM, Erik Moeller e...@wikimedia.org wrote: [1] http://strategy.wikimedia.org/wiki/Task_force I meant to say - the one example where we've tried targeted task forces that I can think of was this one, as part of the strategy process years ago. IIRC some of the task forces were pretty productive, though the integration of their work in the final end product was inconsistent. If product-related task forces actually were part of the process of influencing the backlog, examining data/findings, adding potential requirements, etc., that might be a compelling way to work together. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ 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
Pine W skrev 2014-08-20 09:32: Erik, 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 second that question The mediaviewer has never been an issue on the Swedish community. After our layout expert stated it was a good feature for the readers, we editors quickly learned to opt out and continue our editing I also have no problem accepting that the communities do not decide over the UI to our readers. I also see very promising statement from Lila. But i am missing the insight from both Erik and Lila that behind what is being discussed is a key concern. Who decides over the development. And here I believe, as I stated before, that a properly set up Technology Committe is needed in order to ease the tensions in the movement independent of iany mproved processes Anders ___ 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] Brevity
With 11 days remaining in August, I'd like to remind everyone that Wikimedia-l's guidelines[0] ask that subscribers keep their post count below at most 30 per month. This guideline exists to help curb the temptation to weigh in on absolutely every point raised, turning what could otherwise be a carefully considered debate into a rapid-fire argument. (If that's what you're looking for, fear not—I'm sure IRC[1] has you covered.) I know that this month has seen a few contentious topics, but if you see yourself nearing 30 posts (Erik Zachte's ScanMail tool[2] is very helpful, here), perhaps it's worth sparing a moment for pause before clicking reply. In fact, that's probably worth doing even if you aren't topping the charts. Less is sometimes more. Thanks for your attention, Austin [0] https://meta.wikimedia.org/wiki/Wikimedia-l [1] https://meta.wikimedia.org/wiki/IRC/Channels [2] http://www.infodisiac.com/Wikipedia/ScanMail/Wikimedia-l.html ___ 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] Fwd: Accounting software for thematic orgs
Forwarding to the to-be-revived treasurers mailing list. ~ Seb35 --- Message réexpédié--- De: Pine W wiki.p...@gmail.com A: Wikimedia Mailing List Wikimedia-l@lists.wikimedia.org Cc: Sujet: [Wikimedia-l] Accounting software for thematic orgs Date: Wed, 20 Aug 2014 06:54:41 +0200 Hi all, There are online small business accounting software packages. Do any thematic orgs have experience with them? Any recommendations? I am thinking about proposing Quickbooks Online for the Cascadia user group, but as this Forbes article says, there are competitors: http://www.forbes.com/sites/quickerbettertech/2014/01/06/why-your-company-may-dump-quickbooks-this-year/ Thanks, Pine ___ 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] Accounting software for thematic orgs
Hi Pine, When I was treasurer of WMAU we invested in Xero (mentioned in that article). Our primary motivators were allowing all the committee members to be able to examine the books or enter receipts at any time, as most of us were separated by hundreds of kilometres. It worked very well for us, and chopped away a lot of the overhead and risk of maintaining everything on our private Wiki and in Excel spreadsheets and the like. Cheers, Craig Franklin On 20 August 2014 14:54, Pine W wiki.p...@gmail.com wrote: Hi all, There are online small business accounting software packages. Do any thematic orgs have experience with them? Any recommendations? I am thinking about proposing Quickbooks Online for the Cascadia user group, but as this Forbes article says, there are competitors: http://www.forbes.com/sites/quickerbettertech/2014/01/06/why-your-company-may-dump-quickbooks-this-year/ Thanks, Pine ___ 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] Accounting software for thematic orgs
Hi Pine, you may want to evaluate CiviCRM. It is not perfect but supports accounting (rather than just recording donations as before) about a year. The advantage of CiviCRM is the fact that it integrates membership management, mailings, donors management and that it can be used centrally by all the committee members. The setup and customization is not so easy with CiviCRM but there are plenty of people in the movement who gathered some experience with that. /Manuel -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ 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] Accounting software for thematic orgs
Hi Pine, I started off doing the accounts at WMUK several years ago and looked at a fair few different systems, including open source. Initially we used Gnucash, I believe, but because no-one else used it - including our auditors - it was not very useful when we needed to create year end accounts. I also considered CiviCRM after viewing a talk from the Swedish chapter in 2012. However, the talk was not encouraging - CiviCRM needs a *lot *of work to be useable as an accounting system. I would not therefore recommend Gnucash or CiviCRM or any other open source system: you will find it almost impossible to find an accountant who uses them, and also almost impossible to find a CiviCRM developer who is also an accountant! Your auditors will not know how to use the data and will not have the programs to access it, so in the end you will have to pay extra for the free software. In short: open source programs are good for small charity accounts, but the moment you start hiring staff (of any sort), or have fixed assets or non-cash donations, the system does not scale and as a result you will incur large overheads trying to get it to work. You might run into a problem with CiviCRM if you need to generate invoices for a conference you run in three or four years time - will your system be able to handle it, or will you need to upgrade everything at much greater cost? We also looked at Quickbooks, Sage, and a few others. In the end, we picked Sage - not because it was cheap, or because it was ethical - but because it is the UK standard and practically all UK accountants know how to use it. It has a huge support network, and it is scalable from a self-employed person up to an organisation with many thousands of employees. Sage is not used much in the USA though, so Quickbooks may be a better idea for you. My advice to you would be: - Plan for the future - ten year's time. Your solution needs to be scalable with little fuss. - Use something that has a proven track record - don't got for anything like a startup, because you need it supported in future and you can't take the risk. - Cloud-based is good, but the Treasurer really needs to understand what's happening - things should go through him where possible. - Don't be afraid to spend money if money needs to be spent. - Don't be afraid to ask the WMF directly for their advice. They know their stuff and it'd be good if your accounts were run on a similar system to theirs - cheaper in the long run, and you've got someone to turn to if it all breaks. I hope this helps! Feel free to drop me an email if you have any more specific questions. Richard Symonds Wikimedia UK 0207 065 0992 Wikimedia UK is a Company Limited by Guarantee registered in England and Wales, Registered No. 6741827. Registered Charity No.1144513. Registered Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT. United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia movement. The Wikimedia projects are run by the Wikimedia Foundation (who operate Wikipedia, amongst other projects). *Wikimedia UK is an independent non-profit charity with no legal control over Wikipedia nor responsibility for its contents.* On 20 August 2014 10:57, Manuel Schneider manuel.schnei...@wikimedia.ch wrote: Hi Pine, you may want to evaluate CiviCRM. It is not perfect but supports accounting (rather than just recording donations as before) about a year. The advantage of CiviCRM is the fact that it integrates membership management, mailings, donors management and that it can be used centrally by all the committee members. The setup and customization is not so easy with CiviCRM but there are plenty of people in the movement who gathered some experience with that. /Manuel -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ 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] [Wikidata-l] Compare person data
Thanks for this. You might want to filter it, though: For example https://www.wikidata.org/wiki/Q85256 states born in 1606 (no month or day given), but your report at https://www.wikidata.org/wiki/User:Ladsgroup/Birth_date_report2/26 gives it as 1606-01-01, which then conflicts with the date given in Wikipedias (1606-03-18). Wikidata is less precise than Wikipedia here, but not actually wrong. Maybe these cases should be treated separately from the potential errors. Cheers, Magnus On Wed, Aug 20, 2014 at 3:54 PM, Amir Ladsgroup ladsgr...@gmail.com wrote: I started this report, you can find it here https://www.wikidata.org/wiki/User:Ladsgroup/Birth_date_report2. Best On Tue, Aug 19, 2014 at 3:27 PM, Amir Ladsgroup ladsgr...@gmail.com wrote: It's possible and rather easy to add them .just several regexes and list of months in that language are needed. but the issue is no major wikis except these three are using a person data template (Almost all of them have the template but almost none of them are using it widely) If any other wiki is using a person data template widely, I would be happy to implement it. Best On Tue, Aug 19, 2014 at 2:29 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Can we join more Wikipedias to the comparison? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2014-08-19 10:38 GMT+03:00 Gerard Meijssen gerard.meijs...@gmail.com: Hoi, Amir has created functionality that compares data from en.wp de.wp and it.wp. It is data about humans and it only shows differences where they exist. It compares those four Wikipedias with information in Wikidata. The idea is that the report will be updated regularly. The problem we face is: what should it actually look like. Should it just splatter the info on a page or is more needed. At this time we just have data [1]. Please help us with something that works easily for now. Once we have something, it can be prettified and more functional. Thanks, GerardM [1] http://paste.ubuntu.com/8079742/ ___ 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 -- Amir -- Amir ___ Wikidata-l mailing list wikidat...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l ___ 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] @WikipediaZero Twitter account
It's up to Carolynnes team to figure out if they want to use it or not. --tomasz On Wed, Aug 13, 2014 at 10:24 AM, Dan Garry dga...@wikimedia.org wrote: I could be mistaken, but I think Tomasz is the owner. CCing him. Dan On 13 August 2014 11:19, Andy Mabbett a...@pigsonthewing.org.uk wrote: Who owns the @WikipediaZero Twitter account? It's only ever had one post, and that seems a missed opportunity. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ 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 -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ 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
