With respect to complexity of language, we have some data in publication, looking at the the leads of English medical articles over time. Good news is that they have improved over the last 10 years from a reading level of close to "grade 16" to just under "grade 13". This has been a concerted effort by a small group of us since 2014 and I believe has helped approach our goal of writing for a general audience rather than a specialist one.
Happy holidays to those getting time off :-) James
On Mon, Dec 31, 2018 at 5:51 PM Samuel Klein meta.sj@gmail.com wrote:
Dear Kiril, I assume you mean these lovely experiments by Shared Knowledge:
https://commons.wikimedia.org/wiki/Category:Videos_from_the_Republic_of_Mace...
They are lovely, and look like they are now in use. I like specific examples like these; was there any description of the project afterwards covering its welcome, the steps towards its inclusion, notes for future research groups tackling similar projects in the future?
Kiril writes:
The problem is that a general community consensus can not be easily
bypassed
even when the novelty is an obvious improvement and the changes usually
get
rejected as good-faith attempts.
A dedicated Draft-Wiki, like [test] but for text and media, with much simpler standards for structure, sourcing, and metadata [perhaps combined w/ incubator?] would be a simple and welcome solution. It would help not only small media projects but also massive uploads from existing archives and GLAMs take their first steps without overly complicating things. I think this is one of the most valuable simple additions we could make.
There is also a more general solution already available: to create a new tool that participants in a new initiative use (which only later gets integrated fully into the standard workflow on various projects). But that takes a bit of technical preparation each time.
Amir writes:
There are two relatively recently developed components in MediaWiki
that
are important for developers: Content Model and Multi-Content
Revisions.
They are not discussed very much among the less technical editors
because
they are pretty internal, and I'm really not an expert on what they do myself, but as far as I understand them, they can serve as steps to implementing Jane's suggestion.
Yes! and thanks for bringing up T2167 -- that and adding a simple mechanism for federating such data (so that every owner of a lowly small-scale mediawiki instance can add to or revise metadata namespaces) feel more like a basic expansion of wiki-nature --- with associated expansion of the kinds and magnitude of knowledge included in our projects -- than like just another set of features.
Warmly + medialogically, SJ
On Mon, Dec 31, 2018 at 2:18 PM Kiril Simeonovski < kiril.simeonovski@gmail.com> wrote:
P.S. I can give you a very nice example of this happening in practice
from
my personal experience. Few years ago, we produced high-quality videos documenting physics and chemistry experiments that had to be added to related articles. The project was welcomed by some chapters, mostly despised by the Wikimedia Foundation, while the communities appeared to
be
not ready for the introduction of such videos with only some users on Wikimedia Commons showing some interest and sharing their thoughts.
The main problem seems to be the lack of coordination between various stakeholders inside the movement on technology-related questions that are strategically important for the future of Wikipedia.
Best, Kiril
On Mon 31. Dec 2018 at 19:59, Kiril Simeonovski < kiril.simeonovski@gmail.com> wrote:
Hi Paulo,
I agree that more or less we know what activities are intended for new
and
what for experienced users. The challenging part is to make a sensible decision on whether to reach out to new users using the visual editor
and
the translation tool or to continue with the old-fashioned code editor. There are multiple pros and cons of either decision but it is
reasonable
to
believe that these tools were developed for some specific purpose. This will gain even more weight once the mobile editing gets improved.
Other examples soliciting important decisions are whether and how to
allow
new users to use videos across articles or how to shape an article's structure that differs from the standard one. In many cases, people
that
we
reach out to are smart in pinpointing Wikipedia's weaknesses and are
eager
to propose innovative solutions that primarily aim at making the
articles
reader-friendlier. The problem is that a general community consensus
can
not be easily bypassed even when the novelty is an obvious improvement
and
the changes usually get rejected as good-faith attempts.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe