Re: [Wikimedia-l] Chapters and GLAM tooling
Erik Moeller wrote: I'm not seeing any developer contract time allocated to GLAM tooling work yet. At the same time I'm seeing reports of breakage and missing functionality in important tools running in Labs. To the extent that this breakage is due to Labs infrastructure or access to data, it's our job (WMF) to fix it and you should (continue to) poke us to do so -- but to the extent that it can be addressed in the tools themselves, I'd love to see chapters take this on directly. Maybe, but we need to clearly define what a smart investment of resources looks like. In my opinion, it's much closer to the development of an extension such as GWToolset than it is to trying to have someone hack at a few PHP scripts on Wikimedia Labs. Labs is a playground and Galleries, Libraries, Archives, and Museums are serious enough to warrant a proper investment of resources, in my view. Magnus and many others develop magnificent tools, but my sense is that they're largely proofs of concept, not final implementations. We need to build infrastructure, and while Labs is itself infrastructure, it's really a sandbox for neat ideas, not a proper resolution to technical problems facing the wikis. If people want to substantively contribute to the technical ecosystem, that requires fully integrating into it. This typically means developing and supporting a deployed MediaWiki extension or, more rarely, integrating directly into MediaWiki core. This type of development requires an intelligent and focused set of requirements for new extensions or development projects that gets a thorough review (and sign-off) by the people who will ultimately be deploying and indefinitely hosting this code. GLAMs and Chapters could make all kinds of investments into new functionality for the projects. Improved Wikidata modeling and data entry into Wikidata, an in-browser SVG (or rasterized image) editor, better media search, enhancements to Wikisource/OCR, etc. There's no shortage of work to be done, but it's moderately challenging currently to develop scalable solutions to the larger problems. If GLAMs and Chapters aren't willing to try to tackle a harder problem, there are also plenty of smaller improvements needed to both MediaWiki and its hundreds of extensions that could also benefit everyone. But again, the focus would be integrating into the Wikimedia technical platform and fixing issues in production, rather than trying to make Labs scripts and tools better. MZMcBride ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Chapters and GLAM tooling
Hoi, There are several issues and imho the one Erik mentions is crucial. When no money is intended for GLAM tool related work, nothing will happen. The situation will remain one where everybody is eying each other... are you going to make a move ... are you? If you are all for a comprehensive technical infra structure blabla, all well and good. Nothing is going to happen without an initiative and, any initiative that does not have funding support will end up on Labs. Fiddling with small scale improvements are nice, it will provide some solace but what we need is a next generation of tools and of particular importance is reporting. An environment is being developed for statistics and reporting but as far as I can see it is either really hard or developments are not being communicated or there is not much to report anyway. Erik challenges the chapters. I hope the chapters rise to the occasion and define a plan. From what I observed the most important part of the products that are of use to GLAMS, stability is the main thing. We need continuous reporting. We need the continuous availability of tools. That is very much more than only a question of Labs or not Labs. If anything it is a challenge to Erik how he envisions to provide a platform for statistics that will be continuously available and how he will ensure that tools are stable and are available. Thanks, GerardM PS The statistics for Wikidata are still broken and who is going to tackle that and the break in reporting ??? On 25 October 2014 16:16, MZMcBride z...@mzmcbride.com wrote: Erik Moeller wrote: I'm not seeing any developer contract time allocated to GLAM tooling work yet. At the same time I'm seeing reports of breakage and missing functionality in important tools running in Labs. To the extent that this breakage is due to Labs infrastructure or access to data, it's our job (WMF) to fix it and you should (continue to) poke us to do so -- but to the extent that it can be addressed in the tools themselves, I'd love to see chapters take this on directly. Maybe, but we need to clearly define what a smart investment of resources looks like. In my opinion, it's much closer to the development of an extension such as GWToolset than it is to trying to have someone hack at a few PHP scripts on Wikimedia Labs. Labs is a playground and Galleries, Libraries, Archives, and Museums are serious enough to warrant a proper investment of resources, in my view. Magnus and many others develop magnificent tools, but my sense is that they're largely proofs of concept, not final implementations. We need to build infrastructure, and while Labs is itself infrastructure, it's really a sandbox for neat ideas, not a proper resolution to technical problems facing the wikis. If people want to substantively contribute to the technical ecosystem, that requires fully integrating into it. This typically means developing and supporting a deployed MediaWiki extension or, more rarely, integrating directly into MediaWiki core. This type of development requires an intelligent and focused set of requirements for new extensions or development projects that gets a thorough review (and sign-off) by the people who will ultimately be deploying and indefinitely hosting this code. GLAMs and Chapters could make all kinds of investments into new functionality for the projects. Improved Wikidata modeling and data entry into Wikidata, an in-browser SVG (or rasterized image) editor, better media search, enhancements to Wikisource/OCR, etc. There's no shortage of work to be done, but it's moderately challenging currently to develop scalable solutions to the larger problems. If GLAMs and Chapters aren't willing to try to tackle a harder problem, there are also plenty of smaller improvements needed to both MediaWiki and its hundreds of extensions that could also benefit everyone. But again, the focus would be integrating into the Wikimedia technical platform and fixing issues in production, rather than trying to make Labs scripts and tools better. MZMcBride ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On 25 October 2014 15:09, Kim Bruning k...@bruning.xs4all.nl wrote: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 Quite apart from other issues, the author falls at the first hurdle; he fails to say what an IDE is. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Chapters and GLAM tooling
MZMcBride, 25/10/2014 16:16: But again, the focus would be integrating into the Wikimedia technical platform and fixing issues in production, rather than trying to make Labs scripts and tools better. False dichotomy IMHO. Usual example:* https://bugzilla.wikimedia.org/42259 Quite clearly WMF's responsibility to make it possible, but all the interfaces and value are in consumers/tools. Nemo (*) Yes, I know https://meta.wikimedia.org/wiki/Research:Page_view is being worked on. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Chapters and GLAM tooling
Federico Leva (Nemo) wrote: MZMcBride, 25/10/2014 16:16: But again, the focus would be integrating into the Wikimedia technical platform and fixing issues in production, rather than trying to make Labs scripts and tools better. False dichotomy IMHO. Usual example:* https://bugzilla.wikimedia.org/42259 Quite clearly WMF's responsibility to make it possible, but all the interfaces and value are in consumers/tools. Nemo (*) Yes, I know https://meta.wikimedia.org/wiki/Research:Page_view is being worked on. I think it's a limited view to suggest that the Wikimedia Foundation should only provide raw dumps and/or queryable data and have volunteers try to cobble together scripts and tools to interact with the data. That certainly can and should be a piece of this, but there's no good reason not to, for example, integrate page view graphs into MediaWiki's info action, allowing regular users to see quickly and easily see an article's page views over time. We already have queryable revision information, but we rely on external tools and services to try to graph edits over time, rather than having visual functionality integrated into MediaWiki. The same is true of visualizing a particular user's edits or other logged actions. We're relying on external tools when we should be trying to create tools that live within the technical platform that we've created. A generalized, scaleable graphing/visualization tool would be an excellent use of resources. Making such a tool could easily have a definable goal with clear requirements, and implementing and deploying such a tool would have a very clear benefit to all of our projects. We have a real problem turning proofs of concept into stable infrastructure. GLAMs and Chapters can invest in creating stable infrastructure, but that probably doesn't mean investing in Labs, exactly. Not if you want to have a long-term, substantive impact, in my opinion. Regarding page views data specifically, the Wikimedia Foundation has done a good deal of cookie-licking in this area and that really should be addressed. The linked bug report demonstrates what I'm talking about. It's been _years_ of waiting as various analytics team have come and gone (does anyone remember when Open Web Analytics was going to save the day?). And yet it's 2014 and we still can't answer the most basic analytics questions such as how many views did X article get this month? There has been some deep dysfunction in this area of the Wikimedia Foundation, but I don't know what any GLAM institution or Wikimedia Chapter can do about the analytics situation, so it may be best to focus on other areas in which making an impact is feasible. MZMcBride ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
Perpetuating it with a dedicated IDE wouldn't help it go away. בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On Oct 25, 2014 8:03 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Perpetuating it with a dedicated IDE wouldn't help it go away. I doubt that. Side by side wikitext and result, making you see the result of either in the other in real time could help adoption of wysiwyg techniques, help improve them, and help people ease in to using them. Your wonton dismissiveness is worrysome to me. בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On Sat, Oct 25, 2014 at 9:56 AM, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 25 October 2014 15:09, Kim Bruning k...@bruning.xs4all.nl wrote: [...] https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 Quite apart from other issues, the author falls at the first hurdle; he fails to say what an IDE is. ... so, what is it?? /me searches ah, Article: http://en.wikipedia.org/wiki/Integrated_development_environment Annotated image: http://i01.i.aliimg.com/photo/v0/267990999/Integrated_Development_Environment_IDE_software_for_embedded.jpg We already have many of these components (requested in the medium post, or in the image), as needed for editing an article: * Syntax highlighter https://www.mediawiki.org/wiki/User:Remember_the_dot/Syntax_highlighter (gadget) * Ajax preview (A few options. I've used user:js/ajaxPreview https://en.wikipedia.org/wiki/User:Js/ajaxPreview for many years and love it and strongly recommend it) * Split preview (side-by-side) https://en.wikipedia.org/wiki/Wikipedia:User_scripts#Previewing (although that doesn't have simultaneous scrolling, which would be fancy/nice. Also the width-drag doesn't seem to work. It probably just needs an update after 6 years..) * integrating the diff viewer with the syntax highlighted source text, sounds incredibly confusing, so let's not do that. Besides, we have ajax Show Changes. * We have a Section-edit link, for jumping to the right section * We have a Template/Page transclusion list, under the edit-source textarea We don't have HTML preview, which might be interesting. Surely it's possible to whip up a userscript for it, if anyone would actually find it massively useful. (Or, we can just leave the browser's own Web Developer bar open to see the HTML. ctrl-f is our friend.) It would be nice to get some of those userscripts turned into (global)Gadgets and/or Extensions, but they're all usable. The only thing they (and all our fancy optional extras) really need, is better visibility. There are a number of ideas to do that, at https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences and (especially the bottom of) it's talkpage. More ideas appreciated. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On 10/25/14, 7:20 PM, Amir E. Aharoni wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. What do you expect it to be replaced with? I don't care about wikitext per se, but as an external consumer of the open-source data dumps, having articles be in *some* kind of markup format is quite useful to me. The same is true for editing bots, among other things. And as long as there is some format, the IDE can simply target that format. :-) I can imagine many ways the markup format could be better, so by all means let's improve it. But I can also imagine a lot of ways the situation could be worse— such as not having a markup format! Best, Mark ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
Keep in mind that the projects on Y are brainstorms/seeds -- so it is important to keep that in perspective. By the time they've evolved they often look radically different. That said I think there is kernel of truth there. Our components solve often every problem with one solution. We do need a way to code on top of wikis, but that is not necessarily the same thing as a tool to quickly add/remove text. But we tend to think of them as one. Do we need a better interface for writing components of top of wikis -- I'd think so. Do we need a better way to edit text -- for sure. Are those two the same thing? Lila On Sat, Oct 25, 2014 at 11:03 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Perpetuating it with a dedicated IDE wouldn't help it go away. בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
Oh, it will remain, just internally. Maybe some day it will be replaced with pure XML, but that day is far away, and by the time it happens editors aren't supposed to care. (That's just me fantasizing; Parsoid people may have a different idea.) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2014-10-25 21:44 GMT+03:00 Mark delir...@hackish.org: On 10/25/14, 7:20 PM, Amir E. Aharoni wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. What do you expect it to be replaced with? I don't care about wikitext per se, but as an external consumer of the open-source data dumps, having articles be in *some* kind of markup format is quite useful to me. The same is true for editing bots, among other things. And as long as there is some format, the IDE can simply target that format. :-) I can imagine many ways the markup format could be better, so by all means let's improve it. But I can also imagine a lot of ways the situation could be worse— such as not having a markup format! Best, Mark ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
People Who Are Able to Edit Articles But Not to Code dismiss wiki syntax much more than I do. Most of them don't even bother to begin to understand it. The few who do are a rare exception. A wiki syntax IDE will not go a long way, as the article says, in helping them edit. They will still be forced to do mental mapping from [[]] to links, from to headings, and so on, even if it's shown side-by-side. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2014-10-25 21:22 GMT+03:00 Martijn Hoekstra martijnhoeks...@gmail.com: On Oct 25, 2014 8:03 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Perpetuating it with a dedicated IDE wouldn't help it go away. I doubt that. Side by side wikitext and result, making you see the result of either in the other in real time could help adoption of wysiwyg techniques, help improve them, and help people ease in to using them. Your wonton dismissiveness is worrysome to me. בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
I haven't had that experience with lightweight markup around here. The humanities, journalism, and creative-writing academics are the ones who seem to be the most enthusiastic adopters of Markdown in particular. It's taking off quite a bit as part of a simplify/concentrate movement, where people find WYSIWYG editors like Word too distracting, so have moved to using Markdown as a minimalist editing environment to concentrate on writing, at least for drafts. It also helps that it's easy to e-mail around. People Who Code are actually mostly absent from that trend— I don't think I've ever met a computer scientist who writes papers in Markdown. Wikitext, of course, especially as typically used in Wikipedia, does not look as nice and minimalist as an article draft in Markdown does. Which is where I think the majority of the problem lies, not in the concept of markup itself. -Mark On 10/25/14, 9:46 PM, Amir E. Aharoni wrote: People Who Are Able to Edit Articles But Not to Code dismiss wiki syntax much more than I do. Most of them don't even bother to begin to understand it. The few who do are a rare exception. A wiki syntax IDE will not go a long way, as the article says, in helping them edit. They will still be forced to do mental mapping from [[]] to links, from to headings, and so on, even if it's shown side-by-side. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2014-10-25 21:22 GMT+03:00 Martijn Hoekstra martijnhoeks...@gmail.com: On Oct 25, 2014 8:03 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Perpetuating it with a dedicated IDE wouldn't help it go away. I doubt that. Side by side wikitext and result, making you see the result of either in the other in real time could help adoption of wysiwyg techniques, help improve them, and help people ease in to using them. Your wonton dismissiveness is worrysome to me. בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Because, even though I'm well aware of the fact that lots of experienced wikipedians love wiki syntax, the wiki syntax must go away, and will go away. Maybe in five years, maybe ten, maybe twenty. But it will go away. Investing effort in an IDE for it is pointless. So fortunately we didn't invest in something five years ago with an expected lifespan of 10 to 25 years? Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or something like Winter) will remove the need to edit transclusions as part of the articles' source code in maybe three years (maybe much less). Development should focus on that, rather than on an IDE for a language that should as soon as possible become transparent to all editors. (This is not an official representation of the Wikimedia Foundation's opinion.) בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com כתב: On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Thank goodness this wasn't written five years ago, otherwise somebody could get the awful idea to implement it. Having a side by side really time wikitext - display doesn't sound like an aweful idea at all to me. I'm quite surprised anyone would find that aweful actually. I don't understand why you're so dismissive of that idea. --Martijn בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב: I spotted this article linked from news.ycombinator.com, arguing -well- what it says on the tin. ;-) Apologies if someone else already posted a link. https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8 I'm not sure scratches head. Well, if we allow lua in templates, I suppose things actually are already pretty Interesting. sincerely, Kim Bruning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org ?subject=unsubscribe ___ Wikimedia-l mailing list,
[Wikimedia-l] new Math options: phrasing the preferences
As a follow-up to the discussions about the new Math rendering options, I'd like to raise the question of how to write the preferences in way that will really be helpful to the users. I made a little patch at https://gerrit.wikimedia.org/r/#/c/167024/ It only fixes some minor things, and the problem is wider: How is a person supposed to choose the best option? What are modern browsers? If one thing is recommended for modern browsers, and another improves (or enhances) rendering on modern, which one should I choose? What is slow? Why is improved visual rendering mixed with accessibility in *two* options? Which accessibility features do I get in each option? Are they even different? These options confused me for years as a Wikipedia user. The recent developments in Math are great technically (kudos to Moritz, Gabriel, TheDJ and everybody else who was involved!), but the options are still not so helpful. Let's fix them! Suggestions?.. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On 10/25/2014 03:38 PM, Amir E. Aharoni wrote: (That's just me fantasizing; Parsoid people may have a different idea.) Parsoid, AFAIK, represents marked up articles as very strict HTML with Mediawiki-specific attributes - exactly what is needed to maintain a sane and consistent machine readable and manipulable representation, but about as human-friendly as a punch in the face. The idea, of course, is that we want the program and not people to have to manipulate the internal representation because, no matter how simplified you try to make it, editing code still sucks for 99% of humans. -- Marc ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
quiddity, 25/10/2014 20:26: We don't have HTML preview, which might be interesting. Surely it's possible to whip up a userscript for it, if anyone would actually find it massively useful. (Or, we can just leave the browser's own Web Developer bar open to see the HTML. ctrl-f is our friend.) Are you sure we don't? Well, last time I used livepreview was probably 2007 or so, but it's still in preferences. https://www.mediawiki.org/wiki/special:search/livepreview also not very useful. Nemo ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Chapters and GLAM tooling
On 10/25/2014 01:50 PM, MZMcBride wrote: [...] that probably doesn't mean investing in Labs, exactly. Not if you want to have a long-term, substantive impact, in my opinion. I'd like to address that particular recurrent canard here, if I may. Things that reside in labs are empathically /not/ second-class citizens by any stretch of the imagination. Perhaps our attempts to emphasise that Labs is not production were not clear enough about what me mean by the distinction - and because of that people have gotten the wrong impression about it. What not production means is simply a matter of (a) scaling and (b) service level. For the latter, all it means in practice is that if something in labs breaks not all of ops will drop what they are doing to attend it as we would for prod. It doesn't mean that we don't care that it broke, nor that it is of lesser importance - just that the impact is lower and therefore it is not reasonable to divert all resources to the issue. As for scaling, it will almost never be an issue until something becomes used frequently by a large fraction of the projects' user base. Labs remains a perfectly reasonable permanent home for anything that expects light or medium use - whether it's volunteer-driven or WMF-driven (deployment-prep is an excellent example of a service that lives in Labs which is used continually by almost all the devs and yet will never live in prod). Labs isn't a second-grade production for unimportant things; it's a more flexible, more open environment for general tooling and development. If anything, it's /prod/ that is more restricted (in who can use it, how complicated it is to be allowed to deploy there, what restrictions are place on what is there). Any GLAM tools would almost certainly live in Labs - whether it's been developped by the WMF, volunteers or Chapters - not because it's not worthy of production but because trying to make it into production services would make development and deployment immensely more complicated and much less flexible. The question shouldn't be Do we need to invest in Labs but How to we avoid the trouble of having to do this in production. -- Marc ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor
On Sat, Oct 25, 2014 at 1:23 PM, Federico Leva (Nemo) nemow...@gmail.com wrote: quiddity, 25/10/2014 20:26: We don't have HTML preview, which might be interesting. Surely it's possible to whip up a userscript for it, if anyone would actually find it massively useful. (Or, we can just leave the browser's own Web Developer bar open to see the HTML. ctrl-f is our friend.) Are you sure we don't? Well, last time I used livepreview was probably 2007 or so, but it's still in preferences. https://www.mediawiki.org/wiki/special:search/livepreview also not very useful. See links for Live preview earlier on in my message (a.k.a. Ajax Preview). (Or to repeat: https://en.wikipedia.org/wiki/User:Js/ajaxPreview which I heartily recommend, and there are 3 alternative items linked at the bottom of that page. The one in Special:Preferences isn't nearly as good.) Re: HTML-preview: I suspect I've misunderstood that section of the Medium post (I thought he was coming at it from a debugger angle, but possibly not). Now that I re-read it, I think maybe he's just asking for synchronous scrolling selection-highlighting in the side-by-side preview? ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Chapters and GLAM tooling
On Sat, Oct 25, 2014 at 7:16 AM, MZMcBride z...@mzmcbride.com wrote: Labs is a playground and Galleries, Libraries, Archives, and Museums are serious enough to warrant a proper investment of resources, in my view. Magnus and many others develop magnificent tools, but my sense is that they're largely proofs of concept, not final implementations. Far from being treated as mere proofs of concept, Magnus' GLAM tools [1] have been used to measure and report success in the context of project grant and annual plan proposals and reports, ongoing project performance measurements, blog posts and press releases, etc. Daniel Mietchen has, to my knowledge, been the main person doing any systematic auditing or verification of the reports generated by these tools, and results can be found in his tool testing reports, the last one of which is unfortunately more than a year old. [2] Integration with MediaWiki should IMO not be viewed as a runway that all useful developments must be pushed towards. Rather, we should seek to establish clearer criteria by which to decide that functionality benefits from this level of integration, to such an extent that it justifies the cost. Functionality that is not integrated in this manner should, then, not be dismissed as proofs of concept but rather judged on its own merits. GWToolset [3] is a good example. It was built as a MediaWiki extension to manage GLAM batch uploads, but we should not regard this decision as sacrosanct, or the only correct way to develop this kind of functionality. The functionality it provides is of highly specialized interest, and indeed, the number of potential users to-date is 47 according to [4], most of whom have not performed significant uploads yet. Its user interface is highly specialized and special permissions + detailed instructions are required to use it. At the same time, it has been used to upload 322,911 files overall, an amazing number even without going into the quality and value of the individual collections. So, why does it need to be a MediaWiki extension at all? When development began in 2012, OAuth support in MediaWiki did not exist, so it was impossible for an external tool (then running on toolserver) to manage an upload on the user's behalf without asking for the user's password, which would have been in violation of policy. But today, we have other options. It's possible that storage requirements or other specific desired integration points would make it impossible to create this as a Tool Labs tool -- but if we created the same tool today, we should carefully consider that. Indeed, highly specialized tools for the cultural and education sector _are_ being developed and hosted inside Tool Labs or externally. Looking at the current OAuth consumer requests [5], there are submissions for a metadata editor developed by librarians at the University of Miami Libraries in Coral Gables, Florida, and an assignment creation wizard developed by the Wiki Education Foundation. There's nothing improper about that, as Marc-André pointed out. As noted before, for tools like the ones used for GLAM reporting to get better, WMF has its role to play in providing more datasets and improved infrastructure. But there's nothing inherent in the development of those tools that forces them to live in production land, or that requires large development teams to move them forward. Auditing of numbers, improved scheduling/queuing of database requests, optimization of API calls and DB queries; all of this can be done by individual contributors, making this suitable work for even chapters with limited experience managing technical projects to take on. On the analytics side, we're well aware that many users have asked for better access to the pageview data, either through MariaDB, or through a dedicated API. We have now said for some time that our focus is on modernizing the infrastructure for log analysis and collection, because the numbers collected by the old webstatscollector code were incomplete, and the infrastructure subject to frequent packet loss issues. In addition, our ability to meet additional requirements on the basis of simple pageview aggregation code was inherently constrained. To this end, we have put into production use infrastructure to collect and analyze site traffic using Kafka/Hadoop/Hive. At our scale, this has been a tremendously complex infrastructure project which has included custom development such as varnishkafka [6]. While it's taken longer than we've wanted, this new infrastructure is being used to generate a public page count dataset as of this month, including article-level mobile traffic for the first time [7]. Using Hadoop/Hive, we'll be able to compile many more specialized reports, and this is only just beginning. Giving community developers better access to this data needs to be prioritized relative to other ongoing analytics work, including but not limited to: - Continued development and maintenance of the above
Re: [Wikimedia-l] new Math options: phrasing the preferences
Amir, On 10/25/2014 01:16 PM, Amir E. Aharoni wrote: As a follow-up to the discussions about the new Math rendering options, I'd like to raise the question of how to write the preferences in way that will really be helpful to the users. I made a little patch at https://gerrit.wikimedia.org/r/#/c/167024/ thank you for your patch, I just merged it. I agree that the current options are confusing. We should be able to improve things a bit further by tweaking the descriptions, but in the longer term we are working towards having only a single mode that works really well, out of the box, for everybody. Before we can consider moving to One True Math mode, we need more refinement and testing, both with older browsers and various accessibility tools. It would also be nice to reduce the size of the SVG fall-back images, which are currently about 50% larger than the (low-resolution) PNGs. Thankfully, users with MathML-enabled browsers like Firefox don't even load them, and are now saving bandwidth relative to PNGs. Why is improved visual rendering mixed with accessibility in *two* options? Which accessibility features do I get in each option? Are they even different? As I understand it, client-side MathJax still defaults to an HTML+CSS rendering mode on browsers without MathML support, which provides better accessibility than the PNGs on IE 9 (so hardly 'modern'). It also has some nifty context menu features like zooming, but this could also be added to the server-side MathML mode. I added Moritz and Peter in the CC, maybe they can chime in. Gabriel ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
