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...@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_Macedonia > > 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.simeonov...@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.simeonov...@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: Wikimediaemail@example.com > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe> -- James Heilman MD, CCFP-EM, Wikipedian _______________________________________________ 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: Wikimediafirstname.lastname@example.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>