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
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 :-)
On Mon, Dec 31, 2018 at 5:51 PM Samuel Klein <meta.sj(a)gmail.com> wrote:
Dear Kiril, I assume you mean these lovely experiments
by Shared Knowledge:
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?
The problem is that a general community consensus
can not be easily
even when the novelty is an obvious improvement
and the changes usually
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.
There are two relatively recently developed
components in MediaWiki
are important for developers: Content Model and
They are not discussed very much among the less
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 <
P.S. I can give you a very nice example of this
happening in practice
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
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.
On Mon 31. Dec 2018 at 19:59, Kiril Simeonovski <
I agree that more or less we know what activities are intended for new
> 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
> the translation tool or to continue with the
old-fashioned code editor.
> There are multiple pros and cons of either decision but it is
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
> 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
reach out to are smart in pinpointing
Wikipedia's weaknesses and are
> to propose innovative solutions that primarily aim at making the
> reader-friendlier. The problem is that a
general community consensus
easily bypassed even when the novelty is an obvious improvement
the changes usually get rejected as good-faith
Wikimedia-l mailing list, guidelines at:
New messages to: Wikimedia-l(a)lists.wikimedia.org