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: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
