I just tried to watch some presentation videos from Wikimania.
Some had very weak sound, some had no sound in the first minutes,
some only played the first minute and then stopped. I don't think
the Wikimania videos are unique in having such problems. Video is
new to Commons, and the expert contributors are more familiar with
still images.
How can we learn to make better videos? Are there some good
instructions? Perhaps a free instruction video (Wikibooks, but a
video instead of a book) on how to produce good videos is what we
need. In fact, the English Wikibooks has a title on "Video
Production", http://en.wikibooks.org/wiki/Video_Production but it
doesn't have a clear focus (pun not intended). It starts out with
discussing satellite TV and has long sections on file formats in
different operating systems.
There is a help page on Commons for converting video to the Ogg
Theora format, but that is only the last step in a long chain.
Given that video is new, how can we find and rate videos, nominate
"good/featured videos", and give advice on how to improve quality?
Is the Commons village pump enough for this? Commons has a
separate graphics village pump. Do we also need a separate video
village pump?
Current digital video cameras use hard disks or memory cards,
instead of tape cassettes. Many new models cost less than 300
euro (or dollars), some as little as 120 euro (memory card perhaps
not included). Some have a special "Youtube mode", and I guess
that kind of usage is what drives the price down. What models are
good, and what should one watch out for?
We can find free still photos on Flickr and copy them to Commons.
Is there somewhere we can find free videos and copy them? Yes, at
the Internet Archive. Somewhere else?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Dear Community members,
I hope you're doing well. We're excited to invite you to the upcoming Wiki
Loves Folklore 2024 Office Hour Part Two, where we'll be discussing how to
make our jury processes better.
Event Details:
- Date: March 2nd, 2024
- Time: 4:00 pm UTC https://zonestamp.toolforge.org/1709388000
- Where: Zoom
https://us06web.zoom.us/j/88637039784?pwd=AIGFVXsrMPB2piCVZ17acvacHuaZgR.1
What's Happening:
-
Introduction by Isaac Chabota Kanguya (Communication Officer): Isaac
will start things off with a quick 10-minute talk. He'll explain why having
fair and inclusive jury procedures is important for Wiki Loves Folklore.
-
Presentation by Suyash (Jury Coordinator for Wiki Loves Folklore
2024): Next,
Suyash will speak for 20 minutes about "How to Set Up a Good Jury for Wiki
Loves Folklore Photography Contest." He'll help to choose good pictures
-
Presentation by Nokib Sarkar (Lead Tool Developer for WLF 2024): Then,
Nokib will talk for 20 minutes about "How We Judge Writing Contests using
Campwiz Tool." He will show how to use the jury functionality in campwiz.
-
Questions and Chat Time: After the presentations, we'll have 10 minutes
for you to ask questions and share your thoughts.
We think this event will be really helpful, and we'd love for you to be
there. To save your spot, just click here
<https://meta.wikimedia.org/wiki/Wiki_Loves_Folklore_2024_Office_Hour_2#Part…>
Thanks so much for all your support with Wiki Loves Folklore. We're looking
forward to chatting with you soon!
Best,
Isaac Kanguya
Communication Officer International Team WLF 2024
Hello all!
We have been hard at work on our Graph Split experiment [1], and we now
have a working graph split that is loaded onto 3 test servers. We are
running tests on a selection of queries from our logs to help understand
the impact of the split. We need your help to validate the impact of
various use cases and workflows around Wikidata Query Service.
**What is the WDQS Graph Split experiment?**
We want to address the growing size of the Wikidata graph by splitting it
into 2 subgraphs of roughly half the size of the full graph, which should
support the growth of Wikidata for the next 5 years. This experiment is
about splitting the full Wikidata graph into a scholarly articles subgraph
and a “main” graph that contains everything else.
See our previous update for more details [2].
**Who should care?**
Anyone who uses WDQS through the UI or programmatically should check the
impact on their use cases, scripts, bots, code, etc.
**What are those test endpoints?**
We expose 3 test endpoints, for the full, main and scholarly articles
graphs. Those graphs are all created from the same dump and are not live
updated. This allows us to compare queries between the different endpoints,
with stable / non changing data (the data are from the middle of October
2023).
The endpoints are:
* https://query-full-experimental.wikidata.org/
* https://query-main-experimental.wikidata.org/
* https://query-scholarly-experimental.wikidata.org/
Each of the endpoints is backed by a single dedicated server of performance
similar to the production WDQS servers. We don’t expect performance to be
representative of production due to the different load and to the lack of
updates on the test servers.
**What kind of feedback is useful?**
We expect queries that don’t require scholarly articles to work
transparently on the “main” subgraph. We expect queries that require
scholarly articles to need to be rewritten with SPARQL federation between
the “main” and scholarly subgraphs (federation is supported for some
external SPARQL servers already [3], this just happens to be for internal
server-to-server communication). We are doing tests and analysis based on a
sample of query logs.
**We want to hear about:**
General use cases or classes of queries which break under federation
Bots or applications that need significant rewrite of queries to work with
federation
And also about use cases that work just fine!
Examples of queries and pointers to code will be helpful in your feedback.
**Where should feedback be sent?**
You can reach out to us using the project’s talk page [1], the Phabricator
ticket for community feedback [4] or by pinging directly Sannita (WMF) [5].
**Will feedback be taken into account?**
Yes! We will review feedback and it will influence our path forward. That
being said, there are limits to what is possible. The size of the Wikidata
graph is a threat to the stability of WDQS and thus a threat to the whole
Wikidata project. Scholarly articles is the only split we know of that
would reduce the graph size sufficiently. We can work together on providing
support for a migration, on reviewing the rules used for the graph split,
but we can’t just ignore the problem and continue with a WDQS that provides
transparent access to the full Wikidata graph.
Have fun!
Guillaume
[1]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_split
[2]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_up…
[3]
https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Federation
[4] https://phabricator.wikimedia.org/T356773
[5] https://www.wikidata.org/wiki/User:Sannita_(WMF)
--
Guillaume Lederrey (he/him)
Engineering Manager
Wikimedia Foundation