[Wikimedia-l] Chapters and GLAM tooling

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Wikimedia-l] Chapters and GLAM tooling

Erik Moeller-4
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

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 <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Jon Davies
In reply to this post by Erik Moeller-4
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 <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Stéphane Coillet-Matillon-2
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 <[hidden email]>:

> 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 <[hidden email]> 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
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?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
> [hidden email]
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@...>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Ilario Valdelli
In reply to this post by Erik Moeller-4
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 <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Liam Wyatt
In reply to this post by Erik Moeller-4
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 <[hidden email]> 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
> [hidden email]
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@...>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

David Cuenca Tudela
In reply to this post by Erik Moeller-4
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 <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>




--
Etiamsi omnes, ego non
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Seb35
Similarly to what you are describing, Micru, BeWelcome has a process to  
identify issues and resolve them in a community discussion. It’s a sort of  
communal product specification/design.

The process looks like: [1]
1/ firstly, community members can submit issues or product ideas,
2/ secondly, there is a discussion with proposed resolutions,
3/ thirdly, a vote between the various proposed resolutions,
4/ lastly, the development phase itself.

Although we have some sort of such process (Idea lab, RFC, mailing lists,  
bug tracker, MediaWiki.org), it’s not as easy to find where are the ideas  
of products, where are the development of these ideas, and where and how  
you can give your voice to influence the path of the development.

Personally I like a lot the BeWelcome process (and it’s a non-technical  
member who presented me that), and I find you could reuse it in Wikimedia,  
probably in a customized form, and with short and intuitive product ideas  
and resolutions (avoid too long pages at first sight).

[1] https://www.bewelcome.org/suggestions/about

~ Seb35


Le mardi 26 juin 2014 15:12:03 (CEST), David Cuenca a écrit :

> 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 <[hidden email]> 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
>> [hidden email]
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
>
>
>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] [cultural-partners] Chapters and GLAM tooling

Ilario Valdelli
In reply to this post by Liam Wyatt
In my opinion your are putting on the table an important question, dear
Barbara.

The question is how approaching the GLAM tools.

In every software there is a need, after there is a development, and after
there is an acceptance because who asked to have a tool may say that the
"functionalities" don't match the requirements.

The tool can be fantastic, multitasking, multifunctional, portable,
efficient, and so on BUT cannot do some basic functions required by a GLAM
project.

The main problem, for instance, is that it's hard to use, not friendly, it
requires a long training...

The problem is to have technicians designing softwares for technicians or
implementing softwares for technicians.

I think that it's fundamental that the requests and the acceptance MUST be
done by GLAM operators and that the tools must implement ONLY what is
required, nothing else.

I remember that some months ago there was a discussion here about the tools
required by GLAM projects... there were several emails and the request was
for the GLAMwiki tooolkit.

After some months it would be happy to know who is using it, which projects
are having benefits from it and how quantify the relation costs/benefits.

I think that the GLAM-coordinators must take their right position in this
process and must organize a "task force" to collect requirements and to
submit these requirements to the community of developers and to evaluate
the final results asking for corrections or re-engineering. If the GLAM
coordinators will not be bold, the risk is to have terabytes of unusable
software or tools.

This role is fundamental for a correct approach to this problem.

regards


On Thu, Jul 3, 2014 at 12:34 PM, Barbara Fischer <
[hidden email]> wrote:

> Hi Liam and Eric,
>
> collaborating with GLAMs in Germany I can only stress how important
> technical support is to help GLAM to integrate their content to Wikimedia
> projects. Actually it is a trias of consultancy, technical support and
> seduce them with projects like coding da Vinci : the culture hackathon
> <http://codingdavinci.de/>.  We are planning to enhance this support by
> more intense collaboration with EUROPEANA through the GLAM Wiki Tool kit -
> hopefully with Liam -, by launching a "Lizenzhinweisgenerator
> <https://github.com/wmde/Lizenzverweisgenerator>" helping users in an
> easy way to quote and reuse legally correct the data files on Commons, and
> thus ensuring GLAMs that "their" content will be widely spread but thread
> to them. And triggering the discussion on license issues on all legal
> levels. We would really appreciate it, if there would something like an
> international "task force" making sure as one point that the different
> tools are accessible in the different languages in different chapters and
> adapting them to national law where it is required.
>
> As far as I can see time is right to harvest - let`s provide the service
> and tools to make it as easy and convenient as possible.
>
> The meet up of GLAM-coordinators at the Wikimania would be a good starting
> point. Lilli Illiev
> <http://wikimania2014.wikimedia.org/wiki/User:Lilli_Iliev_(WMDE)>and Katja
> Ullrich
> <http://wikimania2014.wikimedia.org/wiki/User:Katja_Ullrich_(WMDE)> will
> attend the Wikimania to meet as many of You as possible and share the
> knowledge.
>
> Best regards
>
> Barbara Fischer
> Kuratorin für Kulturpartnerschaften
> Jeweils persönlich von Montag bis Donnerstag für Sie erreichbar
> Wikimedia Deutschland e.V. | NEU: Tempelhofer Ufer 23-24 | 10963 Berlin
> Tel. (030) 219 158 26-(0)44
>
> http://wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/681/51985.
>
>
>


--
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Erik Moeller-4
In reply to this post by Erik Moeller-4
Just pinging this thread -- looking through all the proposals for
annual plan grants:

https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_%C3%96sterreich/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_UK/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Sverige/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Serbia/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Nederland/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Israel/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Eesti/Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Deutschland_e.V./Proposal_form
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form

I'm not seeing any developer contract time allocated to GLAM tooling
work yet. At the same time I'm seeing reports of breakage and missing
functionality in important tools running in Labs. To the extent that
this breakage is due to Labs infrastructure or access to data, it's
our job (WMF) to fix it and you should (continue to) poke us to do so
-- but to the extent that it can be addressed in the tools themselves,
I'd love to see chapters take this on directly. It's possible that I'm
missing something. Are there more concrete plans at this point in time
to help support the tools developed by Magnus and others, and create
new reports on an as-needed basis? Having a dedicated staff person in
chapters or an affilicate like Europeana who WMF analytics can partner
with would be really helpful for keeping this moving, in my view.

Thanks,
Erik

--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

MZMcBride-2
Erik Moeller wrote:
>I'm not seeing any developer contract time allocated to GLAM tooling
>work yet. At the same time I'm seeing reports of breakage and missing
>functionality in important tools running in Labs. To the extent that
>this breakage is due to Labs infrastructure or access to data, it's
>our job (WMF) to fix it and you should (continue to) poke us to do so
>-- but to the extent that it can be addressed in the tools themselves,
>I'd love to see chapters take this on directly.

Maybe, but we need to clearly define what a smart investment of resources
looks like. In my opinion, it's much closer to the development of an
extension such as GWToolset than it is to trying to have someone hack at a
few PHP scripts on Wikimedia Labs.

Labs is a playground and Galleries, Libraries, Archives, and Museums are
serious enough to warrant a proper investment of resources, in my view.
Magnus and many others develop magnificent tools, but my sense is that
they're largely proofs of concept, not final implementations.

We need to build infrastructure, and while Labs is itself infrastructure,
it's really a sandbox for neat ideas, not a proper resolution to technical
problems facing the wikis.

If people want to substantively contribute to the technical ecosystem,
that requires fully integrating into it. This typically means developing
and supporting a deployed MediaWiki extension or, more rarely, integrating
directly into MediaWiki core. This type of development requires an
intelligent and focused set of requirements for new extensions or
development projects that gets a thorough review (and sign-off) by the
people who will ultimately be deploying and indefinitely hosting this code.

GLAMs and Chapters could make all kinds of investments into new
functionality for the projects. Improved Wikidata modeling and data entry
into Wikidata, an in-browser SVG (or rasterized image) editor, better
media search, enhancements to Wikisource/OCR, etc. There's no shortage of
work to be done, but it's moderately challenging currently to develop
scalable solutions to the larger problems. If GLAMs and Chapters aren't
willing to try to tackle a harder problem, there are also plenty of
smaller improvements needed to both MediaWiki and its hundreds of
extensions that could also benefit everyone. But again, the focus would be
integrating into the Wikimedia technical platform and fixing issues in
production, rather than trying to make Labs scripts and tools better.

MZMcBride



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Gerard Meijssen-3
Hoi,
There are several issues and imho the one Erik mentions is crucial. When no
money is intended for GLAM tool related work, nothing will happen. The
situation will remain one where everybody is eying each other... are you
going to make a move ... are you?

If you are all for a comprehensive technical infra structure blabla, all
well and good. Nothing is going to happen without an initiative and, any
initiative that does not have funding support will end up on Labs. Fiddling
with small scale improvements are nice, it will provide some solace but
what we need is a next generation of tools and of particular importance is
reporting. An environment is being developed for statistics and reporting
but as far as I can see it is either really hard or developments are not
being communicated or there is not much to report anyway.

Erik challenges the chapters. I hope the chapters rise to the occasion and
define a plan. From what I observed the most important part of the products
that are of use to GLAMS, stability is the main thing. We need continuous
reporting. We need the continuous availability of tools. That is very much
more than only a question of Labs or not Labs.

If anything it is a challenge to Erik how he envisions to provide a
platform for statistics that will be continuously available and how he will
ensure that tools are stable and are available.
Thanks,
      GerardM

PS The statistics for Wikidata are still broken and who is going to tackle
that and the break in reporting ???

On 25 October 2014 16:16, MZMcBride <[hidden email]> wrote:

> Erik Moeller wrote:
> >I'm not seeing any developer contract time allocated to GLAM tooling
> >work yet. At the same time I'm seeing reports of breakage and missing
> >functionality in important tools running in Labs. To the extent that
> >this breakage is due to Labs infrastructure or access to data, it's
> >our job (WMF) to fix it and you should (continue to) poke us to do so
> >-- but to the extent that it can be addressed in the tools themselves,
> >I'd love to see chapters take this on directly.
>
> Maybe, but we need to clearly define what a smart investment of resources
> looks like. In my opinion, it's much closer to the development of an
> extension such as GWToolset than it is to trying to have someone hack at a
> few PHP scripts on Wikimedia Labs.
>
> Labs is a playground and Galleries, Libraries, Archives, and Museums are
> serious enough to warrant a proper investment of resources, in my view.
> Magnus and many others develop magnificent tools, but my sense is that
> they're largely proofs of concept, not final implementations.
>
> We need to build infrastructure, and while Labs is itself infrastructure,
> it's really a sandbox for neat ideas, not a proper resolution to technical
> problems facing the wikis.
>
> If people want to substantively contribute to the technical ecosystem,
> that requires fully integrating into it. This typically means developing
> and supporting a deployed MediaWiki extension or, more rarely, integrating
> directly into MediaWiki core. This type of development requires an
> intelligent and focused set of requirements for new extensions or
> development projects that gets a thorough review (and sign-off) by the
> people who will ultimately be deploying and indefinitely hosting this code.
>
> GLAMs and Chapters could make all kinds of investments into new
> functionality for the projects. Improved Wikidata modeling and data entry
> into Wikidata, an in-browser SVG (or rasterized image) editor, better
> media search, enhancements to Wikisource/OCR, etc. There's no shortage of
> work to be done, but it's moderately challenging currently to develop
> scalable solutions to the larger problems. If GLAMs and Chapters aren't
> willing to try to tackle a harder problem, there are also plenty of
> smaller improvements needed to both MediaWiki and its hundreds of
> extensions that could also benefit everyone. But again, the focus would be
> integrating into the Wikimedia technical platform and fixing issues in
> production, rather than trying to make Labs scripts and tools better.
>
> MZMcBride
>
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Federico Leva (Nemo)
In reply to this post by MZMcBride-2
MZMcBride, 25/10/2014 16:16:
> But again, the focus would be
> integrating into the Wikimedia technical platform and fixing issues in
> production, rather than trying to make Labs scripts and tools better.

False dichotomy IMHO. Usual example:*
https://bugzilla.wikimedia.org/42259 Quite clearly WMF's responsibility
to make it possible, but all the interfaces and value are in
consumers/tools.

Nemo

(*) Yes, I know https://meta.wikimedia.org/wiki/Research:Page_view is
being worked on.

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

MZMcBride-2
Federico Leva (Nemo) wrote:

>MZMcBride, 25/10/2014 16:16:
>> But again, the focus would be
>> integrating into the Wikimedia technical platform and fixing issues in
>> production, rather than trying to make Labs scripts and tools better.
>
>False dichotomy IMHO. Usual example:*
>https://bugzilla.wikimedia.org/42259 Quite clearly WMF's responsibility
>to make it possible, but all the interfaces and value are in
>consumers/tools.
>
>Nemo
>
>(*) Yes, I know https://meta.wikimedia.org/wiki/Research:Page_view is
>being worked on.

I think it's a limited view to suggest that the Wikimedia Foundation
should only provide raw dumps and/or queryable data and have volunteers
try to cobble together scripts and tools to interact with the data. That
certainly can and should be a piece of this, but there's no good reason
not to, for example, integrate page view graphs into MediaWiki's info
action, allowing regular users to see quickly and easily see an article's
page views over time.

We already have queryable revision information, but we rely on external
tools and services to try to graph edits over time, rather than having
visual functionality integrated into MediaWiki. The same is true of
visualizing a particular user's edits or other logged actions. We're
relying on external tools when we should be trying to create tools that
live within the technical platform that we've created. A generalized,
scaleable graphing/visualization tool would be an excellent use of
resources. Making such a tool could easily have a definable goal with
clear requirements, and implementing and deploying such a tool would have
a very clear benefit to all of our projects.

We have a real problem turning proofs of concept into stable
infrastructure. GLAMs and Chapters can invest in creating stable
infrastructure, but that probably doesn't mean investing in Labs, exactly.
Not if you want to have a long-term, substantive impact, in my opinion.

Regarding page views data specifically, the Wikimedia Foundation has done
a good deal of cookie-licking in this area and that really should be
addressed. The linked bug report demonstrates what I'm talking about. It's
been _years_ of waiting as various analytics team have come and gone (does
anyone remember when Open Web Analytics was going to save the day?). And
yet it's 2014 and we still can't answer the most basic analytics questions
such as "how many views did X article get this month?" There has been some
deep dysfunction in this area of the Wikimedia Foundation, but I don't
know what any GLAM institution or Wikimedia Chapter can do about the
analytics situation, so it may be best to focus on other areas in which
making an impact is feasible.

MZMcBride



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Marc-Andre
On 10/25/2014 01:50 PM, MZMcBride wrote:
> [...] that probably doesn't mean investing in Labs, exactly.
> Not if you want to have a long-term, substantive impact, in my opinion.

I'd like to address that particular recurrent canard here, if I may.

Things that reside in labs are empathically /not/ second-class citizens
by any stretch of the imagination.  Perhaps our attempts to emphasise
that "Labs is not production" were not clear enough about what me mean
by the distinction - and because of that people have gotten the wrong
impression about it.

What "not production" means is simply a matter of (a) scaling and (b)
service level.  For the latter, all it means in practice is that if
something in labs breaks not all of ops will drop what they are doing to
attend it as we would for prod.  It doesn't mean that we don't care that
it broke, nor that it is of lesser importance - just that the impact is
lower and therefore it is not reasonable to divert all resources to the
issue.

As for scaling, it will almost never be an issue until something becomes
used frequently by a large fraction of the projects' user base.  Labs
remains a perfectly reasonable permanent home for anything that expects
light or medium use - whether it's volunteer-driven or WMF-driven
(deployment-prep is an excellent example of a service that lives in Labs
which is used continually by almost all the devs and yet will never live
in "prod").


Labs isn't a second-grade production for unimportant things; it's a more
flexible, more open environment for general tooling and development.  If
anything, it's /prod/ that is more restricted (in who can use it, how
complicated it is to be allowed to deploy there, what restrictions are
place on what is there).

Any GLAM tools would almost certainly live in Labs - whether it's been
developped by the WMF, volunteers or Chapters - not because it's not
"worthy" of production but because trying to make it into production
services would make development and deployment immensely more
complicated and much less flexible.  The question shouldn't be "Do we
need to invest in Labs" but "How to we avoid the trouble of having to do
this in production".

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Erik Moeller-4
In reply to this post by MZMcBride-2
On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride <[hidden email]> wrote:

> Labs is a playground and Galleries, Libraries, Archives, and Museums are
> serious enough to warrant a proper investment of resources, in my view.
> Magnus and many others develop magnificent tools, but my sense is that
> they're largely proofs of concept, not final implementations.

Far from being treated as mere proofs of concept, Magnus' GLAM tools
[1] have been used to measure and report success in the context of
project grant and annual plan proposals and reports, ongoing project
performance measurements, blog posts and press releases, etc. Daniel
Mietchen has, to my knowledge, been the main person doing any
systematic auditing or verification of the reports generated by these
tools, and results can be found in his tool testing reports, the last
one of which is unfortunately more than a year old. [2]

Integration with MediaWiki should IMO not be viewed as a runway that
all useful developments must be pushed towards. Rather, we should seek
to establish clearer criteria by which to decide that functionality
benefits from this level of integration, to such an extent that it
justifies the cost. Functionality that is not integrated in this
manner should, then, not be dismissed as "proofs of concept" but
rather judged on its own merits.

GWToolset [3] is a good example. It was built as a MediaWiki extension
to manage GLAM batch uploads, but we should not regard this decision
as sacrosanct, or the only correct way to develop this kind of
functionality. The functionality it provides is of highly specialized
interest, and indeed, the number of potential users to-date is 47
according to [4], most of whom have not performed significant uploads
yet.  Its user interface is highly specialized and special permissions
+ detailed instructions are required to use it. At the same time, it
has been used to upload 322,911 files overall, an amazing number even
without going into the quality and value of the individual
collections.

So, why does it need to be a MediaWiki extension at all? When
development began in 2012, OAuth support in MediaWiki did not exist,
so it was impossible for an external tool (then running on toolserver)
to manage an upload on the user's behalf without asking for the user's
password, which would have been in violation of policy. But today, we
have other options. It's possible that storage requirements or other
specific desired integration points would make it impossible to create
this as a Tool Labs tool -- but if we created the same tool today, we
should carefully consider that.

Indeed, highly specialized tools for the cultural and education sector
_are_ being developed and hosted inside Tool Labs or externally.
Looking at the current OAuth consumer requests [5], there are
submissions for a metadata editor developed by librarians at the
University of Miami Libraries in Coral Gables, Florida, and an
assignment creation wizard developed by the Wiki Education Foundation.
There's nothing "improper" about that, as Marc-André pointed out.

As noted before, for tools like the ones used for GLAM reporting to
get better, WMF has its role to play in providing more datasets and
improved infrastructure. But there's nothing inherent in the
development of those tools that forces them to live in production
land, or that requires large development teams to move them forward.
Auditing of numbers, improved scheduling/queuing of database requests,
optimization of API calls and DB queries; all of this can be done by
individual contributors, making this suitable work for even chapters
with limited experience managing technical projects to take on.

On the analytics side, we're well aware that many users have asked for
better access to the pageview data, either through MariaDB, or through
a dedicated API. We have now said for some time that our focus is on
modernizing the infrastructure for log analysis and collection,
because the numbers collected by the old webstatscollector code were
incomplete, and the infrastructure subject to frequent packet loss
issues. In addition, our ability to meet additional requirements on
the basis of simple pageview aggregation code was inherently
constrained.

To this end, we have put into production use infrastructure to collect
and analyze site traffic using Kafka/Hadoop/Hive. At our scale, this
has been a tremendously complex infrastructure project which has
included custom development such as varnishkafka [6]. While it's taken
longer than we've wanted, this new infrastructure is being used to
generate a public page count dataset as of this month, including
article-level mobile traffic for the first time [7]. Using
Hadoop/Hive, we'll be able to compile many more specialized reports,
and this is only just beginning.

Giving community developers better access to this data needs to be
prioritized relative to other ongoing analytics work, including but
not limited to:

- Continued development and maintenance of the above infrastructure foundations;

- Development of "Vital Signs": public reports on editor activity,
content contribution, sign-ups and other metrics. This tool gives us
more timely access to key measures than WikiStats [9] (or the
reportcard [10], which to-date still consumes Wikistats data). Rather
than having to wait 4-6 weeks to know what's happening with regard to
editor numbers, we can see continuous updates on a day-to-day basis.

- Development of Wikimetrics, which analyzes the editing activity of a
group of editors, and which is essential for measuring all movement
work that targets increased activity by a targeted group (e.g.
editathon), and is a key tool used for grants evaluation (was a funded
program worth the $$?). A lot of thought has gone into the development
of standardized  global metrics [12] for program work, much of it
using this technology and dependent on its continued development.

- Measurement (instrumentation) of site actions and
development/maintenance of associated infrastructure. As an example,
in-depth data collection for features like Media Viewer (see
dashboards at  [13] ) is only possible because of the EventLogging
extension developed by Ori Livneh, and the increasing use of this
technology by WMF developers. EventLogging requires significant
management, maintenance and teaching effort from the analytics team.

Lila is requesting visibility into all primary funnels on Wikimedia
sites (e.g. sign-ups, edits/saves through wikitext, edits/saves
through VisualEditor, etc.), and this will require lots of sustained
effort from lots of people to get done. What it will give us is a
better sense of where people succeed and fail to complete an action --
by way of example, see the initial UploadWizard funnel analysis here:
https://www.mediawiki.org/wiki/UploadWizard/Funnel_analysis

- Improved software and infrastructure support for A/B testing,
possibly including adoption of existing open source tooling such as
Facebook's PlanOut library/interpreter [14].

- Improved readership metrics, possibly including a privacy-sensitive
approach to estimating Unique Visitors, and better geographic
breakdowns for readers/editors.

These are all complex problems, most of which are dependent on the
small analytics team, and feedback on projects and priorities is very
much welcome on the analytics mailing list:
https://lists.wikimedia.org/mailman/listinfo/analytics

With regard to better embedding of graphs in wikis specifically, Yuri
Astrakhan has led the development of a new extension, inspired by work
by Dan Andreescu, to visualize data directly in wikis. This extension
has been deployed already to Meta and MediaWiki.org and can be used
for dynamic graphs where it's appropriate to not have a fallback to a
static image, for example in grant reports. See:
https://www.mediawiki.org/wiki/Extension:Graph
https://www.mediawiki.org/wiki/Extension:Graph/Demo
https://meta.wikimedia.org/wiki/Graph:User:Yurik_(WMF)/Obama

I agree this is the kind of functionality that should make its way
into Wikipedia. Again, we need to judge throwing a full team behind
that against the relative priority of other work. In the meantime,
Yuri and others will continue to push it along and may even be able to
get it all the way there in due time. The main blockers, from what I
can tell, are generation of static fallback images for users without
JavaScript, and a better way to manage the data sources.

In general, the point of my original message was this: All
organizations that seek to improve Wikipedia and the other Wikimedia
projects ultimately depend on technology to do so; to view WMF as the
sole "tech provider" does not scale. Larger, well-funded chapters can
take on big, hairy challenges like Wikidata; smaller, less-funded orgs
are better positioned to work on specialized technical support for
programmatic work.

I would caution against requesting WMF to work on highly specialized
solutions for highly specialized problems. If such solutions are
needed, I would caution against building them into MediaWiki unless
they can be generalized to benefit a larger number of users, at which
point it's appropriate to seek partnership with WMF, or to ask WMF for
the relative priority of such work. But often, it's perfectly fine
(and much faster) to build such tools and reports independently, and
to ask WMF for help in providing APIs/services/data/infrastructure to
get it done.

Cheers,
Erik

[1] http://tools.wmflabs.org/glamtools/
[2] https://outreach.wikimedia.org/wiki/Category:This_Month_in_GLAM_Tool_testing_reports
[3] https://www.mediawiki.org/wiki/Extension:GWToolset
[4] https://commons.wikimedia.org/w/index.php?title=Special%3AListUsers&username=&group=gwtoolset&limit=50
[5] https://www.mediawiki.org/wiki/Special:OAuthListConsumers?name=&publisher=&stage=0
[6] https://github.com/wikimedia/varnishkafka
[7] https://wikitech.wikimedia.org/wiki/Analytics/Pagecounts-all-sites
[8] https://metrics.wmflabs.org/static/public/dash/
[9] http://stats.wikimedia.org/
[10] http://reportcard.wmflabs.org/
[11] https://metrics.wmflabs.org/
[12] https://meta.wikimedia.org/wiki/Grants:Learning_%26_Evaluation/Global_metrics
[13] http://multimedia-metrics.wmflabs.org/dashboards/mmv
[14] https://github.com/facebook/planout
--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

MZMcBride-2
Erik Moeller wrote:

>On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride <[hidden email]> wrote:
>> Labs is a playground and Galleries, Libraries, Archives, and Museums are
>> serious enough to warrant a proper investment of resources, in my view.
>> Magnus and many others develop magnificent tools, but my sense is that
>> they're largely proofs of concept, not final implementations.
>
>Far from being treated as mere proofs of concept, Magnus' GLAM tools
>[1] have been used to measure and report success in the context of
>project grant and annual plan proposals and reports, ongoing project
>performance measurements, blog posts and press releases, etc. Daniel
>Mietchen has, to my knowledge, been the main person doing any
>systematic auditing or verification of the reports generated by these
>tools, and results can be found in his tool testing reports, the last
>one of which is unfortunately more than a year old. [2]

It's funny that you mention "This Month in GLAM" as my now-defunct bot
delivered its monthly newsletter for quite some time. The MassMessage
MediaWiki extension is a pretty great case study of exactly what I'm
discussing here: turning a proof-of-concept script into a supported and
maintained tool that's integrated with MediaWiki. :-)

While it's tedious to get an extension deployed, the (ideal) result is
that it has documentation, it's gone through series of review
(performance, security, architecture, and design) and we know where the
source code is and how to build it. That's not nothing!

>Integration with MediaWiki should IMO not be viewed as a runway that
>all useful developments must be pushed towards. Rather, we should seek
>to establish clearer criteria by which to decide that functionality
>benefits from this level of integration, to such an extent that it
>justifies the cost. Functionality that is not integrated in this
>manner should, then, not be dismissed as "proofs of concept" but
>rather judged on its own merits.

Sure, I agree with this in principle.

When I consider Labs (or Tool Labs), I think of the Toolserver:
<https://toolserver.org/~magnus/>.

My point was that GLAMs should be taken seriously. The Wikimedia
Foundation's historical track record with regard to GLAM support isn't
great. And from the perspective of these institutions, I continue to
believe that it makes sense to invest in long-term solutions, even if
they're more costly in terms of time and money.

Wikimedia DC has been hosting meet-ups at the National Archives lately.
The National Archives has been in the free content business a lot longer
than the Wikimedia Foundation, eh. ;-)  They know that hacking together a
few scripts on Labs isn't going to integrate their enormous collection of
accumulated holdings that we want in our projects and that they want to
share with the world.

Labs _is_ a playground, just as the Toolserver was. Volunteers created
some incredible scripts and tools, but how many are still around today? I
maintained many scripts and bots for years, but eventually you lose
interest, you have other priorities, life moves on, and yet the need for
such tools has only grown.

>As noted before, for tools like the ones used for GLAM reporting to
>get better, WMF has its role to play in providing more datasets and
>improved infrastructure. But there's nothing inherent in the
>development of those tools that forces them to live in production
>land, or that requires large development teams to move them forward.

If these tools want to be around in five or ten years from now, then I
disagree. I've spent far too long watching far too many people walk away,
abandoning their previous pet projects. That's certainly their prerogative
as volunteers and I don't blame the Wikimedia Foundation or anyone else
for their departure, but that doesn't mean there's not a real issue here
in terms of creating lasting, sustainable software.

This isn't to say that every MediaWiki extension is some garden of Eden
where there's no code rot. But at least the current extension process
creates a much higher likelihood of long-term success than the
alternatives. I wouldn't be so quick to discount it.

MediaWiki _is_ the platform, in my view. I wonder: if we relabeled
MediaWiki extensions and started calling them apps, would it be easier to
sell everyone on the idea of the need for more of them?

> - Improved software and infrastructure support for A/B testing, possibly
>including adoption of existing open source tooling such as Facebook's
>PlanOut library/interpreter [14].

I'll split this out into a separate thread.

>In general, the point of my original message was this: All
>organizations that seek to improve Wikipedia and the other Wikimedia
>projects ultimately depend on technology to do so; to view WMF as the
>sole "tech provider" does not scale. Larger, well-funded chapters can
>take on big, hairy challenges like Wikidata; smaller, less-funded orgs
>are better positioned to work on specialized technical support for
>programmatic work.

Sure, I agree with this as well.

And thank you for laying out some of the work and progress that has been
made in the analytics area. It was a very interesting read, as was the
information about (among other things) improved graphs support.

>I would caution against requesting WMF to work on highly specialized
>solutions for highly specialized problems.

Nobody is suggesting this. I'm all for both strictly evaluating the need
for new tools and for developing generalized solutions for maximum impact.

MZMcBride



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Stéphane Coillet-Matillon-2
In reply to this post by Erik Moeller-4
Hi Erik,

To specifically respond to your question, and as you know, WMCH does have
plans to hire a developer next year for its offline dissemination program
(ie KIWIX) [1][2].

Since Europeana had indicated its interest into maintaining/developing it
the GWToolset, we decided to focus our efforts on keeping Kiwix going
(that's also where our relationship with the community is strongest). This
being said, we also do intend to be heavily using the GlamWikiToolset next
year already, and may therefore need to develop our own extensions as needs
arise. We however first need to find out what such needs are/will be, and
how Europeana will handle the load.

But yes, to answer your question we do plan on having a dedicated chapter
staff whom you will be able to work with (provided the current APG request
goes well enough, of course).

Cheers

Stephane


[1] *https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form#Offline_Dissemination_Program
<https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form#Offline_Dissemination_Program>*
[2] https://meta.wikimedia.org/wiki/Kiwix_-_Wikipedia_Offline

>>
>>
>> -------- Original Message --------
>> Subject: Re: [Wikimedia-l] Chapters and GLAM tooling
>> Date: Fri, 24 Oct 2014 11:45:50 -0700
>> From: Erik Moeller <[hidden email]>
>> Reply-To: Wikimedia Mailing List <[hidden email]>
>> To: Wikimedia Mailing List <[hidden email]>
>>
>> Just pinging this thread -- looking through all the proposals for
>> annual plan grants:
>>
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_%C3%96sterreich/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_UK/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Sverige/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Serbia/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Nederland/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Israel/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Eesti/Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Deutschland_e.V./Proposal_form
>>
https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form

>>
>> I'm not seeing any developer contract time allocated to GLAM tooling
>> work yet. At the same time I'm seeing reports of breakage and missing
>> functionality in important tools running in Labs. To the extent that
>> this breakage is due to Labs infrastructure or access to data, it's
>> our job (WMF) to fix it and you should (continue to) poke us to do so
>> -- but to the extent that it can be addressed in the tools themselves,
>> I'd love to see chapters take this on directly. It's possible that I'm
>> missing something. Are there more concrete plans at this point in time
>> to help support the tools developed by Magnus and others, and create
>> new reports on an as-needed basis? Having a dedicated staff person in
>> chapters or an affilicate like Europeana who WMF analytics can partner
>> with would be really helpful for keeping this moving, in my view.
>>
>> Thanks,
>> Erik
>>
>> --
>> Erik Möller
>> VP of Product & Strategy, Wikimedia Foundation
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> [hidden email]
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
>>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

[Wikimedia-l] Chapters and GLAM tooling

Liam Wyatt
Hi Stéphane,
I'm currently sitting in the plenary hall of the Europeana AGM in Prado
Museum in Madrid and, quite literally, right now is the presentation is
about the 2015 business plan. What the organisation will prioritise etc.
etc. Therefore, it's a perfectly timed email to mention the GLAMwikiToolset
[GWT] and Europeana! Several Wikimedians from European Chapters, Maria from
the WMF Board of Trustees, and other 'friends of the family' are here too.

In this specific context I should say that in the last weeks of practical
planning for 2015, we've narrowed down the scope of what Europeana will be
wiling and able to support in the Wikiverse. It was decided that while
Europeana does want to fix bugs, improve documentation and give some more
'polish' to the GWT, it has decided that committing to the ongoing
development of an integrated, content-agnostic, clear user-interface, for
Wikimedia Commons is actually beyond the scope of the organisation.
Ultimately Europeana's mission is about European GLAM content and it can no
longer justify being the 'business owner' for the large development task
that would be creating the fully-featured integrated Commons system. To be
clear: Europeana is not 'leaving' and wants to help improve the tool as it
currently exists (as well as remain involved in a variety of other GLAMwiki
activities), but the organisation wanted to be clear in setting
expectations that it will *not* be building the Mass-upload equivalent of
the Upload Wizard.

From a personal perspective, as the guy who was pushing for the
funding/creation of the magical, easy, beautiful mass-upload system
since... I forget how long ago now... I would love to see investment (by
anyone), but in my professional perspective I understand the need for
Europeana to clearly define the scope of its activities - and a
mass-uploader for anyone, with any content, to Wikimedia (with all the
extremely complex usability, templates, metadata... requirements that this
entails) is actually outside the scope of its mission.

- Liam, in my capacity as
Europeana GLAMwiki Coordinator.

wittylama.com
Peace, love & metadata

On 31 October 2014 11:11, Stéphane Coillet-Matillon <
[hidden email]> wrote:

> Hi Erik,
>
> To specifically respond to your question, and as you know, WMCH does have
> plans to hire a developer next year for its offline dissemination program
> (ie KIWIX) [1][2].
>
> Since Europeana had indicated its interest into maintaining/developing it
> the GWToolset, we decided to focus our efforts on keeping Kiwix going
> (that's also where our relationship with the community is strongest). This
> being said, we also do intend to be heavily using the GlamWikiToolset next
> year already, and may therefore need to develop our own extensions as needs
> arise. We however first need to find out what such needs are/will be, and
> how Europeana will handle the load.
>
> But yes, to answer your question we do plan on having a dedicated chapter
> staff whom you will be able to work with (provided the current APG request
> goes well enough, of course).
>
> Cheers
>
> Stephane
>
>
> [1] *
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form#Offline_Dissemination_Program
> <
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form#Offline_Dissemination_Program
> >*
> [2] https://meta.wikimedia.org/wiki/Kiwix_-_Wikipedia_Offline
>
> >>
> >>
> >> -------- Original Message --------
> >> Subject: Re: [Wikimedia-l] Chapters and GLAM tooling
> >> Date: Fri, 24 Oct 2014 11:45:50 -0700
> >> From: Erik Moeller <[hidden email]>
> >> Reply-To: Wikimedia Mailing List <[hidden email]>
> >> To: Wikimedia Mailing List <[hidden email]>
> >>
> >> Just pinging this thread -- looking through all the proposals for
> >> annual plan grants:
> >>
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_%C3%96sterreich/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_UK/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Sverige/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Serbia/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Nederland/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Israel/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Eesti/Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_Deutschland_e.V./Proposal_form
> >>
>
> https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2014-2015_round1/Wikimedia_CH/Proposal_form
> >>
> >> I'm not seeing any developer contract time allocated to GLAM tooling
> >> work yet. At the same time I'm seeing reports of breakage and missing
> >> functionality in important tools running in Labs. To the extent that
> >> this breakage is due to Labs infrastructure or access to data, it's
> >> our job (WMF) to fix it and you should (continue to) poke us to do so
> >> -- but to the extent that it can be addressed in the tools themselves,
> >> I'd love to see chapters take this on directly. It's possible that I'm
> >> missing something. Are there more concrete plans at this point in time
> >> to help support the tools developed by Magnus and others, and create
> >> new reports on an as-needed basis? Having a dedicated staff person in
> >> chapters or an affilicate like Europeana who WMF analytics can partner
> >> with would be really helpful for keeping this moving, in my view.
> >>
> >> Thanks,
> >> Erik
> >>
> >> --
> >> Erik Möller
> >> VP of Product & Strategy, Wikimedia Foundation
> >>
> >> _______________________________________________
> >> Wikimedia-l mailing list, guidelines at:
> >> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >> [hidden email]
> >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >> <mailto:[hidden email]?subject=unsubscribe>
> >>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@...>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
wittylama.com
Peace, love & metadata
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Chapters and GLAM tooling

Erik Moeller-4
In reply to this post by Erik Moeller-4
On Sat, Oct 25, 2014 at 5:58 PM, Erik Moeller <[hidden email]> wrote:
> Indeed, highly specialized tools for the cultural and education sector
> _are_ being developed and hosted inside Tool Labs or externally.
> Looking at the current OAuth consumer requests [5], there are
> submissions for a metadata editor developed by librarians at the
> University of Miami Libraries in Coral Gables, Florida, and an
> assignment creation wizard developed by the Wiki Education Foundation.

The Wiki Education Foundation just introduced its Assignment Wizard,
which is being developed with the help of an outside agency. As this
tool develops, there may be opportunities for sharing experiences with
other Wikimedia organizations:

http://wikiedu.org/blog/2014/11/07/user-testing-assignment-design-wizard/

Erik

--
Erik Möller
VP of Product & Strategy, Wikimedia Foundation

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12