Re: [Wikitech-l] regarding gsoc 2015
On Mar 19, 2015, at 12:24 AM, Arindam Padhy b113...@iiit-bh.ac.in wrote: can you mention where exactly are the microtasks present for the following project. Extension to identify and delete spam pages Clicking on that link would show you this: https://phabricator.wikimedia.org/T90238 https://phabricator.wikimedia.org/T90238 where “Microtasks” are listed right at the end of the Description. The crossed out ones have been completed. The others are left. You can comment on the task itself to ask for further help, if something isn’t clear. On Wed, Mar 18, 2015 at 11:09 PM, Niharika Kohli niharikakohl...@gmail.com wrote: Hello Arindam, There are 3 different ideas listed under Mediawiki extensions on https://www.mediawiki.org/wiki/Outreach_programs/Possible_projects https://www.mediawiki.org/wiki/Outreach_programs/Possible_projects If you click on these, you’ll see a Phabricator task which explains the idea and suggests some microtasks that a prospective student should work on. You can start working on the one(s) you find interesting. Also, you can start writing a proposal for the project you want to work on. How to write a proposal is explained on the page linked above itself. Thank you! Niharika. On Mar 18, 2015, at 9:57 PM, Arindam Padhy b113...@iiit-bh.ac.in wrote: i am interested in the mediawiki extensions idea proposed by the org. what should i do next...?? On Wed, Mar 18, 2015 at 5:56 PM, Quim Gil q...@wikimedia.org wrote: Hi Arindam, On Tue, Mar 17, 2015 at 8:58 PM, Arindam Padhy b113...@iiit-bh.ac.in wrote: hello i am a b.tech student pursuing my carrer at iiit bhubaneswar,india. i am deeply interested in gsoc 2015 and wanted to do a project under this organization. how should i proceed..?? Please go to https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015 and check the project ideas proposed. do we need to solve any bugs..?? Yes, we are requiring candidates to solve microtasks as part of their evaluation. Every project idea proposed has a list of suggested microtasks. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 2015-03-18 11:31 PM, Isarra Yos wrote: On 19/03/15 01:42, Danny Horn wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. I'm a little confused. Didn't LQT already solve this problem? Why not just nest/thread things the same way it does, or how well-formatted wikitext conversations in general do? That seemed to work fine; the issues with LQT lay elsewhere, and the issue with wikitext really just seems to be it all needs to be done manually and users often don't get it right as a result, hence a good chunk of why we're trying to replace it in the first place. -I Yes, Wikitext conversations did have a threading pattern. From what I can see looking at a long discussion on a random FA talkpage archive it goes like this: Users indent after each message. Then when it gets too deep someone starts their message with 0 indentation. Conversations with larger messages end up reset quicker. Unfortunately this model cannot be applied to LQT or Flow. LQT just keeps indenting even when you would break because the indent is too deep. Flow tries to fix this by only indenting when replying in a spot where you can't just append. Frankly the WikiText indentation practice doesn't make sense in LQT or Flow. As I understand we always change the indentation in WikiText in part because it's hard to see where one user's message becomes another with just a signature to break the paragraphs into messages. That doesn't make sense in LQT or Flow where messages are structured and have an interface to differentiate them. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Maps
Heh, I'm not sure if I should laugh or groan. IIRC, Erik, Yuvi and others are prioritizing Labs reliability improvements for the next FY. I hope so. Pine On Mar 18, 2015 11:03 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi What is meant by real hardware ? Can we have some at Labs please? Thanks, GerardM And will this service be hosted on Wikimedia Labs? No, on real hardware. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Maps
Hoi What is meant by real hardware ? Can we have some at Labs please? Thanks, GerardM And will this service be hosted on Wikimedia Labs? No, on real hardware. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 19/03/15 07:00, Daniel Friesen wrote: On 2015-03-18 11:31 PM, Isarra Yos wrote: On 19/03/15 01:42, Danny Horn wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. I'm a little confused. Didn't LQT already solve this problem? Why not just nest/thread things the same way it does, or how well-formatted wikitext conversations in general do? That seemed to work fine; the issues with LQT lay elsewhere, and the issue with wikitext really just seems to be it all needs to be done manually and users often don't get it right as a result, hence a good chunk of why we're trying to replace it in the first place. -I Yes, Wikitext conversations did have a threading pattern. From what I can see looking at a long discussion on a random FA talkpage archive it goes like this: Users indent after each message. Then when it gets too deep someone starts their message with 0 indentation. Conversations with larger messages end up reset quicker. Unfortunately this model cannot be applied to LQT or Flow. Um... LQT has exactly that model. Yes, you can keep going, but you can keep going in wikitext, too, even off the side of the page (which is exactly what uncyclopedians do sometimes precisely because they want to go off the side of the page because they think it's funny, because let's face it, it is funny), but normally you just start a new conversation/thread/topic/whatever you want to call it if it goes too far. There's no way to solve the threading problem for long complex conversations directly because while you need that threading in order to discern who is responding to whom, or even what is going on in general, there is always only so much space on the screen. We accept this, we outdent, or we refocus with a new section after it gets too long/we feel like putting our usernames in the ToC, or we even wind up just having everyone involved creating their own thread from the start (because really, we all want our usernames in the ToC), but the problem of how to handle it has been solved in practice. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Maps
Hoi, Yes, and that why the Labs hardware should not be talked down. It is or it is not and truth apparently is in the eye of the one who sees it in its way. Thanks, GerardM On 19 March 2015 at 07:15, Pine W wiki.p...@gmail.com wrote: Heh, I'm not sure if I should laugh or groan. IIRC, Erik, Yuvi and others are prioritizing Labs reliability improvements for the next FY. I hope so. Pine On Mar 18, 2015 11:03 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi What is meant by real hardware ? Can we have some at Labs please? Thanks, GerardM And will this service be hosted on Wikimedia Labs? No, on real hardware. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Maps
On Mar 19, 2015 2:03 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: What is meant by real hardware ? https://en.wikipedia.org/wiki/Bare_metal_%28computer%29 Can we have some at Labs please? Labs nodes provisioned for and by labs users are virtual machines. Labs has dedicated bare metal just for labs but it is not directly exposed to labs users. We could theoretically copy the approach at http://www.rackspace.com/cloud/servers/onmetal but that probably would not be a very good allocation of resources. (both capital and human) Labs is well suited for virtualization. (nova and the other OSM, OpenstackManager are not perfect. We can and do fix them and if needed can explore other options. but bare metal is unnecessary for all labs workloads I'm aware of) -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 19/03/15 01:42, Danny Horn wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. I'm a little confused. Didn't LQT already solve this problem? Why not just nest/thread things the same way it does, or how well-formatted wikitext conversations in general do? That seemed to work fine; the issues with LQT lay elsewhere, and the issue with wikitext really just seems to be it all needs to be done manually and users often don't get it right as a result, hence a good chunk of why we're trying to replace it in the first place. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] VisualEditor on Wikipedia now faster with RESTBase
Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily - a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and - storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] looking for unit testing resources for bot development
On Wed, Mar 18, 2015 at 11:18 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: If you're using Pywikibot, you may want to have a look at its extensive unit tests :) Thanks. I'm not, but I'll take a look. -Frances ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Excellent. Just as a reminder: English-language video training for VisualEditor is in the queue for publication by mid-April, led by yours truly and with the assistance of a few collaborators. (: Pine On Mar 19, 2015 4:51 PM, Jared Zimmerman jared.zimmer...@wikimedia.org wrote: https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit just loaded in 2 seconds. Team is on fire. don't put them out. *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman http://loo.ms/g0 On Thu, Mar 19, 2015 at 4:41 PM, Arthur Richards aricha...@wikimedia.org wrote: Awesome! That is a truly significant improvement and quite an achievement. High-fives all around :D On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily - a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and - storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit just loaded in 2 seconds. Team is on fire. don't put them out. *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation M +1 415 609 4043 \\ @jaredzimmerman http://loo.ms/g0 On Thu, Mar 19, 2015 at 4:41 PM, Arthur Richards aricha...@wikimedia.org wrote: Awesome! That is a truly significant improvement and quite an achievement. High-fives all around :D On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily - a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and - storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Fantastic work! :) VisualEditor is becoming really zippy -- which had been one of the top concerns in user feedback in the past. Congratulations to everyone involved. Erik -- Erik Möller VP of Product Strategy, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Nice work! This is big. On Thu, Mar 19, 2015 at 3:08 PM Erik Moeller e...@wikimedia.org wrote: Fantastic work! :) VisualEditor is becoming really zippy -- which had been one of the top concerns in user feedback in the past. Congratulations to everyone involved. Erik -- Erik Möller VP of Product Strategy, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Great job team On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Amazing. Even for larger articles, it seems to load quicker, or at least as quick, as the classic edit box. Superb job! On Thu, Mar 19, 2015 at 10:52 PM Tomasz Finc tf...@wikimedia.org wrote: Great job team On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015- March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Gabrielle and All, Thanks for these great speedy innovations! Cheers, Scott On Mar 19, 2015 4:08 PM, Magnus Manske magnusman...@googlemail.com wrote: Amazing. Even for larger articles, it seems to load quicker, or at least as quick, as the classic edit box. Superb job! On Thu, Mar 19, 2015 at 10:52 PM Tomasz Finc tf...@wikimedia.org wrote: Great job team On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015- March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
On Thu, Mar 19, 2015 at 4:50 PM, Jared Zimmerman jared.zimmer...@wikimedia.org wrote: https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit just loaded in 2 seconds. Much of this is also owed to *a lot* of optimization work in VisualEditor over the last months. Plenty of ingenuity and hard work by the entire VisualEditor team and Ori went into making this possible. Cheers! Gabriel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] VisualEditor on Wikipedia now faster with RESTBase
Awesome! That is a truly significant improvement and quite an achievement. High-fives all around :D On Thu, Mar 19, 2015 at 3:05 PM, Gabriel Wicke gwi...@wikimedia.org wrote: Hello all, Earlier this morning, we made some good progress towards a faster VisualEditor experience by loading the HTML from https://rest.wikimedia.org/, the REST content API that entered beta production a bit over a week ago [1]. Preliminary data shows a drop of mean client HTML load times by close to 40% from about 1.9 seconds to 1.2 seconds. The reasons for this speed-up are primarily - a reduction in HTML size by 30-40%, achieved by storing page metadata separately in RESTBase [2], and - storing (rather than caching) the HTML of all Wikipedia articles, thus eliminating expensive cache misses. So far we have enabled this optimization on all Wikipedias. Other projects with VisualEditor support will follow over the next week. There are also a lot more optimizations in the pipeline. Eventually, we hope to completely eliminate the need to re-load the page for editing by using the same Parsoid-generated HTML for regular page views. While many people helped to make RESTBase and the content API a reality (see the original announcement [1]), I want to specially call out Marko Obrovac for doing much of the integration work with MediaWiki and the VisualEditor extension. I hope that you enjoy the newly faster VisualEditor experience as much as we do! Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-March/081135.html [2]: https://www.mediawiki.org/wiki/RESTBase ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [hackathon] Wikimedia Hackathon Lyon : Scholarship deadline
Hey all! In the name of Wikimedia France, I express to all attendees our deepest gratitude to see so much motivation for the hackathon! On the other hand, I'd like to remind all of you that you can apply for a scholarship til the 31st of March. Follow the link to apply: https://dons.wikimedia.fr/civicrm/event/register?reset=1id=8 Don't miss the deadline! :) Best regards, Alex. *Alexandre Cella* ASSISTANT LEVÉE DE FOND ET MÉCÉNAT FUNDRAISING AND SPONSORSHIP ASSISTANT *WIKIMEDIA FRANCE* +33 6 18 16 16 19 www.wikimedia.fr 40 rue de Cléry, 75002 Paris *Vos dons réguliers aident à faire fonctionner Wikipédia ! Soutenez Wikimédia France aujourd'hui* : https://dons.wikimedia.fr ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [GSoC] An enhanced cross-wiki watchlist as an OAuth tool – looking for mentors
(Jan is looking for GSoC mentors, and the deadline for submitting proposals with mentors is 27 March, next week. If you are interested, hurry up! https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015 ) On Thu, Mar 19, 2015 at 11:30 AM, Jan Lebert jan.leb...@online.de wrote: Hey everyone, I want to build a better watchlist as an OAuth tool – this would include cross-wiki watchlist notifications support as well as distinct features like inline diffs. I see the opportunity here to experiment with the design and do things differently without breaking any existing workflows. I've made a basic prototype at https://tools.wmflabs.org/watchr/ which currently orientates itself much on the MW watchlist design. It is currently quite limited and only queries a list of hand-picked projects. One of the things I would like to support is dynamic filtering (as shown by the search box in the prototype). See https://phabricator.wikimedia.org/T92955 for a screenshot and more details. It's build with a AngularJS frontend and a python backend. I'm looking for possible mentors, anyone interested? Feel free to ping me in IRC under the nick sitic, I idle around in the usual channels. Thanks sitic ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 4:42 AM, Isarra Yos zhoris...@gmail.com wrote:
...
Um... LQT has exactly that model. Yes, you can keep going, but you can keep
going in wikitext, too, even off the side of the page (which is exactly what
uncyclopedians do sometimes precisely because they want to go off the side
of the page because they think it's funny, because let's face it, it is
funny), but normally you just start a new conversation/thread/topic/whatever
you want to call it if it goes too far.
There's no way to solve the threading problem for long complex conversations
directly because while you need that threading in order to discern who is
responding to whom, or even what is going on in general, there is always
only so much space on the screen. We accept this, we outdent, or we refocus
with a new section after it gets too long/we feel like putting our usernames
in the ToC, or we even wind up just having everyone involved creating their
own thread from the start (because really, we all want our usernames in the
ToC), but the problem of how to handle it has been solved in practice.
LQT works well for the part of showing who is replying to who.
As for the cases where one would need to use {{outdent}} so that
each message has more horizontal space, I think it is possible for LQT/Flow
to have a system similar to this: when someone is reading a talkpage where there
is too many indentation, the user should be allowed to click in a given message
so that messages above it get collapsed, and its left margin is
reduced near to zero,
so that all replies (to replies (to replies...)) of that message now
have more space.
If reading this thread one gets too much indentation again, just
click in another message,
to focus on it, reset the margin again, and hide the previous comments.
On Thu, Mar 19, 2015 at 5:21 AM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
Perhaps the Flow interface needs high level support for something like
that. Something like how Discourse lets you fork a message into a new
topic and displays an interface bit that links to the new topic.
LQT already allows that. One just need to click on More Drag to
new location
and move it to a top level position. This will open a popup with this message:
To complete the following actions, please fill in a reason and click Confirm.
* Adjust post's position on the page
* Move post to its own thread
Reason: [__]
Subject for new thread (mandatory): [___]
[Confirm]
I've used this many times on Portuguese Wikibooks and it works well
for discussing new off-topic ideas which come up in the middle of
other discussions.
Best regards,
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [GSoC] An enhanced cross-wiki watchlist as an OAuth tool - looking for mentors
If any potential mentors are worried about the OAuth piece, I can help with that. Although I think OAuth is a pretty small piece of this project. On Thu, Mar 19, 2015 at 5:21 AM, Quim Gil q...@wikimedia.org wrote: (Jan is looking for GSoC mentors, and the deadline for submitting proposals with mentors is 27 March, next week. If you are interested, hurry up! https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015 ) On Thu, Mar 19, 2015 at 11:30 AM, Jan Lebert jan.leb...@online.de wrote: Hey everyone, I want to build a better watchlist as an OAuth tool - this would include cross-wiki watchlist notifications support as well as distinct features like inline diffs. I see the opportunity here to experiment with the design and do things differently without breaking any existing workflows. I've made a basic prototype at https://tools.wmflabs.org/watchr/ which currently orientates itself much on the MW watchlist design. It is currently quite limited and only queries a list of hand-picked projects. One of the things I would like to support is dynamic filtering (as shown by the search box in the prototype). See https://phabricator.wikimedia.org/T92955 for a screenshot and more details. It's build with a AngularJS frontend and a python backend. I'm looking for possible mentors, anyone interested? Feel free to ping me in IRC under the nick sitic, I idle around in the usual channels. Thanks sitic ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote: The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. From what I remember officewiki is pretty unused by most of the staff, so I'd doubt you'd get much usable feedback there. As someone who's used mediawiki for 10+ years I can say that *anything* is better than wikitext for discussion. I have a certain bias towards LQT and such, but that's because I actually want to use discussion pages for discussion and wikitext is basically the worst user experience in the world in this regard. You have a bias towards wikitext because it's been the only option and Wikimedia wikis have weirdly embraced the functionality and freedom it provides. Having that freedom hampered is surely painful to powerusers, but the new user experience isn't even comparable it's so much better. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 4:29 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: If you want to have a real world population of editors moving over to flow, try translatewiki.net when FLOW is ready. Check https://phabricator.wikimedia.org/T88102 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 19 March 2015 at 13:28, Ryan Lane rlan...@gmail.com wrote: On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote: The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. From what I remember officewiki is pretty unused by most of the staff, so I'd doubt you'd get much usable feedback there. As someone who's used mediawiki for 10+ years I can say that *anything* is better than wikitext for discussion. I have a certain bias towards LQT and such, but that's because I actually want to use discussion pages for discussion and wikitext is basically the worst user experience in the world in this regard. You have a bias towards wikitext because it's been the only option and Wikimedia wikis have weirdly embraced the functionality and freedom it provides. Having that freedom hampered is surely painful to powerusers, but the new user experience isn't even comparable it's so much better. I think you're mistaking me for someone else. I too have used wikitext for 10+ years - even though today I do the majority of my mainspace edits using Visual Editor. I get the idea of a better way of having discussions, and I also am happy that VE is well on its way. But quite honestly, what I'm seeing with Flow is...well, it reminds me of nothing more than the kinds of discussion systems that seemed old-fashioned and clunky even before I started editing Wikipedia. It wasn't envisioned as a discussion system, it was envisioned as a workflow system, and it shows. I routinely cannot tell who is responding to whom in Flow threads today on seldom-used and seldom-edited pages (I've never seen it used at all in any fast-moving discussions) and I'm hardly stupid - I've been participating in online discussion forums since the 1990s too. I am not married to the idea of using Wikitext, but I don't see the benefit in making an irreversible change in discussion software to a forum that is intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta and Commons and Wikidata) by applying software that isn't ready for prime time. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote: On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote: On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you. The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My content is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure. Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it). Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo , I find it much easier in the latter to see what is a reply to what. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. No thanks. Pretend real conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing. Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software. I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step. The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. Really? This is news to me and if true, I really ponder why paid staff members would not be actively trying to feed back to their team mates on why it is not working for them. In general this thread is really veering off topic in various directions. It would be great if people could start new conversations and phabricator discussions around particular bugs so that they don't get lost in the void of the ramblings of wikitech. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 18 March 2015 at 21:42, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. The problem with your testing process is that it is entirely possible for a response to one comment to also make sense as a response to other comments - which leads to miscommunication, confusion and difficulty figuring out who is saying what to whom. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you. The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My content is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure. Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it). Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo, I find it much easier in the latter to see what is a reply to what. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. No thanks. Pretend real conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you. The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My content is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure. Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it). Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo , I find it much easier in the latter to see what is a reply to what. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. No thanks. Pretend real conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing. Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software. I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step. ___enable __ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 3:19 PM, Risker risker...@gmail.com wrote: I am not married to the idea of using Wikitext, but I don't see the benefit in making an irreversible change in discussion software to a forum that is intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta and Commons and Wikidata) by applying software that isn't ready for prime time. As long as the structure of the conversation is stored by the new system (and I think both LQT and Flow do that - using a graph of what is a reply to what?) the presentation we have for this structure can be improved over time, or we can even have multiple ways for viewing a given conversation (e.g. with infinite indentation, completelly plain, limited indentation, flow's-new style, whatever). This is like the four View by options at https://lists.wikimedia.org/pipermail/wikitech-l/ I don't like the current limited indentation view implemented in Flow, but I like even less the lack of (semantic) structure of wikitext conversations. The :s are converted to dls and dts by MediaWiki, and this breaks every time someone adds an extra new line between comments (to tell apart one comment from the next) or when someone whants to discuss a table or a template. Best regards, Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 1:35 PM, John phoenixoverr...@gmail.com wrote:
If it's not clear ask for clarification. I am posting from my mobile, so I
don't have pretty screenshots handy. I am by no means suggesting that flow
should use a template. Instead when it detects a reply above a specific
indent level it uses the same functionality that od fulfilles
I don't see how that could work when someone wants to reply to a
comment which was made before the outdent template was added. In the
example below, the numbers indicate the time at which each commnent is
added. Once someone makes the 11th reply (in response to 9th comment),
it goest to the left, but then if someone makes a 12th comment
replying to the 1st comment, the formatting doesn't indicate this
anymore (it will appear that 12 is a reply to 11). The same problem
happens for each new reply to previous comments like 13 (which could
be a reply to 2, or to 12).
1
:2
::3
::6
:::7
8
:9
{{outdent|:}}11
:12
::13
:4
::10
:5
My suggestion on this aspect is
https://phabricator.wikimedia.org/T93238
Best regards,
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Ok stop being condescending and dismissive. I was proposing that type of
functionality be added to flow as an option for dealing with reply level
excessnes. It is a simple graphic to de-indent a discussion without much
disruption and it improves readability
On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
Hoi,
It does not scale in two ways:
- you do not get everybody to know about such trivia; there are more
relevant things to learn
- it may work on one wiki but how about the next ?
Remember this is Wikimedia-l not en.wikipedia-l
Thanks,
GerardM
On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com javascript:;
wrote:
What do you mean it doesn't scale?
On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
javascript:;
wrote:
Hoi,
REALLY .. never ever heard about that template ... and it does not
scale
Thanks,
GerardM
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
javascript:;
javascript:;
wrote:
I think my post might have gotten lost. But what is normal on wiki
when
we
hit a reasonable indentation level is to use a template like {{od}}
that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hoi,
Sorry if you feel that I am condescending. What you said was not clear at
all. For me it was not put in a way that made me understand that you were
proposing a solution. It came across as: look how great Wiki synax is; we
have templates..
I hate templates with a vengeance. They obfuscate what is being said, they
do not transcend the limits of a wiki and it makes people believe that the
templates in use are best practice. Maybe for them but not when you have a
profile on over 100 wikis like me.
Thanks,
GerardM
On 19 March 2015 at 17:17, John phoenixoverr...@gmail.com wrote:
Ok stop being condescending and dismissive. I was proposing that type of
functionality be added to flow as an option for dealing with reply level
excessnes. It is a simple graphic to de-indent a discussion without much
disruption and it improves readability
On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
Hoi,
It does not scale in two ways:
- you do not get everybody to know about such trivia; there are more
relevant things to learn
- it may work on one wiki but how about the next ?
Remember this is Wikimedia-l not en.wikipedia-l
Thanks,
GerardM
On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com
javascript:;
wrote:
What do you mean it doesn't scale?
On Thursday, March 19, 2015, Gerard Meijssen
gerard.meijs...@gmail.com
javascript:;
wrote:
Hoi,
REALLY .. never ever heard about that template ... and it does not
scale
Thanks,
GerardM
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
javascript:;
javascript:;
wrote:
I think my post might have gotten lost. But what is normal on wiki
when
we
hit a reasonable indentation level is to use a template like {{od}}
that
has a return and an arrow showing that the conversation is
continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
What do you mean it doesn't scale?
On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
Hoi,
REALLY .. never ever heard about that template ... and it does not scale
Thanks,
GerardM
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com javascript:;
wrote:
I think my post might have gotten lost. But what is normal on wiki when
we
hit a reasonable indentation level is to use a template like {{od}} that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hoi,
It does not scale in two ways:
- you do not get everybody to know about such trivia; there are more
relevant things to learn
- it may work on one wiki but how about the next ?
Remember this is Wikimedia-l not en.wikipedia-l
Thanks,
GerardM
On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com wrote:
What do you mean it doesn't scale?
On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:
Hoi,
REALLY .. never ever heard about that template ... and it does not scale
Thanks,
GerardM
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
javascript:;
wrote:
I think my post might have gotten lost. But what is normal on wiki when
we
hit a reasonable indentation level is to use a template like {{od}}
that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
I think my post might have gotten lost. But what is normal on wiki when we
hit a reasonable indentation level is to use a template like {{od}} that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote: On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you. The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My content is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure. Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it). Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo , I find it much easier in the latter to see what is a reply to what. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. No thanks. Pretend real conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing. Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software. I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step. The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Thu, Mar 19, 2015 at 11:08 AM, Jon Robson jdlrob...@gmail.com wrote: Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software. On the other hand, forcing people to dogfood a product with known issues is a sure way to piss people off and make them hate your product even after the issues are fixed. Without getting too specific, we know that from experience. I'm glad of the initial approach taken here, with the team reaching out to wikitech-l to ask about known issues before trying a deployment. I'll be even happier if I learn they have a plan for dealing with Murphy's law that isn't beg for patience while we rush to fix it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hoi, If you want to have a real world population of editors moving over to flow, try translatewiki.net when FLOW is ready. It is exclusively LQT and it has localisation in any languages always.You will not have any religious rants about Wikitext; there is none and, you will not have official bias. Thanks, GerardM On 19 March 2015 at 16:18, Risker risker...@gmail.com wrote: On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote: On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote: Brad: unfortunately, it's really hard to tell very much from a conversation with messages like 3: Post C: reply to Post A. You could do that with the old model, the new model or the perfect magic Nobel-Prize-winning discussion threading still to be discovered, and it would probably look like nonsense in all three. I shouldn't have used both numbers and post-names, but once I realized that it was already a bit late and it won't let me edit those posts. Someone with appropriate permissions is free to go back and edit them all to remove the number prefix and let the alphabetical order of the post-names suffice to indicate the chronological order of the postings, if that would make it less confusing for you. The point is the structure you're displaying doesn't make any sense, not that the content of my messages isn't anything that might make sense on its own. My content is explicitly simplified to illustrate the failings in the displayed structure. Structure should *facilitate* understanding, but in your demo I'd find that understanding the underlying structure of the conversation would be *despite* the broken display-structure. Nor is the point that people can screw up wikitext talk pages in ways that are even more confusing. That's a given, but Flow is supposed to do better. Right now it's worse than a well-formatted wikitext talk page (which has the advantage that human users can *fix* the structure when a newbie breaks it). Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of Topic:Sdrqdcffddyz0jeo to http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo , I find it much easier in the latter to see what is a reply to what. We've tried in our testing to pretend that we're having real conversations, so we could see whether there's any logical way to get to eight levels of nested threading. It's not easy to organize make-believe conversations, but if you want to start a thread, I'd be happy to fire up a few sockpuppets and pretend to talk about something with you. No thanks. Pretend real conversations are ok for a first assessment at usability, but by nature they're likely to be vapid and unlikely to have the inter-post complexity of actual conversations on-wiki where people are concentrating on actually communicating rather than on forcing a conversation for the sake of testing. Let's all be happy then that we are replacing an unloved broken talk extension with Flow on a wiki where we have real conversations then ...? :) actually dogfooding will make it much easier for us to communicate errors with the Flow team and help improve the software. I truly hope that soon we can get to a point where we can enable flow on all pages on mediawiki.org and this seems like the obvious first step. The dogfooding has been happening for a while on WMF's own office-wiki. We haven't heard any results about that. Is the system being used more than the wikitext system? (i.e., are there more talk page comments now than there were before?) Have users expressed satisfaction/dissatisfaction with the system? Have they been surveyed? Do they break down into groups (e.g., engineering loves it, grants hates it, etc...)? I hear some stories (including stories that suggest some groups of staff have pretty much abandoned talk pages on office-wiki and are now reverting to emails instead) but without any documentary evidence or analysis it's unreasonable to think that it is either a net positive OR a net negative. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hoi,
REALLY .. never ever heard about that template ... and it does not scale
Thanks,
GerardM
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com wrote:
I think my post might have gotten lost. But what is normal on wiki when we
hit a reasonable indentation level is to use a template like {{od}} that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
If it's not clear ask for clarification. I am posting from my mobile, so I don't have pretty screenshots handy. I am by no means suggesting that flow should use a template. Instead when it detects a reply above a specific indent level it uses the same functionality that od fulfilles ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
