Hello everyone,
Since 2019, it is possible to add structured data to files on Wikimedia Commons [1] (SDC = Structured Data on Commons), but adding structured 'depicts' annotations remains a challenging task, particularly since there is no strong guidance on use of standard controlled vocabularies. Also such vocabularies can't always meet the needs of highly diverse media collections and multi-lingual & multi-cultural contexts.
But there are possible pathways to create more structured and user-friendly workflows for the application of specialist vocabularies, such as Iconclass [2], when it comes to images of fine art in particular.
Myself (a UX designer & experienced Wikidata / Wikibase user), an art historian and DH researcher - Dr Karin de Wild, and the developer of the Iconclass Browser - Etienne Posthumus, have proposed a small new research grant to Wikimedia [3]. Our goal is to research and prototype several routes to make the addition of standard Iconclass terms as structured data on Commons, as well as the reuse of these data statements, an easier and more intuitive task for users of Commons services, GLAM professionals who may have collections described with Iconclass codes already, or DH researchers who want to run queries against the Wiki Commons query service and discover interesting data correlations across works from multiple collections. This is framed as a research endeavor, rather than just a technical project, because we are aware Iconclass is not a perfect vocabulary, but working closely with the Iconclass community, and the international communities of Wikidata / Wiki Commons users, we will research how the vocabulary can better meet the needs of diverse use-cases, rather than just implementing it without effort to respond to justified critiques.
If this is something of interest to you, please review our application and consider leaving some feedback via the form [4]. All feedback is much appreciated and will help us refine our proposal if we get to Stage II of the process, or help us apply for further funding opportunities in the future.
Many thanks and kind regards,
Lozana
(User: Loz.ross<https://meta.wikimedia.org/wiki/User:Loz.ross>)
[1] https://commons.wikimedia.org/wiki/Commons:Structured_data
[2] https://test.iconclass.org/
[3] https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Research_Fund/Ima…
[4] https://meta.wikimedia.org/wiki/Grants_talk:Programs/Wikimedia_Research_Fun…
---
Dr. Lozana Rossenova
Researcher @ Open Science Lab, TIB Hannover
Wikibase Community Manager @ NFDI4Culture
ORCID: 0000-0002-5190-1867
Kaya
I have created a wishlist for Commons to have all the phabricator
tickets(approximately 900) fixed, the video upload issues to be fixed, tfa
to be added to existing tools. Via a team of Staff and volunteers being
created to focus on Commons.
Two fold fix the existing problems, and then make it possible to bring new
multimedia content to the projects.
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Multimedia_a…
Its in your hands now.
--
GN.
Hello, I'd like to refer to the original subject of the discussion -
tomorrow is the last day for submitting proposals for the Community
Wishlist Survey 2022.
Apart from that, everyone is welcome to translate, promote, and discuss
proposals:
https://diff.wikimedia.org/2022/01/10/what-improvements-in-wikimedia-platfo…
Best wishes,
Szymon Grabarczuk (he/him)
Community Relations Specialist
Wikimedia Foundation
On Wed, Jan 12, 2022 at 2:43 PM Strainu <strainu10(a)gmail.com> wrote:
> În mar., 11 ian. 2022 la 08:01, Kunal Mehta <legoktm(a)debian.org> a scris:
> >
> > So I think the status quo can be changed by just about anyone who is
> > motivated to do so, not by trying to convince the WMF to change its
> > prioritization, but just by doing the work. We should be empowering
> > those people rather than continuing to further entrench a WMF technical
> > monopoly.
> >
>
> Counterexample:
>
> https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
> (this was the situation that I quoted in my first email on this thread
> as the WMF refusing to even do reviews).
>
> Maybe it's just the multimedia part that it's in this desperate
> situation, but I can totally see volunteer developers getting
> discouraged quickly if their patches are outright ignored.
>
> Strainu
> _______________________________________________
> Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
Dear All,
Wiki Loves Folklore is back this year on Wikimedia commons to be held from
1st of February till the 28th of February 2022. We need your support in
participation and translation of project pages to share a word in your
native language.
Concurrently with the photo contest we will be having a writing competition
called Feminism and Folklore. It will be held from 1st of February till the
31st of March 2022. We would like various Wikimedia communities to take
part in it.
Feel free to organise both the contest locally
We look forward for your immense participation in both the projects.
Warm regards,
Tiven Gonsalves (User:Tiven2240)
Coordinator WLF & FNF
*https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Folklore_2022
*
https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Folklore_2022/Organize
*
https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Folklore_2022/Transla…
*https://meta.wikimedia.org/wiki/Feminism_and_Folklore_2022
*https://meta.wikimedia.org/wiki/Feminism_and_Folklore_2022/Project_Page
*
https://meta.wikimedia.org/wiki/Grants:Project/Rapid/Wiki_Loves_Folklore_20…
Hello everybody! A small, yet important change is coming to Structured
Data on Commons: users are now able to add references to a file’s
metadata.[1]
References were always a part of SDC, but until now they weren’t
visible to end users, nor was there an interface to add them. This has
been fixed with the current update.
References for SDC will work exactly like they work on Wikidata: you
can use URLs or items for reference; adding, removing and changing
references will share the same experience of doing it on Wikidata; and
there will be no limit to the number of references that can be added.
I am here in case you have any questions or requests for more information.
Cheers,
Luca / Sannita@WMF
[1] For more info, this is the Phabricator ticket covering this issue:
https://phabricator.wikimedia.org/T230315
Hi,
On 1/1/22 12:10, Asaf Bartov wrote:
> It seems to me there are *very few* people who could change status quo,
> not much more than a handful: the Foundation's executive leadership (in
> its annual planning work, coming up this first quarter of 2022), and the
> Board of Trustees.
If the goal is to get paid WMF staff to fix the issues, then you're
correct. However, I do not believe that as a solution is healthy
long-term. The WMF isn't perfect and I don't think it's desirable to
have a huge WMF that tries to do everything and has a monopoly on
technical prioritization.
The technical stack must be co-owned by volunteers and paid staff from
different orgs at all levels. It's significantly more straightforward
now for trusted volunteers to get NDA/deployment access than it used to
be, there are dedicated training sessions, etc.
Given that the multimedia stack is neglected and the WMF has given no
indication it intends to work on/fix the problem, we should be
recruiting people outside the WMF's paid staff who are interested in
working on this and give them the necessary access/mentorship to get it
done. Given the amount of work on e.g. T40010[1] to develop an
alternative SVG renderer, I'm sure those people exist.
Take moving Thumbor to Buster[2] for example. That requires
forward-porting some Debian packages written Python, and then testing in
WMCS that there's no horrible regressions in newer imagemagick, librsvg,
etc. I'm always happy to mentor people w/r to Debian packaging (and have
done so in the past), and there are a decent amount of people in our
community who know Python, and likely others from the Commons community
who would be willing to help with testing and dealing with whatever fallout.
So I think the status quo can be changed by just about anyone who is
motivated to do so, not by trying to convince the WMF to change its
prioritization, but just by doing the work. We should be empowering
those people rather than continuing to further entrench a WMF technical
monopoly.
[1] https://phabricator.wikimedia.org/T40010
[2] https://phabricator.wikimedia.org/T216815
-- Legoktm
Amir
you raise a good point how do things get into the next budget, the simple
answer is first to have people/teams responsible for each of the projects.
Having someone accountable stops the ball being dropped as easily, it means
WMF starts looking at needs on longer timetables. We've seen this with
everything else the WMF does but not where it matters the most the points
which each community relies on.
In the end we should go begging to WMF for platforms to maintained. nor
should we be fighting against a wishlist gadgets just to get heard even
when that list rejects us because its too big an issue.
On Tue, 11 Jan 2022 at 16:51, Amir Sarabadani <ladsgroup(a)gmail.com> wrote:
> (Speaking in my volunteer capacity)
> I doubt there is any malicious intent by WMF. I personally think the
> underlying problem is time. Let me explain.
>
> Fixing a big issue in software takes time (I wrote a long essay about it
> in this thread) so it makes sense WMF annual planning to focus on issues
> before they get to a level that hinders community's work. The problem is
> that an issue doesn't get enough attention if it's not severe enough to
> affect users so the cycle of frustration continues. For example, I sent an
> email in February 2021, at the start of annual planning, to one of the
> directors at product outlining all of the issues of multimedia stack.
> Because at that point, it wasn't this bad, it didn't make it to FY21-22
> plans. Now I feel like a cassandra. We have similar issues in lots of other
> places that will lead to frustration. Load balancers (pybal), dumps, beta
> cluster, flagged revs, patrolling tools, etc. etc.
>
> On Tue, Jan 11, 2022 at 8:21 AM bawolff <bawolff+wn(a)gmail.com> wrote:
>
>> Honestly, I find the "not in the annual plan" thing more damning than the
>> actual issue at hand.
>>
>> The core competency of WMF is supposed to be keeping the site running.
>> WMF does a lot of things, some of them very useful, others less so, but at
>> its core its mission is to keep the site going. Everything else should be
>> secondary to that.
>>
>> It should be obvious that running a 300 TB+ media store servicing 70
>> billion requests a month requires occasional investment and maintenance
>>
>> And yet, this was not only not in this year's annual plan, it has been
>> ignored in the annual plan for many many years. We didn't get to this state
>> by just 1 year of neglect.
>>
>> Which raises the question - If wmf is not in the business of keeping the
>> Wikimedia sites going, what is it in the business of?
>>
>> On Tue, Jan 11, 2022 at 6:01 AM Kunal Mehta <legoktm(a)debian.org> wrote:
>>
>>> Hi,
>>>
>>> On 1/1/22 12:10, Asaf Bartov wrote:
>>> > It seems to me there are *very few* people who could change status
>>> quo,
>>> > not much more than a handful: the Foundation's executive leadership
>>> (in
>>> > its annual planning work, coming up this first quarter of 2022), and
>>> the
>>> > Board of Trustees.
>>>
>>> If the goal is to get paid WMF staff to fix the issues, then you're
>>> correct. However, I do not believe that as a solution is healthy
>>> long-term. The WMF isn't perfect and I don't think it's desirable to
>>> have a huge WMF that tries to do everything and has a monopoly on
>>> technical prioritization.
>>>
>>> The technical stack must be co-owned by volunteers and paid staff from
>>> different orgs at all levels. It's significantly more straightforward
>>> now for trusted volunteers to get NDA/deployment access than it used to
>>> be, there are dedicated training sessions, etc.
>>>
>>> Given that the multimedia stack is neglected and the WMF has given no
>>> indication it intends to work on/fix the problem, we should be
>>> recruiting people outside the WMF's paid staff who are interested in
>>> working on this and give them the necessary access/mentorship to get it
>>> done. Given the amount of work on e.g. T40010[1] to develop an
>>> alternative SVG renderer, I'm sure those people exist.
>>>
>>> Take moving Thumbor to Buster[2] for example. That requires
>>> forward-porting some Debian packages written Python, and then testing in
>>> WMCS that there's no horrible regressions in newer imagemagick, librsvg,
>>> etc. I'm always happy to mentor people w/r to Debian packaging (and have
>>> done so in the past), and there are a decent amount of people in our
>>> community who know Python, and likely others from the Commons community
>>> who would be willing to help with testing and dealing with whatever
>>> fallout.
>>>
>>> So I think the status quo can be changed by just about anyone who is
>>> motivated to do so, not by trying to convince the WMF to change its
>>> prioritization, but just by doing the work. We should be empowering
>>> those people rather than continuing to further entrench a WMF technical
>>> monopoly.
>>>
>>> [1] https://phabricator.wikimedia.org/T40010
>>> [2] https://phabricator.wikimedia.org/T216815
>>>
>>> -- Legoktm
>>> _______________________________________________
>>> Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
>>> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>>>
>>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>>>
>> _______________________________________________
>> Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
>
>
> --
> Amir (he/him)
>
> _______________________________________________
> Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
> at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
--
GN.
Separate thread. I'm not sure which list is appropriate.
*... but not all the way to sentience
<https://en.wikipedia.org/wiki/The_Uplift_War>.*
The annual community wishlist survey (implemented by a small team, possibly
in isolation?) may not be the mechanism for prioritizing large changes, but
the latter also deserves a community-curated priority queue. To complement
the staff-maintained priorities in phab ~
For core challenges (like Commons stability and capacity), I'd be surprised
if the bottleneck were people or budget. We do need a shared understanding
of what issues are most important and most urgent, and how to solve them.
For instance, a way to turn Amir's recent email about the problem (and
related phab tickets) into a family of persistent, implementable specs and
proposals and their articulated obstacles.
An issue tracker like phab is good for tracking the progress and
dependencies of agreed-upon tasks, but weak for discussing what is
important, what we know about it, how to address it. And weak for
discussing ecosystem-design issues that are important and need persistent
updating but don't have a simple checklist of steps.
So where is the best current place to discuss scaling Commons, and all that
entails? Some examples from recent discussions (most from the wm-l thread
below):
- *Uploads*: Support for large file uploads / Keeping bulk upload tools
online
- *Video*: Debugging + rolling out the videojs
<https://phabricator.wikimedia.org/T248418> player
- *Formats*: Adding support for CML
<https://phabricator.wikimedia.org/T18491> and dozens of other
<https://phabricator.wikimedia.org/T297514> common high-demand file formats
- *Thumbs*: Updating thumbor <https://phabricator.wikimedia.org/T216815>
and librsvg <https://phabricator.wikimedia.org/T193352>
- *Search*: WCQS still <https://phabricator.wikimedia.org/T297454> down
<https://phabricator.wikimedia.org/T297454>, noauth option
<https://phabricator.wikimedia.org/T297995> wanted for tools
- *General*: Finish implementing redesign
<https://phabricator.wikimedia.org/T28741> of the image table
SJ
On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com> wrote:
> I'm not debating your note. It is very valid that we lack proper support
> for multimedia stack. I myself wrote a detailed rant on how broken it is
> [1] but three notes:
> - Fixing something like this takes time, you need to assign the budget
> for it (which means it has to be done during the annual planning) and if
> gets approved, you need to start it with the fiscal year (meaning July
> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
> people, get them hired) which can take from several months to years. Once
> they are hired, you need to onboard them and let them learn about our
> technical infrastructure which takes at least two good months. Software
> engineering is not magic, it takes time, blood and sweat. [2]
> - Making another team focus on multimedia requires changes in planning,
> budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
> idea? Most teams are already focusing on vital parts of wikimedia and
> changing the focus will turn this into a whack-a-mole game where we fix
> multimedia but now we have critical issues in security or performance.
> - Voting Wishlist survey is a good band-aid in the meantime. To at least
> address the worst parts for now.
>
> I don't understand your point tbh, either you think it's a good idea to
> make requests for improvements in multimedia in the wishlist survey or you
> think it's not. If you think it's not, then it's offtopic to this thread.
>
> [1]
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> [2] There is a classic book in this topic called "The Mythical Man-month"
>
> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote:
>
>> we have to vote for regular maintenance and support for
>> essential functions like uploading files which is the core mission of
>> Wikimedia Commons
>>
>
Hi Asaf,
That's a good response, but I'm not sure it provides a practical way
forward. How can volunteers bring this issue to the attention of the WMF
leadership to get the allocation of the time of Wikimedia staff who can
take ownership implement changes here?
Presumably emails on these lists have relatively little impact at the
most senior levels, so they aren't a good way forward - and similarly on
Phabricator.
The Wishlist provides a way of showcasing issues and a relatively clear
way forward to get them implemented, but with really limited capacity.
How would a case for technical support be made apart from that? It's not
clear if a simple survey would be sufficient. Would an RfC and
discussion on meta help? Does it need the media to be involved to make
it a public crisis? Or should it be proposed as a grant request, perhaps
for a Wikimedia affiliate to implement? Or is there another avenue that
could be persued? Bearing in mind that there's no practical way for
community members to propose changes to the WMF annual plan for multiple
years now.
Sorry to defocus things and express more frustration, but I think there
should be a clear way forward with this type of issue, which isn't
obvious right now. Personally, my hopes are on the Wishlist, although
I'll be reposting a 14-year-old issue there for the fifth time when that
process opens on the 10th January...
Thanks,
Mike
On 1/1/22 20:10:43, Asaf Bartov wrote:
> Writing in my volunteer capacity:
>
> On Sat, 1 Jan 2022, 08:43 Amir Sarabadani <ladsgroup(a)gmail.com
> <mailto:ladsgroup@gmail.com>> wrote:
>
>
> Honestly, the situation is more dire than you think. For example,
> until a couple months ago, we didn't have backups for the media
> files. There was a live copy in the secondary datacenter but for
> example if due to a software issue, we lost some files, they were
> gone. I would like to thank Jaime Crespo for pushing for it and
> implementing the backups.
>
> But I beat my drum again, it's not something you can fix overnight.
> I'm sure people are monitoring this mailing list and are aware of
> the problem.
>
>
> [My goal in this post is to ficus effort and reduce frustration.]
>
> Yes, people reading here are aware, and absolutely none of them expects
> this (i.e. multimedia technical debt and missing features) to be fixed
> overnight.
>
> What's lacking, as you pointed out, is ownership of the problem. To own
> the problem, one must have *both* technical understanding of the issues
> *and* a mandate to devote resources to addressing them.
>
> It is this *combination* that we don't have at the moment. Lots of
> technical people are aware, and some of them quite willing to work
> toward addressing the issues, but they are not empowered to set
> priorities and commit resources for an effort of that scale, and the
> problems, for the most part, don't easily lend themselves to volunteer
> development.
>
> It seems to me there are *very few* people who could change status quo,
> not much more than a handful: the Foundation's executive leadership (in
> its annual planning work, coming up this first quarter of 2022), and the
> Board of Trustees.
>
> Therefore, the greatest contribution the rest of us could make toward
> seeing this work get resourced is to help make the case to the
> executives (including the new CEO, just entering the role) with clear
> and compelling illustrations of the *mission impact* of such investment.
> In parallel, interested engineers and middle managers could help by
> offering rough effort estimates for some components, a roadmap, an
> overview of alternatives considered and a rationale for a recommended
> approach, etc.
>
> But this would all be preparatory and supporting work toward *a
> resourcing decision* being made. So long as such a decision isn't made,
> no significant work on this can happen.
>
> Finally, while it is easy to agree that *this* is necessary and useful
> on its own, to actual resource it in the coming annual plan it would be
> necessary to argue that it is *more* useful and necessary than some
> *other* work, itself also necessary and useful.
>
> Another thing that may help is being explicit about just how important
> this is, even literally saying things like "this would have far more
> impact on our X goal than initiative A, B, or C", naming actual
> resourced or potentially resourced things. It is sometimes difficult for
> managers who aren't practicing Wikimedia volunteers to assess just how
> necessary different necessary things are, from different community
> perspectives.
>
> And of course, one such opinion, or a handful, would not be a solid base
> for resourcing decisions, so perhaps a large-scale ranking survey of
> some sort would be helpful, as SJ implicitly suggested in the original post.
>
> Cheers,
>
> A.
> (In my volunteer capacity)
>
> _______________________________________________
> Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
> To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org