Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org wrote: Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one. Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting grandmothers use? Can you really call not having any (user-visible) threading model a threading model? From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter tries to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or just deal with having to dig through an undifferentiated pile of replies to find the ones that might be replying to the post they're interested in (phpbb, Facebook). ___ 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 Tue, Mar 17, 2015 at 10:56 AM, Risker risker...@gmail.com wrote: On 17 March 2015 at 10:49, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote: On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. The software can tell, but visually it is nearly impossible to determine which message is being responded to when everything has essentially the same indent level. Granted, but that's because the output format is poor rather than the software being unable to tell. Thank you, Brad. Is the output format not determined by the parameters in the software? The software knows the reply structure, but when outputting it ignores that structure beyond the maximum depth. It just strikes me as weird that the software that we keep being told will improve communication and collaboration is deliberately designed in such a way that it is difficult for the human users (as opposed to the software) to be able to immediately discern who is responding to whom. A summary of their rationale seems to be at https://www.mediawiki.org/wiki/Flow/User_to_User_Discussions#Thread_Depth_Models. I think I'll refrain from commenting on 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
On 15-03-17 10:56 AM, Risker wrote: It just strikes me as weird that the software that we keep being told will improve communication and collaboration is deliberately designed in such a way that it is difficult for the human users (as opposed to the software) to be able to immediately discern who is responding to whom. [...] that it is difficuly for [a very small subset of] human users [used to a different, baroque system] to be able to [...] I see, day in and day out, literally thouands upon thousands of fora on Internet where millions of people from grandmothers sharing their latest knitting tricks to software developers manage to communicate effectively and figure out who is talking despite the lack of indentation pushing everything in small boxes to the right margin, and without the ability (or need!) to work around the flaws of that system with horrid hacks like manual outdents. Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
Ricordisamoa wrote: Il 09/11/2014 18:33, MZMcBride ha scritto: Marc A. Pelletier wrote: But there is also a great heap of anecdotal data that shows that having to provide an email account increases the barrier of entry to users signing up. So, there's a tradeoff. Eh, I think the anecdotal data (such as Facebook's and Google's hundreds of millions account registrations) suggests that e-mail confirmation is not a huge barrier to entry for legitimate users. I think both Facebook and Google have enough staff resources to deal with spam, and they could even let bots create fake accounts as long as they don't harass other users, just to let the accounts counter increase. We can't afford that. I'm not sure what you mean by can't afford that. What specific behaviors are we trying to prevent? Account registration alone isn't really a problem on MediaWiki wikis, just as it isn't a problem on Facebook or Google. The system scales. But if the accounts are registering and then spamming (creating new pages, making bad edits to existing pages, etc.), that's a real problem that we should try to solve as efficiently and cleanly as possible. Volunteer time is definitely precious. I think calling this issue a sacred cow is a bit overblown, but requiring an e-mail address would be a violation of our shared values. We strive to be as open and independent as possible and requiring an e-mail address is antithetical to that. If anything, we could provide e-mail address aliases (e.g., mzmcbr...@en.wikipedia.org) for our users as a side benefit. What about case-sensitivity of user names vs email addresses then? This is tangential, but... we should fix usernames to be case-insensitive. And we should support login via e-mail address. And we should (properly) support a display name field, in my opinion. Hopefully, in time. :-) In addition to better heuristics, as Robert suggested, we could also focus on tasks such as https://phabricator.wikimedia.org/T20110, maybe. Using AbuseFilter to trigger CAPTCHAs seems like it would either be a really great or a really terrible idea. At least making this functionality available as an option to potentially try seems worthwhile. MZMcBride ___ 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
Yes, the plan is for editing posts to go everywhere. We want to go a little bit extra slow with deploying that feature just to make sure that the pieces we've put in place actually work properly. So it's rolling out to Mediawiki.org next week, and then English and Russian WP the week after. (The people at Russian WP that we've been talking to said that they weren't even interested in test pages until we had editing posts, because Russian is hardcore.) Having the ability to edit other people's posts can be very useful, but there's also a strong cultural tradition that says that we basically don't do it, except under certain circumstances. People using Flow won't necessarily come to it with that same tradition, so we want to see that the feature set encourages the useful editing, and doesn't encourage people to mess with the wording or intent of someone else's post. Once we've seen it in action for a little while, it'll go live to all the other languages. And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for. On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z...@mzmcbride.com wrote: Ricordisamoa wrote: Il 17/03/2015 23:29, Danny Horn ha scritto: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] By Mediawiki, do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model. Agreed. The ability of anyone to revert bad edits also acts a major anti-abuse feature. As has been pointed out many times, there's a very real spam concern if only the author and admins can edit posts. -- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 Erik B. says on that task that the deployment of ContentHandler should help. This is excellent news. Thanks for the detailed and timely reply. My thanks as well! This e-mail really helped alleviate some of my concerns with Flow's development. I have too much experience with Flow's predecessor LiquidThreads to say that I'm optimistic, but I'm definitely less concerned now about Flow's future than I was when I started the day. MZMcBride ___ 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
Il 18/03/2015 05:08, Danny Horn ha scritto: Yes, the plan is for editing posts to go everywhere. We want to go a little bit extra slow with deploying that feature just to make sure that the pieces we've put in place actually work properly. So it's rolling out to Mediawiki.org next week, and then English and Russian WP the week after. (The people at Russian WP that we've been talking to said that they weren't even interested in test pages until we had editing posts, because Russian is hardcore.) Having the ability to edit other people's posts can be very useful, but there's also a strong cultural tradition that says that we basically don't do it, except under certain circumstances. People using Flow won't necessarily come to it with that same tradition, so we want to see that the feature set encourages the useful editing, and doesn't encourage people to mess with the wording or intent of someone else's post. Once we've seen it in action for a little while, it'll go live to all the other languages. Of course it should be used carefully and for minor changes only. I agree with T91086 https://phabricator.wikimedia.org/T91086. And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for. On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z...@mzmcbride.com wrote: Ricordisamoa wrote: Il 17/03/2015 23:29, Danny Horn ha scritto: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] By Mediawiki, do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model. Agreed. The ability of anyone to revert bad edits also acts a major anti-abuse feature. As has been pointed out many times, there's a very real spam concern if only the author and admins can edit posts. -- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 Erik B. says on that task that the deployment of ContentHandler should help. This is excellent news. Thanks for the detailed and timely reply. My thanks as well! This e-mail really helped alleviate some of my concerns with Flow's development. I have too much experience with Flow's predecessor LiquidThreads to say that I'm optimistic, but I'm definitely less concerned now about Flow's future than I was when I started the day. MZMcBride ___ 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] Our CAPTCHA is very unfriendly
Il 18/03/2015 04:30, MZMcBride ha scritto: Ricordisamoa wrote: Il 09/11/2014 18:33, MZMcBride ha scritto: Marc A. Pelletier wrote: But there is also a great heap of anecdotal data that shows that having to provide an email account increases the barrier of entry to users signing up. So, there's a tradeoff. Eh, I think the anecdotal data (such as Facebook's and Google's hundreds of millions account registrations) suggests that e-mail confirmation is not a huge barrier to entry for legitimate users. I think both Facebook and Google have enough staff resources to deal with spam, and they could even let bots create fake accounts as long as they don't harass other users, just to let the accounts counter increase. We can't afford that. I'm not sure what you mean by can't afford that. What specific behaviors are we trying to prevent? Account registration alone isn't really a problem on MediaWiki wikis, just as it isn't a problem on Facebook or Google. The system scales. But if the accounts are registering and then spamming (creating new pages, making bad edits to existing pages, etc.), that's a real problem that we should try to solve as efficiently and cleanly as possible. Volunteer time is definitely precious. If a bot creates 10,000 Facebook profiles and fills them with bogus content, that's fine for them. More users, more ads, more money. But if it creates 10,000 Wikimedia accounts with bogus user pages, it isn't fine for us. Less trust between Wikimedians. I think calling this issue a sacred cow is a bit overblown, but requiring an e-mail address would be a violation of our shared values. We strive to be as open and independent as possible and requiring an e-mail address is antithetical to that. If anything, we could provide e-mail address aliases (e.g., mzmcbr...@en.wikipedia.org) for our users as a side benefit. What about case-sensitivity of user names vs email addresses then? This is tangential, but... we should fix usernames to be case-insensitive. And we should support login via e-mail address. And we should (properly) support a display name field, in my opinion. Hopefully, in time. :-) In addition to better heuristics, as Robert suggested, we could also focus on tasks such as https://phabricator.wikimedia.org/T20110, maybe. Using AbuseFilter to trigger CAPTCHAs seems like it would either be a really great or a really terrible idea. At least making this functionality available as an option to potentially try seems worthwhile. Definitely. MZMcBride ___ 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
Danny Horn schreef op 2015/03/17 om 21:08: And I'm glad to hear that this thread has come close to almost inspiring optimism. That's what I'm here for. In a sample of one. Still, I guess one finds solace where one can. KWW ___ 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
Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03: On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote: How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script? Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with new software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext. As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation. Risker/Anne Converting LQT to Wikitext would lose the major benefits of: * per-Topic watchlisting, * per-Topic category support, * Sortable views (with Filterable views on the roadmap [1]), as well as the immensely easier process for new-editors to be able to participate in discussions, and be notified about replies.[2] But it would provide the advantage of using the standardized discussion technique used in virtually all Wikimedia installations. There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. KWW ___ 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
Pardon me if I missed an announcement, but will there be any office hours about Flow in the near future? I have a few general questions about cross-wiki discussions and the relationship of Flow to VE. (I'm mostly focused on VE right now.) Thanks, Pine On Mar 16, 2015 11:21 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03: On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote: How about just converting those threads back to Wikitext, instead? That script already exists, I've seen it used on Mediawiki. Will it mess up the pages that have already been converted using that script? Bottom line, it makes no sense to replace software that was considered barely suitable when it was first developed with new software that can't even do what that old, long-neglected software could do...and in several cases, there is no intention to ever add the features already available using Wikitext. As expectations increase for project users to post their comments/concerns/ideas/observations on Mediawiki, the use of Flow will become a barrier for participation. Risker/Anne Converting LQT to Wikitext would lose the major benefits of: * per-Topic watchlisting, * per-Topic category support, * Sortable views (with Filterable views on the roadmap [1]), as well as the immensely easier process for new-editors to be able to participate in discussions, and be notified about replies.[2] But it would provide the advantage of using the standardized discussion technique used in virtually all Wikimedia installations. There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. KWW ___ 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, Sorry but Wikitext is of such a nature that I do not use it as much as possible. LiquidThreads was a huge step forward and I still find it astonishing that it was left to rot for such a long time.I really welcome the move towards Flow. Flow is not an inadequate substitute, it is what will replace wikitext hopefully soon for discussions. I cannot wait. Thanks, GerardM On 17 March 2015 at 06:43, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: Nick Wilson (Quiddity) schreef op 2015/03/16 om 17:51: LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. I assume that the intention is to greater increase the divide between Wikipedia editors and the Wikimedia Foundation? It would be nice if the WMF would focus on becoming good with the tools that editors use instead of attempting to convince them that inadequate substitutes are adequate. KWW ___ 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 Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. There was significant community interest and momentum behind LQT including various votes to enable it [1], and there is significant interest in Flow now [2]. The main thing that prevented LQT from wider adoption was not lack of community interest, it was our decision to put the project on hold due to both major architectural concerns and resource constraints at the time. We've committed to providing an upgrade path, and this is our follow-through to that commitment. Our main objective in Flow development is to solve for progressively more challenging collaboration/conversation use cases well, and to demonstrate positive impact at increasing scale, with the goal of providing a better experience for new and experienced editors alike. We recognize that we still have a long way to go, but we can already demonstrate that the system does one thing well, which is to make the process of using talk pages much more understandable for new users: https://www.mediawiki.org/wiki/Flow/Moderated_Testing,_November,_2014:_talk_pages_and_Flow We're also seeing, as Nick pointed out, that users in a mentorship use case are more likely to follow-up with their mentors. This is a pretty big deal -- quantitative research shows that this type of mentorship improves engagement and retention of new users. [3] So mentorship is an obvious early stage use case, even if the rest of a community functions through traditional talk pages. Village pump type pages that are fairly distinct from article talk pages are another obvious use case where a more forum-like system can relatively quickly outperform the talk page based approach that is rife with edit conflicts and other annoyances. We are trialing the first such use case in Catalan with lots of community participation. As for inconsistency and fragmentation of mediawiki.org, if anything, the conversion of LQT pages on mediawiki.org will create greater consistency as we're already using Flow on Beta Features talk pages ( https://www.mediawiki.org/wiki/Talk:Content_translation is a nice example of a feedback page with lots of continuous and substantive comments from experienced users). Flow may not serve major use cases on English Wikipedia today, or tomorrow; that's okay. Smaller projects are often happy to adopt technologies that may not meet the expectations of a large, mature community like en.wp yet, because they may be more concerned with the experience of new users than with the risks or inconveniences associated with features in earlier stages of development. (I am not dismissing either risks or inconveniences in saying so, as the requirements do of course differ at different scale.) We, in turn, remain committed to building tools that serve users well, continuously improving, and continuously demonstrating value through data and qualitative validation. [4] This is but a small step, but it's an important one. Erik [1] https://phabricator.wikimedia.org/search/query/radjv9rJZNLU/#R [2] https://www.mediawiki.org/wiki/Flow/Rollout [3] http://arxiv.org/pdf/1409.1496v1.pdf [4] What we learn is summarized in our quarterly reviews, most recently: https://upload.wikimedia.org/wikipedia/commons/5/5f/Collaboration_Q3_2014-15_WMF_Quarterly_Review.pdf -- 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] Starting conversion of LiquidThreads to Flow at mediawiki.org
Now done. (I'd meant to earlier, along with the Tech/News entry). Thanks for the reminder, and the general support. Specific suggestions/requests are much appreciated. Please do tell me which elements of LQT you (all) regularly use and can't see in the Sandbox or short-term roadmap. I'll respond to some of the other questions when I awake. On Mar 16, 2015 10:33 PM, Florian Schmidt florian.schmidt.wel...@t-online.de wrote: I fully upport and welcome this, but at least for Project:Support_desk you should communicate this on this LQT board, too, that it will be converted (if you didn't do hat already, i haven't looked now, because LQT ist terrible on mobile :P). There are probably very active supporters, who haven't subscribed this list, but they should have the possibility to post their needs and opinions about that. Best, Florian Gesendet mit meinem HTC - Reply message - Von: Nick Wilson (Quiddity) nwil...@wikimedia.org An: Wikimedia developers wikitech-l@lists.wikimedia.org Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org Datum: Di., März 17, 2015 01:51 LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4]) The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run. The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board. LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them. The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history. There’s a queue of new features in Flow that will be shipped over the next month or so: * Table of Contents is done * Category support for Flow Header and Topics is done * VE with editing toolbar coming last week of March (phab:T90763) [5] * Editing other people’s comments coming last week of March (phab:T91086) * Ability to change the width side rail in progress, probably out in April (phab:T88114]) * Search is in progress (no ETA yet) (phab:T76823) * The ability to choose which Flow notifications end up in Echo, watchlist, or both, and other more powerful options, will be coming up next (no ETA yet) That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] Much thanks, on behalf of the Collaboration Team, Quiddity (WMF) [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Hi Nick,
I'm glad the Foundation is finally valuing a usable discussion system.
Unfortunately, there are some serious issues with Flow which will
prevent my use of it in production if not addressed in full:
* Administrators *must* be able to to see a deleted Flow board without
undeleting it (T90972 https://phabricator.wikimedia.org/T90972)
* Ordinary users *must* be able to move topics between boards (T88140
https://phabricator.wikimedia.org/T88140)
* Ordinary users *must* be able to edit AND move AND indent AND dedent
other users' comments (T78253
https://phabricator.wikimedia.org/T78253)
* An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker
* Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)
I see that the implementation of many features was delayed at the
initial stage of development, but they can't be ignored when trying to
deploy such a software in production. Thank you.
Il 17/03/2015 01:51, Nick Wilson (Quiddity) ha scritto:
LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.
There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])
The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.
The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.
LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.
The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.
There’s a queue of new features in Flow that will be shipped over the
next month or so:
* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)
That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.
Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]
Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)
[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor proxy with blinded tokens
On 17 March 2015 at 02:55, Gergo Tisza gti...@wikimedia.org wrote: On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen dan...@nadir-seen-fire.com wrote: Bitcoin is not untraceable. An adversary capable enough to eavesdrop on dissidents' communication making them need Tor should be capable of tracing the publicly available bitcoin transaction logs back from the payment to the proxy owner to the originating non-anonymous financial transaction used to purchase the bitcoins. I'll admit not knowing much about bitcoin security, but isn't that what mixers are for? Pretty much nothing about Bitcoin works as advertised in the hype, except irreversibility of transactions (which works all too well). Everything will apparently be fixed later. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
Il 09/11/2014 18:33, MZMcBride ha scritto: Marc A. Pelletier wrote: But there is also a great heap of anecdotal data that shows that having to provide an email account increases the barrier of entry to users signing up. So, there's a tradeoff. Eh, I think the anecdotal data (such as Facebook's and Google's hundreds of millions account registrations) suggests that e-mail confirmation is not a huge barrier to entry for legitimate users. I think both Facebook and Google have enough staff resources to deal with spam, and they could even let bots create fake accounts as long as they don't harass other users, just to let the accounts counter increase. We can't afford that. CAPTCHA solutions (not necessarily text-based ones) should try to free our users from the day-to-day fight. Spambots (of which there are multitude, and that hammer any mediawiki site constantly) have gotten pretty good at bypassing captchas but have yet to respond properly to email loops (and that's a more complicated obstacle than first appears; throwaway accounts are cheap but any process that requires a delay - however small - means that spambot must now maintain state and interact rather than fire-and-forget). Hmmm, I imagine many spambots have already made this investment if they're dealing with popular systems that require e-mail address confirmation. Wikimedia is different. You shouldn't even need an account to edit, much less an e-mail address. But this is a philosophical and principle-based (principled, if you will!) decision, not really a user experience or technical decision, in my opinion. I think calling this issue a sacred cow is a bit overblown, but requiring an e-mail address would be a violation of our shared values. We strive to be as open and independent as possible and requiring an e-mail address is antithetical to that. If anything, we could provide e-mail address aliases (e.g.,mzmcbr...@en.wikipedia.org) for our users as a side benefit. What about case-sensitivity of user names vs email addresses then? MZMcBride ___ 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
Ricordisamoa wrote: Il 17/03/2015 23:29, Danny Horn ha scritto: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] By Mediawiki, do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model. Agreed. The ability of anyone to revert bad edits also acts a major anti-abuse feature. As has been pointed out many times, there's a very real spam concern if only the author and admins can edit posts. -- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 Erik B. says on that task that the deployment of ContentHandler should help. This is excellent news. Thanks for the detailed and timely reply. My thanks as well! This e-mail really helped alleviate some of my concerns with Flow's development. I have too much experience with Flow's predecessor LiquidThreads to say that I'm optimistic, but I'm definitely less concerned now about Flow's future than I was when I started the day. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
Il 10/11/2014 17:23, Chris Steipp ha scritto: On the general topic, I think either a captcha or verifying an email makes a small barrier to building a bot, but it's significant enough that it keeps the amateur bots out. I'd be very interested in seeing an experiment run to see what the exact impact is though. Google had a great blog post on this subject where they made recaptcha easier to solve, and instead, The updated system uses advanced risk analysis techniques, actively considering the user's entire engagement with the CAPTCHA--before, during and after they interact with it. That means that today the distorted letters serve less as a test of humanity and more as a medium of engagement to elicit a broad range of cues that characterize humans and bots. [1] So spending time on a new engine that allows for environmental feedback from the system solving the captcha, and that lets us tune lots of things besides did the user sending back the right string of letters, I think would be well worth our time. [1] - http://googleonlinesecurity.blogspot.com/2013/10/recaptcha-just-got-easier-but-only-if.html Il 04/12/2014 05:35, Robert Rohde ha scritto: We have many smart people, and undoubtedly we could design a better captcha. However, no matter how smart the mousetrap, as long as you leave it strewn around the doors and hallways, well-meaning people are going to trip over it. I would support removing the captcha from generic entry points, like the account registration page, where we know many harmless people are encountering it. However, captchas might be useful if used in conjunction with simple behavioral analysis, such as rate limiters. For example, if an IP is creating a lot of accounts or editing at a high rate of speed, those are bad signs. Adding the same external link to multiple pages is often a very bad sign. However, adding a link to the NYTimes or CNN or an academic journal is probably fine. With that in mind, I would also eliminate the external link captcha in most cases where a link has only been added once and try to be more intelligent about which sites trigger it otherwise. Basically, I'd advocate a strategy of adding a few heuristics to try and figure out who the mice are before putting the mousetraps in front of them. Of course, the biggest rats will still break the captcha and get through, but that is already true. Though reducing the prevalence of the captcha may increase the volume of spam by some small measure, I think it is more important that we stop erecting so many hurdles to new editors. -Robert Rohde Il 05/12/2014 06:28, Robert Rohde ha scritto: I suspect that a lot of the spam are the obvious things such as external links to junk sites and repetitive promotional postings, though perhaps there are also less obvious types of spam? I suspect we could weed out a lot of spammy link behavior by designing an external link classifier that used knowledge of what external links are frequently included and what external links are frequently removed to generate automatic good / suspect / bad ratings for new external links (or domains). Good links (e.g. NYTimes, CNN) might be automatically allowed for all users, suspect links (e.g. unknown or rarely used domains) might be automatically allowed for established users and challenged with captchas or other tools for new users / IPs, and bad links (i.e. those repeatedly spammed and removed) could be automatically detected and blocked. -Robert Rohde What about applying ClueBot NG's Vandalism Detection Algorithm https://en.wikipedia.org/wiki/User:ClueBot_NG#Vandalism_Detection_Algorithm to spam? At this point I think machine learning is the only way a real CAPTCHA can keep up with evil bots, and a text-based system (such as T34695 https://phabricator.wikimedia.org/T34695) would only be used for tuning, just as reCAPTCHA does. ___ 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
Il 17/03/2015 23:29, Danny Horn ha scritto: Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so. Here's how it breaks down: Coming out very soon: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] By Mediawiki, do you mean www.mediawiki.org? I would like to stress the importance of such ability for *all* wikis. On Wikimedia, unlike most other sites, nothing is 'owned' by someone, and protection is only a precautionary measure. Flow is supposed to work with this model. -- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2] -- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3] Working on these next: -- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4] -- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need to re-read the mountain of requests that have accumulated, and reach out again to you for fresh feedback. Improvements will aim to be continuous and incremental. Future plans, not scheduled yet: -- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor toolbar in the next couple of weeks. This version will just have three functions: Bold/Italics, Links and Mentions. (Mentions will have autocomplete with user names that have already participated in the thread.) We’ll definitely be doing more work on toolbars coming up, but we want to see how this first one works before we make any solid plans. -- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] -- No-JS and accessibility -- We’ve done some work on this, and there will be more coming up. [6] So there's a lot of work still to be done, but we're adding a lot of features. I hope this helps explain where we are in the process. We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC, so we can answer questions and talk about the project. If people are interested, we can schedule more of these. Thanks again for all the specific feature requests and concerns. We’ll be requesting larger and wider quantities of feedback in the near future, as some of the upcoming features are planned and built. Danny Phabricator tickets mentioned above: [1] Flow post editing for autoconfirmed users: https://phabricator.wikimedia.org/T90670 [2] Prototype for new indentation model: https://phabricator.wikimedia.org/T88501 [3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972 [4] Moving topics between boards: https://phabricator.wikimedia.org/T88140 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 [6] No-JS tracking: https://phabricator.wikimedia.org/T60019 Thanks for the detailed and timely reply. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Improving static analysis tools for MediaWiki.
Il 16/03/2015 09:37, Andre Klapper ha scritto: Hi Krys, On Mon, 2015-03-09 at 17:23 -0800, Krys Nu wrote: I wish to express my interest in working on the above mentioned project. I have the required technical skill -PHP- and I am willing tread new grounds. I would love to discuss more about the project, what is really expected of the student, to establish some measurable goals before getting myself soak into the community. Improving static analysis tools for MW sounds like a wide topic. Could you provide more context please? Is this about some proposed Google Summer of Code / Outreachy task? Is there a link to some wiki page or Phabricator task providing more details? A simple search does the job: https://phabricator.wikimedia.org/T89682 ;-) You might not get much feedback on a mailing list if you only write Please discuss with me without providing a proposal or question. :) Cheers, andre ___ 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
Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so. Here's how it breaks down: Coming out very soon: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] -- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2] -- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3] Working on these next: -- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4] -- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need to re-read the mountain of requests that have accumulated, and reach out again to you for fresh feedback. Improvements will aim to be continuous and incremental. Future plans, not scheduled yet: -- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor toolbar in the next couple of weeks. This version will just have three functions: Bold/Italics, Links and Mentions. (Mentions will have autocomplete with user names that have already participated in the thread.) We’ll definitely be doing more work on toolbars coming up, but we want to see how this first one works before we make any solid plans. -- Make the links to threads look nicer -- Yeah, this is annoying. It’s not in our top five list of annoyances at the moment, but we’ll keep checking off annoying items. Nicer links will get its turn. [5] -- No-JS and accessibility -- We’ve done some work on this, and there will be more coming up. [6] So there's a lot of work still to be done, but we're adding a lot of features. I hope this helps explain where we are in the process. We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC, so we can answer questions and talk about the project. If people are interested, we can schedule more of these. Thanks again for all the specific feature requests and concerns. We’ll be requesting larger and wider quantities of feedback in the near future, as some of the upcoming features are planned and built. Danny Phabricator tickets mentioned above: [1] Flow post editing for autoconfirmed users: https://phabricator.wikimedia.org/T90670 [2] Prototype for new indentation model: https://phabricator.wikimedia.org/T88501 [3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972 [4] Moving topics between boards: https://phabricator.wikimedia.org/T88140 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154 [6] No-JS tracking: https://phabricator.wikimedia.org/T60019 On Tue, Mar 17, 2015 at 12:51 PM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: On 17 mrt. 2015, at 19:45, Isarra Yos zhoris...@gmail.com wrote: On 17/03/15 15:32, Brad Jorsch (Anomie) wrote: On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org wrote: Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one. Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting grandmothers use? Can you really call not having any (user-visible) threading model a threading model? From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter tries to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or just deal with having to dig through an undifferentiated pile of replies to find the ones that might be replying to the post they're interested in (phpbb, Facebook). On a lot of sites they can also get away with a lack of threading because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here. I still think that a
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
Instead of dropping indents use something like {{od}}
On Tuesday, March 17, 2015, Danny Horn dh...@wikimedia.org wrote:
(sorry for reposting, the first version had attachments and wasn't
appearing in the archive)
As a PS to that long post, here's another long post. I mentioned above that
I'd get into more detail about indents and tangents.
Wikitext talk pages use indentation for two different reasons -- to create
visual separation between people's posts, and to create spin-off tangents
that follow a different path than the main flow of conversation in a
thread. They're both important functions, but they don't need the same
mechanism, and I'd argue that trying to do both with indentations makes
wikitext talk pages harder to participate in and understand.
Big, complicated Village pump conversations need lots of room for tangents
and subthreads. A simple back-and-forth conversation between two people
doesn't need that. But we've spent years counting colons and fixing other
people's indentations, to the point where it feels like a conversation can
only be worthwhile if it's diagonal.
The indentation model that we've been using on Flow is kind of an unhappy
compromise between the two different functions, and I don't think anybody
likes it much. It retains the idea that a reply should be indented just
because, but then it only goes to two levels of indentation. Once a thread
reaches the second indentation level, you can't create an out-of-synch
tangent even if you want to.
So we've figured out a new reply/indentation model that separates those two
functions. We've been testing it out on the flow-tests server [1], and
we're going to release it to Mediawiki soon.
Here's how it works:
If you're replying to the most recent post, then your reply just lines up
under the previous message. A two-person back and forth conversation just
looks flat, and the visual separation is noted with the user name and
timestamp.
If you're specifically replying to a previous post, then your reply creates
an indented tangent. If everybody responding on that tangent replies to the
last message in that subthread, then it'll stay at the same indentation
level. But if someone replies to an older message within the subthread,
then that creates a third indentation level. I think we've got it set to a
maximum of 8 possible indentation levels, and we just stop it there because
there's a point where you can't fit a lot of text in each line.
The big idea of the new system is that the indentation should actually mean
something. You should be able to tell the difference between a simple
conversation and a complicated conversation at a glance, and using indented
tangents helps you to spot the places in a conversation where there's a
disagreement or a deeper level of detail.
We've been running tests comparing the old and new indentation models with
several groups, and I think it's promising. You can check out the two
models here:
-- New model: http://flow-tests.wmflabs.org/wiki/Talk:Something
-- Old model (with 8 levels of indentation):
http://ee-flow.wmflabs.org/wiki/Talk:SomethingElse
So that is the Grand Unified Theory of Flow Indentation, in theory and
practice. I would be happy to hear what you think about it. There is a very
good chance that this model will continue the Flow tradition of pleasing
exactly nobody, and if that's the case, then we can keep talking about it
and making more changes. But there's also a chance that this is brilliant
and solves everything, so I want to give it a shot and see what happens.
On Tue, Mar 17, 2015 at 3:29 PM, Danny Horn dh...@wikimedia.org
javascript:; wrote:
Thanks for all of the questions and suggestions. Flow is still in active
development, and there's a lot of feature work being done right now. Some
of the features that have been mentioned in this thread are actually just
about to be released, and some are coming up over the next month or so.
Here's how it breaks down:
Coming out very soon:
-- The ability to edit other people's posts will be out on Mediawiki by
the end of next week. We’ve made a few interface changes to support that.
Posts that have been edited by someone that isn’t the original poster now
say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to
see what’s happened. When someone edits an existing post, we fixed the
diff
pages so that you can browse between previous and next changes. [1]
-- Sane threading model, with more levels for replies and tangents --
also
coming out next week. Talking about this feature gets super lengthy and
complicated, so I’ll write another post right after this one that will
give
all the details for people who are interested. [2]
-- Admins viewing deleted boards without undeleting it -- coming out in
three weeks. [3]
Working on these next:
-- Moving topics between boards -- We’ve got designs and estimates for
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Tue, Mar 17, 2015 at 10:43 AM, Petr Bena benap...@gmail.com wrote: I think you all missed some old good rants. So here is one :) why the hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read and remember? See https://phabricator.wikimedia.org/T59154. On Tue, Mar 17, 2015 at 3:45 PM, Isarra Yos zhoris...@gmail.com wrote: On a lot of sites they can also get away with a lack of threading because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here. Since the level of activity varies from wiki to wiki, a toggle to change the view mode of the discussion (plain vs indented) would be welcome: https://phabricator.wikimedia.org/T93024 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
(sorry for reposting, the first version had attachments and wasn't appearing in the archive) As a PS to that long post, here's another long post. I mentioned above that I'd get into more detail about indents and tangents. Wikitext talk pages use indentation for two different reasons -- to create visual separation between people's posts, and to create spin-off tangents that follow a different path than the main flow of conversation in a thread. They're both important functions, but they don't need the same mechanism, and I'd argue that trying to do both with indentations makes wikitext talk pages harder to participate in and understand. Big, complicated Village pump conversations need lots of room for tangents and subthreads. A simple back-and-forth conversation between two people doesn't need that. But we've spent years counting colons and fixing other people's indentations, to the point where it feels like a conversation can only be worthwhile if it's diagonal. The indentation model that we've been using on Flow is kind of an unhappy compromise between the two different functions, and I don't think anybody likes it much. It retains the idea that a reply should be indented just because, but then it only goes to two levels of indentation. Once a thread reaches the second indentation level, you can't create an out-of-synch tangent even if you want to. So we've figured out a new reply/indentation model that separates those two functions. We've been testing it out on the flow-tests server [1], and we're going to release it to Mediawiki soon. Here's how it works: If you're replying to the most recent post, then your reply just lines up under the previous message. A two-person back and forth conversation just looks flat, and the visual separation is noted with the user name and timestamp. If you're specifically replying to a previous post, then your reply creates an indented tangent. If everybody responding on that tangent replies to the last message in that subthread, then it'll stay at the same indentation level. But if someone replies to an older message within the subthread, then that creates a third indentation level. I think we've got it set to a maximum of 8 possible indentation levels, and we just stop it there because there's a point where you can't fit a lot of text in each line. The big idea of the new system is that the indentation should actually mean something. You should be able to tell the difference between a simple conversation and a complicated conversation at a glance, and using indented tangents helps you to spot the places in a conversation where there's a disagreement or a deeper level of detail. We've been running tests comparing the old and new indentation models with several groups, and I think it's promising. You can check out the two models here: -- New model: http://flow-tests.wmflabs.org/wiki/Talk:Something -- Old model (with 8 levels of indentation): http://ee-flow.wmflabs.org/wiki/Talk:SomethingElse So that is the Grand Unified Theory of Flow Indentation, in theory and practice. I would be happy to hear what you think about it. There is a very good chance that this model will continue the Flow tradition of pleasing exactly nobody, and if that's the case, then we can keep talking about it and making more changes. But there's also a chance that this is brilliant and solves everything, so I want to give it a shot and see what happens. On Tue, Mar 17, 2015 at 3:29 PM, Danny Horn dh...@wikimedia.org wrote: Thanks for all of the questions and suggestions. Flow is still in active development, and there's a lot of feature work being done right now. Some of the features that have been mentioned in this thread are actually just about to be released, and some are coming up over the next month or so. Here's how it breaks down: Coming out very soon: -- The ability to edit other people's posts will be out on Mediawiki by the end of next week. We’ve made a few interface changes to support that. Posts that have been edited by someone that isn’t the original poster now say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to see what’s happened. When someone edits an existing post, we fixed the diff pages so that you can browse between previous and next changes. [1] -- Sane threading model, with more levels for replies and tangents -- also coming out next week. Talking about this feature gets super lengthy and complicated, so I’ll write another post right after this one that will give all the details for people who are interested. [2] -- Admins viewing deleted boards without undeleting it -- coming out in three weeks. [3] Working on these next: -- Moving topics between boards -- We’ve got designs and estimates for this, and I’m expecting that to come out in April. [4] -- More powerful watchlist/notification functionality -- This is a very important feature that will be getting a lot of team attention over the next month. We need
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 17 mrt. 2015, at 19:45, Isarra Yos zhoris...@gmail.com wrote: On 17/03/15 15:32, Brad Jorsch (Anomie) wrote: On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org wrote: Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one. Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting grandmothers use? Can you really call not having any (user-visible) threading model a threading model? From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter tries to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or just deal with having to dig through an undifferentiated pile of replies to find the ones that might be replying to the post they're interested in (phpbb, Facebook). On a lot of sites they can also get away with a lack of threading because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here. I still think that a threading and collapsing model as in http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voor-android-apps.html#reacties http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voor-android-apps.html#reacties makes a lot more sense. It’s limited in width, readable, collapsible, has threading with indenting, has a maximum amount of indenting, and is a tech website that is also very intensive, and all over the place. DJ signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 17/03/15 15:32, Brad Jorsch (Anomie) wrote: On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org wrote: Indentation is a crappy workaround for when your communication system does not support a sane threading model - it isn't a threading model or a substitute for one. Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so on, or whatever other site you were referring to that knitting grandmothers use? Can you really call not having any (user-visible) threading model a threading model? From what I've seen of those types of discussions, people have to either explicitly refer back to whatever they're replying to (e.g. Twitter tries to, and doesn't very well from what I've seen), quote whatever they're replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or just deal with having to dig through an undifferentiated pile of replies to find the ones that might be replying to the post they're interested in (phpbb, Facebook). On a lot of sites they can also get away with a lack of threading because the discussions themselves are relatively inactive, where you don't have multiple people jumping in and replying to different points. Such inactivity isn't the case on many wikis, where discussion is more key to their functionality, and certainly shouldn't be an assumption here. - I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] looking for unit testing resources for bot development
I'm working on cleaning up the code[1] for GrantsBot[2] and generally getting it into better and more robust shape. I've started writing basic unit tests to assist in the refactoring process. Since it interacts so heavily with the MediaWiki API, however, this isn't a straightforward process, and it's even more complicated because I'll be rewriting it to use a different client library (so any mocks/stubs I include will need to be rewritten). Does anyone have thoughts on the best strategy for this, or, more generally, pointers to good resources for writing unit tests for API clients? -Frances [1] dev branch: https://github.com/fhocutt/grantsbot/tree/dev [2] a bot run by Community Resources to maintain the IdeaLab on MetaWiki: https://meta.wikimedia.org/wiki/User:GrantsBot ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] regarding gsoc 2015
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..?? do we need to solve any bugs..?? ___ 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, here I copy my message Petrb (talkcontribsblock) Hi, I think you all missed some old good rants. So here is one :) why the hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read and remember? On Tue, Mar 17, 2015 at 2:42 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) nwil...@wikimedia.org wrote: We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. Working watchlist functionality, see https://phabricator.wikimedia.org/T76862 and https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own pseudo-watchlist rather sucks, but at least it functions correctly. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] No thanks, I prefer this mailing list thread. Feel free to copy this there if you want, but please reply here too ___ 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 Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) nwil...@wikimedia.org wrote: We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. Working watchlist functionality, see https://phabricator.wikimedia.org/T76862 and https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own pseudo-watchlist rather sucks, but at least it functions correctly. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] No thanks, I prefer this mailing list thread. Feel free to copy this there if you want, but please reply here too ___ 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 Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:
* An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker
Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.
* Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)
Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.
--
Best regards,
Max Semenik ([[User:MaxSem]])
___
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
Il 17/03/2015 14:05, Max Semenik ha scritto:
On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:
* An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker
Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.
Software cannot understand which post a message replies to.
In case a sensible way of reducing clutter in the interface without
limiting indenting options can be found, I'll favor it.
* Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)
Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.
I have always been proud of contributing to projects that value
accessibility more than fancy animations.
Flow is a regression in regard to this.
___
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
Il 17/03/2015 14:34, Brad Jorsch (Anomie) ha scritto:
On Tue, Mar 17, 2015 at 9:05 AM, Max Semenik maxsem.w...@gmail.com wrote:
On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa
ricordisa...@openmailbox.org
wrote:
* An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker
Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.
I suspect this is referring to the misfeature where (in the current
configuration) it just stops indenting entirely after two levels, making it
impossible to follow the reply structure if it's not trivially simple.
Exactly.
* Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)
Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.
Just because too many websites allow themselves to be broken without
JavaScript doesn't mean we should too. If you want you could try to debate
that preview isn't basic functionality, but a dismissal like this is
simply uncalled for.
___
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 Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. ___ 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
Il 17/03/2015 14:45, Brad Jorsch (Anomie) ha scritto: On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. Of course. I was referring to an hypothetical single reply button. ___ 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
No thanks, I prefer this mailing list thread Hmm, but there are other people who use LQT all over the day and are very active in contributing (at least on Project:Support_desk), so they would have the chance to discuss with us there, if they aren't subscribers of this list (and don't want to be one). :) Best, Florian Freundliche Grüße Florian Schmidt -Original-Nachricht- Betreff: Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org Datum: Tue, 17 Mar 2015 14:43:17 +0100 Von: Brad Jorsch (Anomie) bjor...@wikimedia.org An: Wikimedia developers wikitech-l@lists.wikimedia.org On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) nwil...@wikimedia.org wrote: We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. Working watchlist functionality, see https://phabricator.wikimedia.org/T76862 and https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own pseudo-watchlist rather sucks, but at least it functions correctly. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] No thanks, I prefer this mailing list thread. Feel free to copy this there if you want, but please reply here too ___ 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
For my perspective (sorry if this is covered somewhere I've missed), who made the decision to do this conversion? One of my reasons for interest is that at en.wn we have LQT and *do not want* Flow. (A fairly good summary of the sense of the en.wn community is (1) we would rather LQT than Flow for our comments pages, (2) our comments pages, which are meant to hold up well when edited by people who are utterly clueless about wiki markup, are better off with LQT than as ordinary wiki pages, and (3) we mostly detest LQT and want straight wiki markup for all pages that are part of our project's primary function.) On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) nwil...@wikimedia.org wrote: LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4]) The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run. The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board. LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them. The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history. There’s a queue of new features in Flow that will be shipped over the next month or so: * Table of Contents is done * Category support for Flow Header and Topics is done * VE with editing toolbar coming last week of March (phab:T90763) [5] * Editing other people’s comments coming last week of March (phab:T91086) * Ability to change the width side rail in progress, probably out in April (phab:T88114]) * Search is in progress (no ETA yet) (phab:T76823) * The ability to choose which Flow notifications end up in Echo, watchlist, or both, and other more powerful options, will be coming up next (no ETA yet) That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] Much thanks, on behalf of the Collaboration Team, Quiddity (WMF) [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox -- Nick Wilson (Quiddity) Community Liaison 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] Starting conversion of LiquidThreads to Flow at mediawiki.org
On Tue, Mar 17, 2015 at 9:05 AM, Max Semenik maxsem.w...@gmail.com wrote:
On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa
ricordisa...@openmailbox.org
wrote:
* An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker
Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.
I suspect this is referring to the misfeature where (in the current
configuration) it just stops indenting entirely after two levels, making it
impossible to follow the reply structure if it's not trivially simple.
* Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)
Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.
Just because too many websites allow themselves to be broken without
JavaScript doesn't mean we should too. If you want you could try to debate
that preview isn't basic functionality, but a dismissal like this is
simply uncalled for.
___
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 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. The software can tell, but visually it is nearly impossible to determine which message is being responded to when everything has essentially the same indent level. There's also the huge waste of screen real estate - I knew it was bad on desktop, but I was surprised to see it looks almost as bad on a tablet when I had an opportunity to take a look. 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 17 March 2015 at 10:49, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote: On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. The software can tell, but visually it is nearly impossible to determine which message is being responded to when everything has essentially the same indent level. Granted, but that's because the output format is poor rather than the software being unable to tell. Thank you, Brad. Is the output format not determined by the parameters in the software? It just strikes me as weird that the software that we keep being told will improve communication and collaboration is deliberately designed in such a way that it is difficult for the human users (as opposed to the software) to be able to immediately discern who is responding to whom. Risker/Anne ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Application period for GSoC and Outreachy now open!
Google Summer of Code 2015 and Outreachy Round 10 have kicked off. We have already received a few proposals and a lot of projects have received tremendous interest. But some of these projects still lack mentors and we're hoping you might be interested in being one. 1. Cross-wiki watchlists[1]: A standalone cross-wiki watchlist web app has been proposed by Sitic. A prototype can be found at [2]. Missing mentors. 2. One stop translation[3]: Proposal by Phoneix303 for improving search for translation messages. 3. Show edits made on Commons on Watchlist[4]: Needs mentors. 4. Adding new datatypes in Wikidata[5]: Needs mentors and discussion. 5. Automatic analysis of Commons images for color-blind[6]: Needs discussion and mentors. 6. Adding user preference to deactivate/delete account[7]: Needs discussion and mentors. Your feedback on these is would be very helpful in pushing them forward. All projects in the pipeline can be found at [8]. [1]: https://phabricator.wikimedia.org/T92955 [2]: https://tools.wmflabs.org/watchr/ [3]: https://phabricator.wikimedia.org/T92929 [4]: https://phabricator.wikimedia.org/T91192 [5]: https://phabricator.wikimedia.org/T91505 [6]: https://phabricator.wikimedia.org/T59806 [7]: https://phabricator.wikimedia.org/T34815 [8]: https://phabricator.wikimedia.org/project/board/1042/ Thank you. Niharika. ___ 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 Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote: On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org wrote: Software cannot understand which post a message replies to. It can, and more easily than with raw wikitext, as long as the correct reply button is used, i.e. if people actually click reply instead of using the already-there box for creating a new top-level post in the topic. The software can tell, but visually it is nearly impossible to determine which message is being responded to when everything has essentially the same indent level. Granted, but that's because the output format is poor rather than the software being unable to tell. ___ 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
Erik Moeller schreef op 2015/03/17 om 1:39: On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com wrote: There doesn't seem to be any particular user demand to adopt Flow, so there's no reason to believe it will gain any more traction than LQT ever did. There was significant community interest and momentum behind LQT including various votes to enable it [1], and there is significant interest in Flow now [2]. The main thing that prevented LQT from wider adoption was not lack of community interest, it was our decision to put the project on hold due to both major architectural concerns and resource constraints at the time. We've committed to providing an upgrade path, and this is our follow-through to that commitment. [snip] As for inconsistency and fragmentation of mediawiki.org, if anything, the conversion of LQT pages on mediawiki.org will create greater consistency as we're already using Flow on Beta Features talk pages ( https://www.mediawiki.org/wiki/Talk:Content_translation is a nice example of a feedback page with lots of continuous and substantive comments from experienced users). I'm not arguing that nuking LQT isn't a good idea: that most certainly is. What I object to is this apparent intent to create two tiers of users: one tier that knows how to use the software and another tier that gets accustomed to a partially functional easy layer that provides no experience or training in how to maintain the actual project content, with no apparent bridge between the two. Between VE and LQT, newbies get provided with no experience in handling the easy cases of editing until they hit something that the simple tools can't handle, at which time they are suddenly faced with a wall of text that they have no experience in dissecting, parsing, and understanding and are expected to make a change in one of the hard parts. Much better to get them gradually accustomed to wikitext by performing small tasks than to just toss them in the deep end after their crutches break. Yes, there are at least five mixed metaphors in that last sentence, buy you get the drift. KWW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
