Re: [Wikimedia-l] Chapters and GLAM tooling

2014-06-26 Thread Pine W
I will add this to my ever-growing list of possible projects for Cascadia.
There are a few other projects under consideration that have received
little WMF support but I feel are movement-aligned and would interest the
public or the contributor base.

In order for Cascadia to work on these projects there will be several steps
such as getting AffCom approval for Cascadia, consensus of the Cascadians
of what we want to do as a group, and finding people with the necessary
technical expertise. I'm speculating that we might hire on a contract basis
for short-term software projects if GAC or the FDC support that approach,
or we might put out an RFP.

In general I would say this sounds like a project we might want to support.
A number of our members have technical, research, or GLAM interests.

Of course, if WMCH wants to do this work and can do it faster than
Cascadia, or someone makes a good proposal to work on this project through
IEG or GSOC/OPW, that is ok. We in Cascadia are still very early in our
development and we can find other work to do if we decide that we want to
support movement-wide projects.

Pine*
* Speaking only in a personal capacity


On Wed, Jun 25, 2014 at 8:54 PM, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 At the Zurich Hackathon, I met with a couple of folks from WM-CH who
 were interested in talking about ways that chapters can get involved
 in engineering/product development, similar to WM-DE's work on
 Wikidata.

 My recommendation to them was to consider working on GLAM-related
 tooling. This includes helping improve some of the reporting tools
 currently running in Labs (primarily developed by the illustrious and
 wonderful Magnus Manske in his spare time), but also meeting other
 requirements identified by the GLAM community [1] and potentially
 helping with the development of more complex MediaWiki-integrated
 tools like the GLAMWiki-Toolset.

 There's work that only WMF is well positioned to do (like feeding all
 media view data into Hadoop and providing generalized reports and
 APIs), but a lot of work in the aforementioned categories could be
 done by any chapter and could easily be scaled up from 1 to 2 to 3
 FTEs and beyond as warranted. That's because a lot of the tools are
 separate from MediaWiki, so code review and integration requirements
 are lower, and it's easier for technically proficient folks to help.

 In short, I think this could provide a nice on-ramp for a chapter or
 chapters to support the work of volunteers in the cultural sector with
 appropriate technology. This availability of appropriate technology is
 clearly increasingly a distinguishing factor for Wikimedia relative to
 more commercial offerings in its appeal to the cultural sector.

 At the same time, WMF itself doesn't currently prioritize work with
 the cultural sector very highly, which I think is appropriate given
 all the other problems we have to solve. So if this kind of work has
 to compete for attention with much more basic improvements to say the
 uploading pipeline or the editing tools, it's going to lose. Therefore
 I think having a cultural tooling team or teams in the larger
 movement would be appropriate.

 I've not heard back from WM-CH yet on this, but I also don't think
 it's an exclusive suggestion, so wanted to put the idea in people's
 heads in case other organizations in the movement want to help with
 it. I do want WMF to solve the larger infrastructure problems, but the
 more specialized tooling is likely _not_ going to be high on our
 agenda anytime soon.

 Thanks,
 Erik

 [1]
 https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf

 --
 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] The tragedy of Commons

2014-06-26 Thread Erik Moeller
On Tue, Jun 17, 2014 at 12:07 PM, Nathan nawr...@gmail.com wrote:

 The problem is the behavior of a certain core set of Commons admins; time
 and time and time again we have it reported here, we see it on Commons.
 While not lawyers, they attempt to be extraordinarily demanding when it
 comes to legal accuracy. Far more than the actual WMF lawyers have
 required, incidentally.

Yes, agreed. Deletion is frequently applied in an overzealous manner
based on arbitrary interpretations and lack of nuance. It would be
appropriate to more frequently apply tags like {{Disputed}} and to
rely more on social contact to resolve incomplete metadata, rather
than aggressively purging content in the fear that a single byte of
potentially non-free content may infect the repository.

It is correct that I proposed Commons as a repository of freely
re-usable media -- indeed, that is a key characteristic which
distinguishes it from other sites and services, as others have pointed
out. I think it's absolutely crucial to maintain that aspect of its
identity. I worry that the creation of any kind of non-free repository
would dramatically alter the incentive structure for contributing to
our projects. Especially when negotiating releases of large
collections, it will be much harder to argue for free licensing if it
becomes trivial to upload and re-use non-free files.

But maintaining that commitment requires that we also maintain a
capacity for nuance in how we enforce it, or we turn into a club of
zealots nobody wants to be part of rather than being effective
advocates for our cause. That includes understanding that some
situations in international copyright law are ambiguous and
unresolved, that some files may present a minimal level of risk and
can reasonably be kept unless someone complains, and that copyright on
all bits that make up a work can be difficult to trace, identify and
document comprehensively and consistently. Moreover, it should include
(in policy and application) an emphasis on communication and
education, rather than deletion and confrontation.

In that way, the problems in the application of Commons policy are not
that different from the problems in the application of policy on
Wikipedia. It's just that Wikipedians who are used to operating under
the regime of Wikipedia's policies frequently get upset when they are
subjected to an entirely different regime. Their experience is not
that different from that of a new user whose article gets speedied
because the source cited to establish its notability doesn't quite
cross the threshold applied by an admin.

In my view, it would be appropriate for WMF to take a more active role
not in the decision-making itself, but in the training of and support
for administrators and other functionaries to ensure that we apply
policy rationally, in a manner that's civil and welcoming. That goes
for these types of deletion decisions just as much as for civility and
other standards of conduct. WMF is now organizationally in a position
where it could resource the consensus-driven development of training
modules for admins across projects to create a more welcoming,
rational environment - on Commons and elsewhere.

Erik

___
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] The tragedy of Commons

2014-06-26 Thread Jeevan Jose
Hi Erik:

Thanks for your comment. I noticed your comment at [[1]] so hope they are
related.

Yes; making proper attributions and satisfying all license requirements are
a bit complicated and time consuming. See my proposal at [[2]].

I requested the help of CC team; but didn't get any response so far.

I requested the help of the WMF legal; Luis Villa (WMF)  commented that Yup,
I understand - it is a difficult situation, and we'd like to help. But
interpreting the license obligations for the public is also tricky for us,
so we're working on it.  [[3]]

Any further help is highly appreciated.


Regards,
Jee

Links:

1.
https://commons.wikimedia.org/wiki/User_talk:Peteforsyth#Some_recent_speedies.
..

2.
https://commons.wikimedia.org/wiki/Commons:Village_pump/Copyright#Propose_to_update_CC_license_tags_to_comply_with_the_new_wordings_in_CC_deeds

3. https://meta.wikimedia.org/wiki/User_talk:LuisV_(WMF)#Attribution


On Thu, Jun 26, 2014 at 11:37 AM, Erik Moeller e...@wikimedia.org wrote:

 On Tue, Jun 17, 2014 at 12:07 PM, Nathan nawr...@gmail.com wrote:

  The problem is the behavior of a certain core set of Commons admins; time
  and time and time again we have it reported here, we see it on Commons.
  While not lawyers, they attempt to be extraordinarily demanding when it
  comes to legal accuracy. Far more than the actual WMF lawyers have
  required, incidentally.

 Yes, agreed. Deletion is frequently applied in an overzealous manner
 based on arbitrary interpretations and lack of nuance. It would be
 appropriate to more frequently apply tags like {{Disputed}} and to
 rely more on social contact to resolve incomplete metadata, rather
 than aggressively purging content in the fear that a single byte of
 potentially non-free content may infect the repository.

 It is correct that I proposed Commons as a repository of freely
 re-usable media -- indeed, that is a key characteristic which
 distinguishes it from other sites and services, as others have pointed
 out. I think it's absolutely crucial to maintain that aspect of its
 identity. I worry that the creation of any kind of non-free repository
 would dramatically alter the incentive structure for contributing to
 our projects. Especially when negotiating releases of large
 collections, it will be much harder to argue for free licensing if it
 becomes trivial to upload and re-use non-free files.

 But maintaining that commitment requires that we also maintain a
 capacity for nuance in how we enforce it, or we turn into a club of
 zealots nobody wants to be part of rather than being effective
 advocates for our cause. That includes understanding that some
 situations in international copyright law are ambiguous and
 unresolved, that some files may present a minimal level of risk and
 can reasonably be kept unless someone complains, and that copyright on
 all bits that make up a work can be difficult to trace, identify and
 document comprehensively and consistently. Moreover, it should include
 (in policy and application) an emphasis on communication and
 education, rather than deletion and confrontation.

 In that way, the problems in the application of Commons policy are not
 that different from the problems in the application of policy on
 Wikipedia. It's just that Wikipedians who are used to operating under
 the regime of Wikipedia's policies frequently get upset when they are
 subjected to an entirely different regime. Their experience is not
 that different from that of a new user whose article gets speedied
 because the source cited to establish its notability doesn't quite
 cross the threshold applied by an admin.

 In my view, it would be appropriate for WMF to take a more active role
 not in the decision-making itself, but in the training of and support
 for administrators and other functionaries to ensure that we apply
 policy rationally, in a manner that's civil and welcoming. That goes
 for these types of deletion decisions just as much as for civility and
 other standards of conduct. WMF is now organizationally in a position
 where it could resource the consensus-driven development of training
 modules for admins across projects to create a more welcoming,
 rational environment - on Commons and elsewhere.

 Erik

 ___
 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] Chapters and GLAM tooling

2014-06-26 Thread Jon Davies
Thanks Erik,
This is certainly something we are keen to work on. I was talking to Magnus
just last night and of course our experience with Europeana has taught us a
lot )I hope we have fully learnt the messages!).
We are undertaking a scoping review of our Development plans at the moment
and this will be part of the consideration.

Jon


On 26 June 2014 04:54, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 At the Zurich Hackathon, I met with a couple of folks from WM-CH who
 were interested in talking about ways that chapters can get involved
 in engineering/product development, similar to WM-DE's work on
 Wikidata.

 My recommendation to them was to consider working on GLAM-related
 tooling. This includes helping improve some of the reporting tools
 currently running in Labs (primarily developed by the illustrious and
 wonderful Magnus Manske in his spare time), but also meeting other
 requirements identified by the GLAM community [1] and potentially
 helping with the development of more complex MediaWiki-integrated
 tools like the GLAMWiki-Toolset.

 There's work that only WMF is well positioned to do (like feeding all
 media view data into Hadoop and providing generalized reports and
 APIs), but a lot of work in the aforementioned categories could be
 done by any chapter and could easily be scaled up from 1 to 2 to 3
 FTEs and beyond as warranted. That's because a lot of the tools are
 separate from MediaWiki, so code review and integration requirements
 are lower, and it's easier for technically proficient folks to help.

 In short, I think this could provide a nice on-ramp for a chapter or
 chapters to support the work of volunteers in the cultural sector with
 appropriate technology. This availability of appropriate technology is
 clearly increasingly a distinguishing factor for Wikimedia relative to
 more commercial offerings in its appeal to the cultural sector.

 At the same time, WMF itself doesn't currently prioritize work with
 the cultural sector very highly, which I think is appropriate given
 all the other problems we have to solve. So if this kind of work has
 to compete for attention with much more basic improvements to say the
 uploading pipeline or the editing tools, it's going to lose. Therefore
 I think having a cultural tooling team or teams in the larger
 movement would be appropriate.

 I've not heard back from WM-CH yet on this, but I also don't think
 it's an exclusive suggestion, so wanted to put the idea in people's
 heads in case other organizations in the movement want to help with
 it. I do want WMF to solve the larger infrastructure problems, but the
 more specialized tooling is likely _not_ going to be high on our
 agenda anytime soon.

 Thanks,
 Erik

 [1]
 https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf

 --
 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




-- 
*Jon Davies - Chief Executive Wikimedia UK*.  Mobile (0044) 7803 505 169
tweet @jonatreesdavies

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).
Telephone (0044) 207 065 0990.

Visit http://www.wikimedia.org.uk/ and @wikimediauk
___
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] Revamped Wikipedia app for Android now live!

2014-06-26 Thread Jon Davies
Thanks Dab - downloaded. The 'night mode' or 'under the blankets' seems a
good idea.


On 25 June 2014 19:28, Dan Garry dga...@wikimedia.org wrote:

 Hi everyone,

 If you love Wikipedia and have an Android phone, you’re in for a treat!
 Today we’ve released a revamped Wikipedia for Android app, now
 available on Google
 Play https://play.google.com/store/apps/details?id=org.wikipedia.

 Our new features include:

- *Speed* – Our new, native app allows you to browse and edit Wikipedia
faster than ever before.
- *Editing* – You can edit Wikipedia on the app. Logged in or logged
out, we thank you for all your contributions.
- *Recent pages* – We provide you with your reading history, so you can
tap as many links as you like without ever getting lost.
- *Saved pages* – You can save select pages for offline reading and
browse them even when you don’t have a data connection.
- *Share* – Use your existing social networking apps to share in the sum
of all human knowledge.
- *Language support* – The app allows you to seamlessly switch to
reading Wikipedia written in any language.
- *Wikipedia Zero* – We’ve partnered with cellular carriers around the
world to provide Wikipedia free of data charges to users in many
 developing
areas.

 Coming soon:

- *Night mode* – We’ve gotten lots of great beta user feedback; one
feature people love is reading Wikipedia in darker environments. The
inverted colour scheme offered by night mode will make that much easier.
- *Discussions* – Talk pages are an important part of Wikipedia for both
new users and experienced editors alike. We’re bringing them to the app.

 This release is just the beginning! We’re still working hard on creating
 new features to make the app the best Wikipedia reading and editing
 experience out there.

 Please help us improve this app by sending a note to our mailing list,
 mobile-android-wikipe...@wikimedia.org.

 Thank you!

 Dan

 --
 Dan Garry
 Associate Product Manager for Platform and 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




-- 
*Jon Davies - Chief Executive Wikimedia UK*.  Mobile (0044) 7803 505 169
tweet @jonatreesdavies

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).
Telephone (0044) 207 065 0990.

Visit http://www.wikimedia.org.uk/ and @wikimediauk
___
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] Chapters and GLAM tooling

2014-06-26 Thread Stéphane Coillet-Matillon
Just as a quick update from WMCH - we are currently discussing our
strategy/priorities for the 2015-20 cycle and yes, we plan to decide over
the Summer whether we want to ramp up our development activities or not.

We will, of course, keep you guys posted.


2014-06-26 10:29 GMT+02:00 Jon Davies jon.dav...@wikimedia.org.uk:

 Thanks Erik,
 This is certainly something we are keen to work on. I was talking to Magnus
 just last night and of course our experience with Europeana has taught us a
 lot )I hope we have fully learnt the messages!).
 We are undertaking a scoping review of our Development plans at the moment
 and this will be part of the consideration.

 Jon


 On 26 June 2014 04:54, Erik Moeller e...@wikimedia.org wrote:

  Hi folks,
 
  At the Zurich Hackathon, I met with a couple of folks from WM-CH who
  were interested in talking about ways that chapters can get involved
  in engineering/product development, similar to WM-DE's work on
  Wikidata.
 
  My recommendation to them was to consider working on GLAM-related
  tooling. This includes helping improve some of the reporting tools
  currently running in Labs (primarily developed by the illustrious and
  wonderful Magnus Manske in his spare time), but also meeting other
  requirements identified by the GLAM community [1] and potentially
  helping with the development of more complex MediaWiki-integrated
  tools like the GLAMWiki-Toolset.
 
  There's work that only WMF is well positioned to do (like feeding all
  media view data into Hadoop and providing generalized reports and
  APIs), but a lot of work in the aforementioned categories could be
  done by any chapter and could easily be scaled up from 1 to 2 to 3
  FTEs and beyond as warranted. That's because a lot of the tools are
  separate from MediaWiki, so code review and integration requirements
  are lower, and it's easier for technically proficient folks to help.
 
  In short, I think this could provide a nice on-ramp for a chapter or
  chapters to support the work of volunteers in the cultural sector with
  appropriate technology. This availability of appropriate technology is
  clearly increasingly a distinguishing factor for Wikimedia relative to
  more commercial offerings in its appeal to the cultural sector.
 
  At the same time, WMF itself doesn't currently prioritize work with
  the cultural sector very highly, which I think is appropriate given
  all the other problems we have to solve. So if this kind of work has
  to compete for attention with much more basic improvements to say the
  uploading pipeline or the editing tools, it's going to lose. Therefore
  I think having a cultural tooling team or teams in the larger
  movement would be appropriate.
 
  I've not heard back from WM-CH yet on this, but I also don't think
  it's an exclusive suggestion, so wanted to put the idea in people's
  heads in case other organizations in the movement want to help with
  it. I do want WMF to solve the larger infrastructure problems, but the
  more specialized tooling is likely _not_ going to be high on our
  agenda anytime soon.
 
  Thanks,
  Erik
 
  [1]
 
 https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf
 
  --
  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




 --
 *Jon Davies - Chief Executive Wikimedia UK*.  Mobile (0044) 7803 505 169
 tweet @jonatreesdavies

 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).
 Telephone (0044) 207 065 0990.

 Visit http://www.wikimedia.org.uk/ and @wikimediauk
 ___
 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, 

Re: [Wikimedia-l] How many volunteers (not editors) does the movement have????

2014-06-26 Thread Federico Leva (Nemo)

ImperfectlyInformed, 26/06/2014 02:14:

I'm surprised no one seems to have mentioned that Part I, question 6 of the
Form 990 which asks for total volunteers. For year 2011, 85,000 was the
number year 2010 has 100,000.


That's just the number of editors taken from WikiStats, as I believe the 
notes to the actual form 990 explain.
You may have missed the movement in the subject line; the form 990 is 
only about WMF properties.


Nemo

___
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] Chapters and GLAM tooling

2014-06-26 Thread Ilario Valdelli
Hi Erik,
I would remember that in IEG or PEG there are several proposals of software
development but every time these proposals don't offer a well defined
approach to the maintenance.

We know that maintenance is an important phase of the software development
and it would be good to know if the software will be developed and will
remain frozen at the last step or if there will be an idea to create at
least a community around it in order to keep it updated and aligned with
any future features that can come from the GLAM community, for instance.

To maintain a software is not mandatory and the open license can assure
that at least another one can take it in charge.

Anyway a GLAM adopting a software can be really worried if this software
becomes outdated, and this risk is higher if the change of this software
can have a big impact, and probably the same reputation of the GLAM
community can receive a worst reputation.

I think that it should be important if some statements can come from the
WMF about the consideration to take care about the *lifecycle* of the
software considering also that this is a cost (and sometimes a higher cost
in comparison with the other phases).

I think that this may help also the IEG and/or the PEG committee to better
evaluate a proposal.

Regards



On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 At the Zurich Hackathon, I met with a couple of folks from WM-CH who
 were interested in talking about ways that chapters can get involved
 in engineering/product development, similar to WM-DE's work on
 Wikidata.

 My recommendation to them was to consider working on GLAM-related
 tooling. This includes helping improve some of the reporting tools
 currently running in Labs (primarily developed by the illustrious and
 wonderful Magnus Manske in his spare time), but also meeting other
 requirements identified by the GLAM community [1] and potentially
 helping with the development of more complex MediaWiki-integrated
 tools like the GLAMWiki-Toolset.

 There's work that only WMF is well positioned to do (like feeding all
 media view data into Hadoop and providing generalized reports and
 APIs), but a lot of work in the aforementioned categories could be
 done by any chapter and could easily be scaled up from 1 to 2 to 3
 FTEs and beyond as warranted. That's because a lot of the tools are
 separate from MediaWiki, so code review and integration requirements
 are lower, and it's easier for technically proficient folks to help.

 In short, I think this could provide a nice on-ramp for a chapter or
 chapters to support the work of volunteers in the cultural sector with
 appropriate technology. This availability of appropriate technology is
 clearly increasingly a distinguishing factor for Wikimedia relative to
 more commercial offerings in its appeal to the cultural sector.

 At the same time, WMF itself doesn't currently prioritize work with
 the cultural sector very highly, which I think is appropriate given
 all the other problems we have to solve. So if this kind of work has
 to compete for attention with much more basic improvements to say the
 uploading pipeline or the editing tools, it's going to lose. Therefore
 I think having a cultural tooling team or teams in the larger
 movement would be appropriate.

 I've not heard back from WM-CH yet on this, but I also don't think
 it's an exclusive suggestion, so wanted to put the idea in people's
 heads in case other organizations in the movement want to help with
 it. I do want WMF to solve the larger infrastructure problems, but the
 more specialized tooling is likely _not_ going to be high on our
 agenda anytime soon.

 Thanks,
 Erik

 [1]
 https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf

 --
 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




-- 
Ilario Valdelli
Wikimedia CH
Verein zur Förderung Freien Wissens
Association pour l’avancement des connaissances libre
Associazione per il sostegno alla conoscenza libera
Switzerland - 8008 Zürich
Wikipedia: Ilario https://meta.wikimedia.org/wiki/User:Ilario
Facebook: Ilario Valdelli https://www.facebook.com/ivaldelli
Twitter: Ilario Valdelli https://twitter.com/ilariovaldelli
Linkedin: Ilario Valdelli http://www.linkedin.com/profile/view?id=6724469
Tel: +41764821371
http://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, 

Re: [Wikimedia-l] Revamped Wikipedia app for Android now live!

2014-06-26 Thread Andy Mabbett
On 26 June 2014 03:18, Brion Vibber bvib...@wikimedia.org wrote:
 On Wed, Jun 25, 2014 at 6:57 PM, Andy Mabbett a...@pigsonthewing.org.uk
 wrote:

 On Jun 26, 2014 2:16 AM, Sage Ross ragesoss+wikipe...@gmail.com wrote:
  You can enter an edit summary. Either choose one of the predefined
 options
  for how you improved the page, or pick other to enter a manual edit
  summary.

 Where?

 Since phone screens are small, you may have noticed that the editing
 process is broken up over a couple of separate steps.

Of course.

 The preview stage
 gives you a chance to select some 'canned' brief edit summaries, or select
 'other' and input your own.

 Here's a screen recording I just made of the process:

 https://www.mediawiki.org/wiki/File:Adding_an_edit_summary_in_Wikipedia_Android_app_version_2.ogv

Thank you. I didn't see the options (buttons) for pre-selected
summaries, nor the Other option.

On further experimentation, they are hidden above the top of the
screen, and I need to scroll up to see them.

I'm using the native browser on an Android 2.3.5 device.

[As a matter of interest, what software did you use to capture the video?]

-- 
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

Re: [Wikimedia-l] Revamped Wikipedia app for Android now live!

2014-06-26 Thread Jan Ainali
2014-06-26 12:22 GMT+02:00 Andy Mabbett a...@pigsonthewing.org.uk:

 On 26 June 2014 03:18, Brion Vibber bvib...@wikimedia.org wrote:
  On Wed, Jun 25, 2014 at 6:57 PM, Andy Mabbett a...@pigsonthewing.org.uk
 
  wrote:
 
 Thank you. I didn't see the options (buttons) for pre-selected
 summaries, nor the Other option.

 On further experimentation, they are hidden above the top of the
 screen, and I need to scroll up to see them.

 I'm using the native browser on an Android 2.3.5 device.


Then you are not using the app that this thread is talking about?

/Jan
___
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] Chapters and GLAM tooling

2014-06-26 Thread Liam Wyatt
Dear Erik,
(Also copying in the Cultural Partners and GLAMwiki Toolset mailing lists
as Erik's email below is directly is related to them).

Thank you for this email with the explicit invitation for groups in the
Wikimedia movement to directly take responsibility for supporting the
technology needs of GLAM partnerships. Different groups in the movement
have different capacities and different areas of priority - and that is how
it should be :-) We each need to try and 'bite off what we can chew' in a
way that is coordinated, mutually beneficial, and not a duplication of each
others' efforts.

To that end...
Over the last couple of years *Europeana*[1] has been increasingly involved
in supporting tech development for mediawiki that is specifically targeted
at addressing the needs of the GLAMwiki community. I note that the report
you linked to on the stats that GLAMs want[1] and also the GLAMwiki Toolset
for mass multimedia upload which you also mentioned[2] are both
*Europeana* projects
- in collaboration with several European Wikimedia Chapters.

On behalf of *Europeana *I would like to confirm that we wish to become
even more involved in this area and has the full intention of supporting
further development in partnership with interested Chapters when possible.
In the fullness of time, we intend to apply for a WMF grant in order to
enable precisely that.

On the mediawiki.org discussion page for the 2014/15 Engineering goals
there has been a fair bit of discussion about GLAM-related projects that
are not in the WMF's own plans[4]. Fabrice, as process owner for the
Multimedia section of those goals, has proposed on that talkpage a couple
of meetings of interested parties to discuss how we can all work together
effectively on this, notably in person at Wikimania, an offer which we
definitely accept :-) I also agree with Illario's point that formalising WMF
support for externally-developed software is an important criteria in any
grant decisions and for organisational reputation. Fortunately Fabrice has
specifically addressed this issue relating specifically to the GLAMwiki
Toolset which is very helpful.[5]

Sincerely,
Liam / Wittylama
GLAMWIKI coordinator, Europeana.

[1] http://pro.europeana.eu/
[2] https://upload.wikimedia.org/wikipedia
/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.
pdf
[3] https://commons.wikimedia.org/wiki/Commons:GLAMwiki_Toolset_Project
[4] https://www.mediawiki.org/wiki/Talk:Wikimedia
_Engineering/2014-15_Goals#Image_view_analytics
[5] https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2014-15_Goals#
GLAMwiki_Toolset

wittylama.com
Peace, love  metadata


On 26 June 2014 05:54, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 At the Zurich Hackathon, I met with a couple of folks from WM-CH who
 were interested in talking about ways that chapters can get involved
 in engineering/product development, similar to WM-DE's work on
 Wikidata.

 My recommendation to them was to consider working on GLAM-related
 tooling. This includes helping improve some of the reporting tools
 currently running in Labs (primarily developed by the illustrious and
 wonderful Magnus Manske in his spare time), but also meeting other
 requirements identified by the GLAM community [1] and potentially
 helping with the development of more complex MediaWiki-integrated
 tools like the GLAMWiki-Toolset.

 There's work that only WMF is well positioned to do (like feeding all
 media view data into Hadoop and providing generalized reports and
 APIs), but a lot of work in the aforementioned categories could be
 done by any chapter and could easily be scaled up from 1 to 2 to 3
 FTEs and beyond as warranted. That's because a lot of the tools are
 separate from MediaWiki, so code review and integration requirements
 are lower, and it's easier for technically proficient folks to help.

 In short, I think this could provide a nice on-ramp for a chapter or
 chapters to support the work of volunteers in the cultural sector with
 appropriate technology. This availability of appropriate technology is
 clearly increasingly a distinguishing factor for Wikimedia relative to
 more commercial offerings in its appeal to the cultural sector.

 At the same time, WMF itself doesn't currently prioritize work with
 the cultural sector very highly, which I think is appropriate given
 all the other problems we have to solve. So if this kind of work has
 to compete for attention with much more basic improvements to say the
 uploading pipeline or the editing tools, it's going to lose. Therefore
 I think having a cultural tooling team or teams in the larger
 movement would be appropriate.

 I've not heard back from WM-CH yet on this, but I also don't think
 it's an exclusive suggestion, so wanted to put the idea in people's
 heads in case other organizations in the movement want to help with
 it. I do want WMF to solve the larger infrastructure problems, but the
 more specialized tooling is 

Re: [Wikimedia-l] Chapters and GLAM tooling

2014-06-26 Thread David Cuenca
Erik (and others), is there any coordination page where groups could place,
take, or discuss requests for development or requests for maintenance?

I saw often that sometimes the hard-to-achieve consensus is found, but
there is no way to evaluate the idea further. What now happens is:
- several development proposals materialize through different channels
(community, user groups, idea lab, RFCs, etc)
- there is a general consensus about project A
- limbo or an IEG, but as Ilario says, that doesn't guarantee its
future viability or integration with current or planned workflows, or
availability of resources for maintenance

It would be more rational to have a further step in the pipeline where
development ideas could be commented, shot down, or approved for further
commitment by the ones who actually can understand how they fit in the
broader product management/life-cycle context (engineering? PMs?
chapters?).
There are often community ideas that on first sight look great, but when
you think about the potential problems, implications, costs, or stepping on
the toes of other developments, that it is more rational not to start them
or delay them until certain conditions are met. But no voice is heard, and
that causes frustration and a sense of disconnection in the community, when
just a single statement this shouldn't be done because X, would make
everyone more aware of the limits.
And the opposite too, when some idea gather community support and is
green-lighted for further commitment, that would make chapters or other
organizations more confident about what is wanted and how.

Micru


On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 At the Zurich Hackathon, I met with a couple of folks from WM-CH who
 were interested in talking about ways that chapters can get involved
 in engineering/product development, similar to WM-DE's work on
 Wikidata.

 My recommendation to them was to consider working on GLAM-related
 tooling. This includes helping improve some of the reporting tools
 currently running in Labs (primarily developed by the illustrious and
 wonderful Magnus Manske in his spare time), but also meeting other
 requirements identified by the GLAM community [1] and potentially
 helping with the development of more complex MediaWiki-integrated
 tools like the GLAMWiki-Toolset.

 There's work that only WMF is well positioned to do (like feeding all
 media view data into Hadoop and providing generalized reports and
 APIs), but a lot of work in the aforementioned categories could be
 done by any chapter and could easily be scaled up from 1 to 2 to 3
 FTEs and beyond as warranted. That's because a lot of the tools are
 separate from MediaWiki, so code review and integration requirements
 are lower, and it's easier for technically proficient folks to help.

 In short, I think this could provide a nice on-ramp for a chapter or
 chapters to support the work of volunteers in the cultural sector with
 appropriate technology. This availability of appropriate technology is
 clearly increasingly a distinguishing factor for Wikimedia relative to
 more commercial offerings in its appeal to the cultural sector.

 At the same time, WMF itself doesn't currently prioritize work with
 the cultural sector very highly, which I think is appropriate given
 all the other problems we have to solve. So if this kind of work has
 to compete for attention with much more basic improvements to say the
 uploading pipeline or the editing tools, it's going to lose. Therefore
 I think having a cultural tooling team or teams in the larger
 movement would be appropriate.

 I've not heard back from WM-CH yet on this, but I also don't think
 it's an exclusive suggestion, so wanted to put the idea in people's
 heads in case other organizations in the movement want to help with
 it. I do want WMF to solve the larger infrastructure problems, but the
 more specialized tooling is likely _not_ going to be high on our
 agenda anytime soon.

 Thanks,
 Erik

 [1]
 https://upload.wikimedia.org/wikipedia/commons/a/a2/Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf

 --
 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




-- 
Etiamsi omnes, ego non
___
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] Revamped Wikipedia app for Android now live!

2014-06-26 Thread Andy Mabbett
On 26 June 2014 12:02, Jan Ainali jan.ain...@wikimedia.se wrote:

 I'm using the native browser on an Android 2.3.5 device.

 Then you are not using the app that this thread is talking about?

Doh! Sorry, I'm using *the app* under Android 2.3.5.

-- 
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

[Wikimedia-l] Open Letter to Lila Regarding Access to Non-Public Information Policy

2014-06-26 Thread Trillium Corsage
Dear Ms. Tretikov,


Would you please speak on the new revision of the Access to Non-Public 
Information policy? Can you express your objection to it? Can you express your 
support of it? You'll find it here:

http://meta.wikimedia.org/wiki/Access_to_nonpublic_information_policy

This governs the conditions by which the WMF grants access to potentially 
personally-identifying data such as IPs and web-browser profiles of Wikipedia 
editors. It grants these to particular administrative participants, for example 
checkusers and oversighters and arbitrators, of the various communities, for 
example the Wikipedias of various languages.

Under the terms of the prior access policy, those administrative participants 
were required to send a fax or scanned copy of an identification document. 
Editors were led to believe that the WMF kept record of who these people 
actually were. It was repeatedly claimed that they had identified to WMF. 
This soothed the concerns of editors like me that thought, okay, well at least 
someone knows who they are. The truth was that a WMF employee marked a chart of 
usernames only that the administrative participant's ID showed someone 18 or 
over, and then shredded or otherwise destroyed those records. The phrase that 
so-and-so has identified to WMF or is identified to WMF was so commonly 
stated, including by the WMF, that I regard it as a great deception and 
betrayal that it really was shredding and destroying the identifications.

The new policy is even worse. It abandons the mere pretense of an 
identification. So while it goes the wrong direction, at least it ceases to 
deceive. All it calls for now is an email address, an assertion that the person 
is 18 or over, and an assertion that the owner of the email account has read a 
short confidentiality agreement. The person need not provide a real name. You 
are well aware that various web-email services offer basically untraceable 
email addresses. You are well aware that only a named person can enter into 
agreement on confidentiality. An agreement by a Wikipedia username with an 
untraceable email address is not only unenforceable, it is a ludicrous 
proposition.

The webpage says the policy is not in effect yet. I urge you to reject it as 
written and instead have it amended to actually require identification for 
those faceless entities you prepare to turn loose with potentially cyberstalker 
tools.

Whatever your stance, I do call on you to speak on the question. Say yea, say 
nay, or say not my concern, but at least speak.

Trillium Corsage  

___
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] The tragedy of Commons

2014-06-26 Thread billinghurst
Erik Moeller erik@... writes:

 
 On Tue, Jun 17, 2014 at 12:07 PM, Nathan nawrich at gmail.com wrote:
 
  The problem is the behavior of a certain core set of Commons admins; time
  and time and time again we have it reported here, we see it on Commons.
  While not lawyers, they attempt to be extraordinarily demanding when it
  comes to legal accuracy. Far more than the actual WMF lawyers have
  required, incidentally.
 
[snip]
 
 In that way, the problems in the application of Commons policy are not
 that different from the problems in the application of policy on
 Wikipedia. It's just that Wikipedians who are used to operating under
 the regime of Wikipedia's policies frequently get upset when they are
 subjected to an entirely different regime. Their experience is not
 that different from that of a new user whose article gets speedied
 because the source cited to establish its notability doesn't quite
 cross the threshold applied by an admin.
 
 In my view, it would be appropriate for WMF to take a more active role
 not in the decision-making itself, but in the training of and support
 for administrators and other functionaries to ensure that we apply
 policy rationally, in a manner that's civil and welcoming. That goes
 for these types of deletion decisions just as much as for civility and
 other standards of conduct. WMF is now organizationally in a position
 where it could resource the consensus-driven development of training
 modules for admins across projects to create a more welcoming,
 rational environment - on Commons and elsewhere.
 
 Erik
 

Refreshing approach Erik.  It would good to see if there could be a
continued conversation about this, maybe something at Wikimania.

I say refreshing, as it follows a similar user talk page conversation at
Commons that discussed the workload for admins trying to manage just the
daily uploads. Part of the reflection was that it was better to be a little
overzealous in the policing to maintain the quality, and to maintain a
curated collection, making it significantly better than flickr, and making
the collection meaningful.

To me it requires multi-pronged approach. You identified that more can done
to support admins. We still have more to do educate users, and the tools
that we have now make an upload easy, however, does it do sufficient to
inform, and does it do enough to provide a framework to ensure that the
added works are within scope. Is there more we can do to make some of the
administrative tasks easier, so admins feel less squeezed for time, and more
able to be supportive rather than squeezed.

Regards, Billinghurst


___
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] The tragedy of Commons

2014-06-26 Thread Pete Forsyth
On Tue, Jun 17, 2014 at 12:06 PM, Samuel Klein meta...@gmail.com wrote:

 On Tue, Jun 17, 2014 at 2:19 PM, George Herbert
 george.herb...@gmail.com wrote:

  the project and world benefit from [Commons] existing as is.  But we
 need an
  alternative to support the educational mission, reasonable inter-project
 reuse,
  and end the endless deletion wars.

 Yes, this.   With highly visible guidance for licensing/use.


If people are excited about starting up a whole new project, that's fine by
me. I think you'll find that donors attracted to the free knowledge
aspect of our vision  mission statements might be a little tough to
persuade, but if you want to try, have at it.

Still, I have to wonder: are the considerable financial, human, and
technical resources something like this would take justified? Why not
simply create the visible guidance SJ requests on each wiki (presumably as
Exemption Doctrine Policies), and enable a software feature that permits
including an image from elsewhere on the web? Wouldn't that accomplish the
same results, with vastly less effort, less expense, and less distraction
to existing communities?

Uncommons is a charming name.


I have to agree on this point :)

Pete
[[User:Peteforsyth]]
___
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] The tragedy of Commons

2014-06-26 Thread David Gerard
On 26 June 2014 23:17, Pete Forsyth petefors...@gmail.com wrote:

 If people are excited about starting up a whole new project, that's fine by
 me. I think you'll find that donors attracted to the free knowledge
 aspect of our vision  mission statements might be a little tough to
 persuade, but if you want to try, have at it.


The more querulous Commons admins are treating this is not provably
100% URAA safe as equivalent to fair-use free-for-all, often seguing
between the two in the same email. This is equivocation of a
particularly unhelpful sort. Speaking as an unreconstructed
Stallmanite, I say what on earth.


- 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

Re: [Wikimedia-l] The tragedy of Commons

2014-06-26 Thread Pete Forsyth
On Thu, Jun 26, 2014 at 3:19 PM, David Gerard dger...@gmail.com wrote:

 On 26 June 2014 23:17, Pete Forsyth petefors...@gmail.com wrote:

  If people are excited about starting up a whole new project, that's fine
 by
  me. I think you'll find that donors attracted to the free knowledge
  aspect of our vision  mission statements might be a little tough to
  persuade, but if you want to try, have at it.


 The more querulous Commons admins are treating this is not provably
 100% URAA safe as equivalent to fair-use free-for-all, often seguing
 between the two in the same email. This is equivocation of a
 particularly unhelpful sort. Speaking as an unreconstructed
 Stallmanite, I say what on earth.


David, I'm not sure how your message is supposed to connect to mine?
* I'm not an admin on Commons, not sure if you intended to lump me in there
* I have no position on URAA and don't think it's particularly germane to
this topic

My comments in this thread have, I think quite clearly and consistently,
been in response to George's proposal of Uncommons, a site which would
host copyright materials for the purpose of fair use. URAA files would not
be a particularly interesting subset of the copyrighted files that could
live on such a site (or, for that matter, on Flickr etc, in the absence of
a DMCA complaint from a rights-holder.)

So -- who was this addressed to, if not me? What did my message have to do
with URAA, or with querulous admins?

Pete
___
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] The tragedy of Commons

2014-06-26 Thread Pete Forsyth
On Wed, Jun 25, 2014 at 11:07 PM, Erik Moeller e...@wikimedia.org wrote:

 than aggressively purging content in the fear that a single byte of
 potentially non-free content may infect the repository.


You're attacking a straw man. I hope you do not sincerely believe anybody
acts out of such a childish fear. Rather, we have committed volunteers at
Commons who take seriously our commitment to the world, to provide a
repository of files that can be (pretty) reliably reused under a free
license, or as public domain materials. Maintaining the integrity of the
collection, in the face of literally hundreds of problematic uploads every
single day, is a big job, and certainly some less-than-ideal decisions will
be made along the way.

Apart from the moaning I see on this email list, I generally hear good
things from those who visit Wikimedia Commons. Tragedy? Citation needed,
for real.

I think it's absolutely crucial to maintain that aspect of its identity.


So what is your proposal for how to effectively curate the firehose of good
and bad content that is uploaded to Commons day by day, hour by hour,
minute by minute? We have a collection of processes that has been good
enough to get us to where we are today. I don't think anybody believes it's
perfect, but it's gotten us this far. What, pray tell, would be the better
approach? Do you really think that if you present a better idea, it will be
rejected? Do you think we *enjoy* sifting through the details of a zillion
files, and comparing them to a zillion copyright laws, personality rights
laws, FOP laws, etc.? I guess I can only speak for myself, but I'd much
rather be creating content than curating it. But curation is the glaring,
everyday need at Commons, so I pitch in.

It's also absolutely crucial to keep my house from turning into a garbage
dump...which is why I take the garbage out every week.

But maintaining that commitment requires that we also maintain a  capacity
 for nuance in how we enforce it, or we turn into a club of zealots nobody
 wants to be part of rather than being effective advocates for our cause.


Good God, Erik. Seriously, with the name-calling? Seriously? I don't know
why you did it to begin with, but since you have, please share with us who
the zealots are, and give some evidence of zealous behavior. If the
zealotry is as obvious as you seem to assume, we should have no trouble
running those ne'erdowells out on a rail.

But the reality, I think, is much more straightforward: this club of
zealots is a figment of your imagination.

-Pete
[[User:Peteforsyth]]
___
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] Invitation to WMF June 2014 Metrics Activities Meeting: Thursday, July 3, 18:00 UTC

2014-06-26 Thread Praveena Maharaj
Dear all,
The next WMF metrics and activities meeting will take place on Thursday,
July 3, 2014 at 6 PM UTC (11 AM PDT). The IRC channel is #wikimedia-office
on irc.freenode.net and the meeting will be broadcast as a live YouTube
stream.

The current structure of the meeting is:

* Welcoming recent hires
* Update and QA with the Executive Director, if available
* Review of key metrics including the monthly report card, but also
specialized reports and analytic
* Review of financials
* Brief presentations on recent projects, with a focus on highest priority
initiatives

Please review
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings for further
information about how to participate.

We’ll post the video recording publicly after the meeting.

*** *Due to preparation for Wikimania 2014
http://wikimania2014.wikimedia.org/wiki/Main_Page, the August metrics
meeting has been rescheduled to July 31, 2014 at 6 PM UTC (11 AM PDT).
We'll send a separate invitation one week prior to this date*. ***

Thank you,
Praveena


-- 
Praveena Maharaj
Executive Assistant to the VP of Engineering  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] Open Letter to Lila Regarding Access to Non-Public Information Policy

2014-06-26 Thread Luis Villa
Hi, Trillium-

As I pointed out to you the last time we discussed the privacy
policy[1], this issue (and the rest of the policy) were discussed
extensively with the community, with the board, and with the previous
Executive Director. It was then approved by the Board.

This particular topic was discussed particularly thoroughly, with a
separate consultation and additional discussion with the Board. We did
all that because, as we said in our blog post on the topic[2], this
was a tough question that required everyone involved to balance
difficult privacy concerns with the risks and practical difficulties
of identifying volunteers. There was no magical answer that could
please everyone, despite sincere efforts to find creative solutions
informed by several years of experience building and operating the
previous policy.

Since we made that post (and since the Board approved the decision)
nothing has changed. The factors being balanced are still difficult,
and Legal would still come down the same way we did in February (when
we finished the public consultation) and April (when we presented our
recommendation to the Board).

Perhaps when we next look at the question in a few years the facts
will have substantially changed and it will make sense to revisit this
decision and tighten the requirements. But right now, within months of
board approval after a lot of discussion, is not that time.

For what it is worth-
Luis

[1] https://www.mail-archive.com/wikimedia-l@lists.wikimedia.org/msg12552.htm
[2] http://blog.wikimedia.org/2014/02/14/a-new-access-to-nonpublic-information/

P.S. Tangentially, and speaking mostly for myself, I want to thank the
many Wikimedians I've talked with in the past ~18 months who have been
patient and supportive as we try our best to talk with you, weigh
costs and benefits with you, and make difficult decisions - not just
about privacy but also about many other things large and small. We'd
love to be perfect, have infinite time and infinite resources and
infinite patience, or no hard problems. Since we don't, we have to
just try our best. I'm grateful for and deeply appreciate all the
people who understand that and have worked with us in patient good
faith to move ahead the mission we all share. Corny, I know, but true.
:)

On Thu, Jun 26, 2014 at 9:06 AM, Trillium Corsage
trillium2...@yandex.com wrote:
 Dear Ms. Tretikov,


 Would you please speak on the new revision of the Access to Non-Public 
 Information policy? Can you express your objection to it? Can you express 
 your support of it? You'll find it here:

 http://meta.wikimedia.org/wiki/Access_to_nonpublic_information_policy

 This governs the conditions by which the WMF grants access to potentially 
 personally-identifying data such as IPs and web-browser profiles of Wikipedia 
 editors. It grants these to particular administrative participants, for 
 example checkusers and oversighters and arbitrators, of the various 
 communities, for example the Wikipedias of various languages.

 Under the terms of the prior access policy, those administrative participants 
 were required to send a fax or scanned copy of an identification document. 
 Editors were led to believe that the WMF kept record of who these people 
 actually were. It was repeatedly claimed that they had identified to WMF. 
 This soothed the concerns of editors like me that thought, okay, well at 
 least someone knows who they are. The truth was that a WMF employee marked a 
 chart of usernames only that the administrative participant's ID showed 
 someone 18 or over, and then shredded or otherwise destroyed those records. 
 The phrase that so-and-so has identified to WMF or is identified to WMF 
 was so commonly stated, including by the WMF, that I regard it as a great 
 deception and betrayal that it really was shredding and destroying the 
 identifications.

 The new policy is even worse. It abandons the mere pretense of an 
 identification. So while it goes the wrong direction, at least it ceases to 
 deceive. All it calls for now is an email address, an assertion that the 
 person is 18 or over, and an assertion that the owner of the email account 
 has read a short confidentiality agreement. The person need not provide a 
 real name. You are well aware that various web-email services offer basically 
 untraceable email addresses. You are well aware that only a named person can 
 enter into agreement on confidentiality. An agreement by a Wikipedia username 
 with an untraceable email address is not only unenforceable, it is a 
 ludicrous proposition.

 The webpage says the policy is not in effect yet. I urge you to reject it as 
 written and instead have it amended to actually require identification for 
 those faceless entities you prepare to turn loose with potentially 
 cyberstalker tools.

 Whatever your stance, I do call on you to speak on the question. Say yea, 
 say nay, or say not my concern, but at least speak.

 Trillium Corsage

 

Re: [Wikimedia-l] Wicnik reminder

2014-06-26 Thread Pharos
Great to see that this celebration of the picnic anyone can edit is
spreading across the USA, and now also in the Netherlands!

As a reminder, the spelling is actually Wiknic as is in  Wik(i-pic)nic.

It's not too late to organize your own edition of the Great American Wiknic
(or an international variant), for July 6 or another date!

And we now have this shortcut domain:

http://wiknic.org

Thanks,
Pharos


On Mon, Jun 23, 2014 at 4:37 PM, R W romaine.w...@gmail.com wrote:

 Brilliant idea !!

 Therefore we organize also a Wicnik in the south of Netherlands, so also
 Belgians, Germans and whoever is in the neighbourhood can join!

 With sun outside, with rain inside. Dutch pancakes will be baked and
 stroopwafels will be available. Would be nice if everyone brings some food,
 drink and more with him/her to share.

 Time: 13:00 - 17:00 (and later)
 Address: Dominee Theodor Fliednerstraat‎, 5631 BM Eindhoven, the
 Netherlands
 Coördinates: 51.455585, 5.488054
 Distance: 15 minutes walk from train station Eindhoven + 2 bus stops
 By car: 500 parking spaces

 Signing up for it is welcomed, but not required:

 https://nl.wikipedia.org/wiki/Wikipedia:Ontmoeten#Zondag_6_juli:_Wiki-picknick_Eindhoven

 If there are any questions: feel free to ask!

 Romaine





 2014-06-23 21:08 GMT+02:00 Pine W wiki.p...@gmail.com:

  This is a reminder mostly for US Wikimedians and US-based WMF office
  employees but also in case Wikimedians in other parts of the world want
 to
  join us.
 
  Wicnik, Wikimedia's annual summer picnic event, is happening again this
  year. Are you signed up to participate? Bring food, sports equipment,
  sunscreen, and/or your significant other(s).
 
 
  So far there are Wicniks planned for these locations:
 
  Cape Cod, Massachusetts - happened already
  New York City, New York - July 6
  Frederick, Maryland - July 6
  Washington, DC - July 13
  Detroit, Michigan - July 6
  Evansville/Bloomington, Indiana - date TBD
  Chicago, Illinois - July 12
  St Louis, Missouri - July 6
  St Paul, Minnesota - July 6
  Arvada, Colorado - July 6
  Seattle, Washington - July 6
  San Francisco, California - July 6
  Los Angeles, California - July 6
 
  Under discussion:
 
  Pittsburgh, Pennsylvania
  Portland, Oregon
 
  Sign up at https://en.wikipedia.org/wiki/Wikipedia:Wicnik
 
  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
___
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] First _draft_ goals for WMF engineering/product

2014-06-26 Thread Erik Moeller
As an update on the goals process for WMF engineering, we've begun
fleshing out out the top priorities for the first quarter. Going
forward, we'll aim to call out the top priorities for each quarter as
we approach it, to create more shared visibility into the most urgent
and high-impact projects we're working on.

I've decided for now to use a division between User-Impacting
Changes and Cross-Functional Platform and Process Improvements. The
intent of calling out both areas is to ensure that important
organizational priorities don't fall off our collective radar. At the
management level, the intent is for us to pay special attention to the
priorities called out in this manner, and this may also impact our
willingness to request help from across the organization if necessary
to support these priorities, at least in Q1.

I've merged the current draft into the goals document, here:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_departmental_priorities_for_Q1_.28July_-_September_2014.29

Once again, this is draft and marked as such. The Impact column will
include links to relevant metrics once those are a bit more solid; if
you look further down in the document you'll see that these are being
refined and tweaked in multiple areas right now.

A little bit of rationale for some items that may surprise you:

- I've decided to list HHVM as the top priority in both categories.
This is because a) it's a very complex undertaking from an engineering
perspective and requires significant coordination across development 
operations, b) it's probably the biggest change regarding how code
gets executed in production since we adopted PHP in the first place,
c) the expected performance benefits for many uncached logged-in user
operations are very significant (I defer to the team to quantify
before throwing out estimates).

This is also indicative of the importance we're attaching to site
performance. There's no question that performance is directly
correlated with user engagement, and it's appropriate that we spend
significant effort in this area.

- We're elevating SUL finalisation (
https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority,
and I've classified it as user-impacting. This is because it's on the
critical path for making it easier to develop cross-site functionality
(as long as we have to deal with the edge case of detached accounts,
certain features that work across wikis are just trickier to
implement), and one of those long term issues of technical debt we've
been kicking down the road for years. It's also a pretty complex
project -- if it goes wrong and we mess up our account database, we're
in big trouble. So we want to make sure we have lots of eyeballs on
this from a technical and community management perspective. We may not
completely wrap up in Q1 since we need to give users whose accounts
are affected significant warning time, which is just elapsed time we
can't shorten.

- Front-end code standardization is called out as a top priority. We
really need to dig ourselves out of the mess of having disjointed
templating systems, widget libraries, and JS frameworks across our
codebase if we want to increase development velocity and UX
consistency. I'm prepared to sacrifice short term development velocity
on other projects in order to make this happen.

- The content API that Gabriel is working on (
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
called out as a top priority. This is because the Parsoid output (for
which the content API will be a high performance front-end) is now
getting to the point where it's starting to become plausible to
increasingly use it not just for VisualEditor, but also for views as
well. The potential here are performance benefits across the board:
for logged-in users in general by consistently relying on fast, cached
output; for users loading VisualEditor by giving them most of the
payload required to edit in read mode; for users saving through
VisualEditor by potentially turning the wikitext transformation into a
post-save asynchronous process and thereby making saves near
instantaneous.

Moreover, it will put us on the long term path towards possibly using
HTML5 as MediaWiki's native format, supporting HTML5-only wikis, and
more. And it will be valuable for third party re-use and re-processing
of Wikimedia content for a multitude of use cases. Last but not least,
it's also a great use case for a service-oriented architecture
including REST APIs  good/clean API documentation.

In short, this is a big deal, and it has lots and lots of
architectural implications -- so raising the visibility on this is
intended to get more people to actually think through what all of this
means for the future of MediaWiki.

Other elements of the prioritization shouldn't be surprising:
Phabricator is a big deal, and it's coming; Mobile (including new
contributory features) and VE (including a really awesome new
citations experience we're 

Re: [Wikimedia-l] Vietnamese wp above 1 M articles and growing

2014-06-26 Thread Anders Wennersten

The Vietnamese Wikipedia creates 30-40 articles/day manually (with as many 
active contributers), which would put them on par with several medium/smaller 
projects, usually having around 200-400 K articles

But among their limited number of active contributers they have a set of very 
clever people creating and running bots. When I analyze the bot results I find 
they are using first class input (The Plant List and list of cities from like 
Turkey governement). I also see they are understanding the intricacies on how 
to manage the generated articles, them using (in some cases) templates and the 
discussion page. Also of course the code in the bots must be very good, 
managing these diverse set of articles. And no translating.

For me it confirms my belief that it is possible for most versions to set up 
and run clever bots for massgeneration of articles with 100% quality and using 
the best sources

I hope this experience can serve as an inspiration to others medium/smaller 
projects

My learnings from looking into several botgeneration effort is that there are 
three aspects you need to master
1.The infrastructure of generated articles - special templates, Categories, 
discussion pages, the speed they are set up (in order for reviews) how to 
handle already existing articles. I know this is learned on svwp itwp and nlwp. 
Basically it is common sense, but for any new the knowledge exist to learn from
2.The code of the Bots. it is complicated but no rocket science. The three I 
have looked into in detail where all written by persons not being professional 
programmers and using different programming languages (c, AWB and something resembling 
Basic). You could probably get access to some existing botcode, but in general I would 
expect most communities to be able to find someone who can create these type of 
botsoftware
3.The inputs to generate data from. This I have found to be the most 
challenging aspect, both what lists to use, how to translate these into article 
texts and how to handle ambiguities/errors. And here I do would recommend to 
take in experience from people already done this. Official lists of geographic 
entities exist and are used by several projects (it, nl, vi etc) but why not 
using the same sets and why not involving wikidata in these? For species the 
already exist several good inputs Lsjbot use Catalogue of Life, but others (nl, 
vi) use others.

And while I have no direct contact with the people at viwp, I would welcome if 
any one made contact and made their bot generation knowledge available to 
others.

Anders
 
 






Tanweer Morshed skrev 2014-06-24 13:52:

That's a great news that the Vietnamese Wikipedia has crossed 1M articles.
What are the significant reasons behind Vietnamese Wikipedia's such growth?
Is it just the usage of such clever Bots (that you have mentioned) or
contribution by the Vietnamese Wikipedians? And actually how does the
Cheer!-bot generate articles? Does it translate articles from English (or
other) Wikipedia? And apart from translating, can it set and maintain
correctly other aspects of Wikisyntax and coding?

Tanweer Morshed
Board member
Wikimedia Bangladesh


On Tue, Jun 24, 2014 at 11:38 AM, Anders Wennersten 
m...@anderswennersten.se wrote:


One of our most interesting projects, Vietnamese Wikipedia has now passed
1 M articles and has a growth just now  of almost 100k/month

They use a clever bot named Cheer!-bot to generate a lot of very good
articles. In some ways it is stronger then Lsjbot (covering more then
spececies) but I do prefer that Lsjbot marks the generated articles with a
template indicating they are botgenerated

start page: https://vi.wikipedia.org/wiki/Trang_Ch%C3%ADnh

Cheer-bot! generated articles (just now working on species like Lsjbot)
https://vi.wikipedia.org/wiki/%C4%90%E1%BA%B7c_bi%E1%BB%87t:
%C4%90%C3%B3ng_g%C3%B3p/Cheers!-bot

Statistics up to April http://stats.wikimedia.org/EN/TablesWikipediaVI.htm
notice active generating around one year from now

As I said a lot of times, I believe it is a weakness we are not making use
of the many excellent inititves taking place on less well known verisons
(like the lithuanian I mentioned some time ago). I am not even sure there
are any from viwp acrtive on this list.

Also I  recommend you to look through the content of viwp by using the
  use the Random article feature Bài vie^'t nga^~u nhiên 
https://vi.wikipedia.org/wiki/%C4%90%E1%BA%B7c_bi%E1%
BB%87t:Ng%E1%BA%ABu_nhi%C3%AAn

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 mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines