Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

2014-08-20 Thread rupert THURNER
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

2014-08-20 Thread Erik Moeller
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

2014-08-20 Thread Erik Moeller
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

2014-08-20 Thread Pine W
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

2014-08-20 Thread Anders Wennersten


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

2014-08-20 Thread Austin Hair
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

2014-08-20 Thread Seb35

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

2014-08-20 Thread Craig Franklin
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

2014-08-20 Thread Manuel Schneider
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

2014-08-20 Thread Richard Symonds
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

2014-08-20 Thread Magnus Manske
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

2014-08-20 Thread Tomasz Finc
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