Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
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] [1] See Pau's design notes at https://docs.google.com/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK95pc0Whs/edit#slide=id.p and Hhhippo's ideas/notes at https://en.wikipedia.org/wiki/User:Hhhippo/Flow/TOC_and_filters [2] The feedback from the ongoing trial at the Frwiki newcomers' helpdesk, is that the Flow version has better engagement, with more editors returning to give further information, or ask a followup question, or just to say thanks. https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux/Flow https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux Flow has been improving over the months. I hope you'll give it a try at the sandbox, check out the list of upcoming features (in 1st message), and let the team know what feature(s) you're most concerned about. The more specific the feedback, the more it will help influence the order new features are developed in. Thanks, as always :) Quiddity (WMF) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
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
Re: [Wikitech-l] Tor proxy with blinded tokens
On 2015-03-16 7:55 PM, Gergo Tisza 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? Assuming those work, they make bitcoin even less accessible to the nontechnical users and many of the users of the proxy would likely not do so, endangering themselves. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
On 16 March 2015 at 21:20, Ryan Lane rlan...@gmail.com wrote: 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. As someone who used LQT a lot, I'd say I'd much rather flow replace the pages I maintained using LQT. Maybe you dislike flow, but it's *way* more useful than wikitext for discussion. I never want to go back to the days where I needed to discuss things with wikitext ever again. Wikitext discussion pages are just the absolute worst. I hear what you are saying, Ryan. I'm also reflecting on the fact that as there is increasing pressure on ordinary editors to post their discussions about Mediawiki on the Mediawikiwiki, they would then encountering *another* new interface that doesn't operate in anything similar to what they've experienced before, and that we know isn't up to handling stuff that even LQT handled without blinking. On the other hand, based on what I'm hearing about the success of installing Flow on Office-wiki, the end result may very well be fewer people coming to complain about something else, which might be viewed as a net positive. 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
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 On 16 March 2015 at 20:51, 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] Tor proxy with blinded tokens
At the end of the day, the key is communicating with communities to work things out with them - and that may well have to happen on a project-by-project basis. Finding a mid-size project with a very active admin corps that would be willing to try out whatever you folks come up with is probably a place to start: if it goes well there, it will raise the chances of acceptance elsewhere. What needs to be demonstrated is that permitting editing through Tor under (to be specified) controlled conditions results in improvements to the targeted project without increased vandalism and spamming - and yes, it's entirely reasonable to expect that there will be active participation by those who are advocating this change to monitor and evaluate the change. Ensure that the processes for evaluating edits through those accounts are set up before activating the access, and have a pre-arranged set of conditions where the access would be withdrawn. Risker/Anne On 16 March 2015 at 01:29, Arlo Breault abrea...@wikimedia.org wrote: I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me). But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith. I’m more than willing to help out. Please get in touch. Arlo On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote: On Mar 11, 2015 2:23 AM, Gergo Tisza gti...@wikimedia.org (mailto: gti...@wikimedia.org) wrote: On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp cste...@wikimedia.org (mailto:cste...@wikimedia.org) wrote: I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, Special Account), so no special permissions are needed by the Special Account, and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to pull the plug if it looks like the edits are predominantly unproductive. I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set up at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly come from the IP address of the proxy so it would not be subject to Tor blocking. Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me. However, we could substitute the entire blinding process with a public page that the proxy posts to that says, this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion. And the proxy only allows tor editing by users with a passing vote. That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link them to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Proposal for Outreachy program 2015
Hi All, I am Dibya Singh and I am applying for FOSS Outreachy 10. I have selected a project from #possible-tech-projects list named One stop translation to improve consistency for translation. I have been in contact with mentor Niklas Laxström and Federico Leva alias for understanding the project in depth. I have drafted a rough proposal based on my interaction with the product as a user. Please find link for my proposal. Please give your valuable feedback. https://phabricator.wikimedia.org/T92929 Link for my mediawiki user page can be found here https://www.mediawiki.org/wiki/User:Phoenix303 Regards, Dibya Singh ___ 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
Fiayy! So happy to hear this is happening :) On 16 Mar 2015 17:52, 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 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. As someone who used LQT a lot, I'd say I'd much rather flow replace the pages I maintained using LQT. Maybe you dislike flow, but it's *way* more useful than wikitext for discussion. I never want to go back to the days where I needed to discuss things with wikitext ever again. Wikitext discussion pages are just the absolute worst. - Ryan ___ 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 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? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki tests will verify the completeness of $wgAvailableRights
This has been merged now. On Sat, 2015-02-21 at 18:27 +0100, hoo wrote: Hi Everyone, just wanted to quickly let you know that MediaWiki will verify that extensions register all rights they define in $wgAvailableRights (or using the UserGetAllRights hook). To make sure your extension complies with that just add all the rights your extension defines to $wgAvailableRights (which is a simple string[] of theses user rights). This test will be introduced with https://gerrit.wikimedia.org/r/192087 Cheers, Marius ___ 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] Improving static analysis tools for MediaWiki.
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? 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 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ 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 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
Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
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 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] Tor proxy with blinded tokens
On Mon, Mar 16, 2015 at 2:30 PM, Gergo Tisza gti...@wikimedia.org wrote: Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits. In some jurisdictions Bitcoin is outright prohibited, with penalties for end users for mere ownership of any amounts. Would be very funny to require people to expose their asses to more problems in order to edit Wikipedia. -- 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] Tor proxy with blinded tokens
I think pretty much anything is better than the current situation. I'd support this proposal. The timing is right too with the WMF vs NSA lawsuit just happening. On Mon, Mar 16, 2015 at 1:29 AM, Arlo Breault abrea...@wikimedia.org wrote: I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me). But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith. I’m more than willing to help out. Please get in touch. Arlo On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote: On Mar 11, 2015 2:23 AM, Gergo Tisza gti...@wikimedia.org (mailto: gti...@wikimedia.org) wrote: On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp cste...@wikimedia.org (mailto:cste...@wikimedia.org) wrote: I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, Special Account), so no special permissions are needed by the Special Account, and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to pull the plug if it looks like the edits are predominantly unproductive. I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set up at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly come from the IP address of the proxy so it would not be subject to Tor blocking. Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me. However, we could substitute the entire blinding process with a public page that the proxy posts to that says, this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion. And the proxy only allows tor editing by users with a passing vote. That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link them to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto: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] Tor proxy with blinded tokens
On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp cste...@wikimedia.org wrote: Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits. To make blocks more granular, some identifier such as the bitcount transaction ID could be exposed via XFF so administrators would still be able to assign blocks based on collaterals. That seems to me like a significantly easier setup than using the reputation of an existing user as collateral - that becomes really difficult if you want to both keep the association hidden and punish users who vouch for spammers. Maybe the proxy is not even necessary (it would certainly bring a host of usability issues) and all that's needed is a gateway to buy editblocked rights for users. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me. I don't think it's the most practical solution for this specific use case, but if it could be generalized, the ability to create a limited number of tokens per user which are anonymous but assert that the creator passed some condition (e.g. 1000 edits) and can be used up in some way would be exciting as it would allow proper voting systems. No idea if that can be fit into the OAuth framework, though (or if it's even possible without having two independent authorities both of which have only partial access to the data). ___ 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 2015-03-16 2:30 PM, Gergo Tisza wrote: On Wed, Mar 11, 2015 at 9:10 AM, Chris Steipp cste...@wikimedia.org wrote: Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. Well, the obvious collateral is always money; and with bitcoin going mainstream, untraceable money transfers are now accessible even to nontechnical users (although I don't know Not sure if the mere act of buying bitcoins could endanger someone in certain oppressive regimes). Something like $10 is probably not a serious hurdle to anyone intent on avoiding censorship but enough to deter spammers. The money could be donated to the Tor project, or retained and returned after a certain number of edits. 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. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor proxy with blinded tokens
I share Risker’s concerns here and limiting the anonymity set to the intersection of Tor users and established wiki contributors seems problematic. Also, the bootstrapping issue needs working out and relegating Tor users to second class citizens that need to edit through a proxy seems less than ideal (though the specifics of that are unclear to me). But, at a minimum, this seems like a useful exercise to run if only for the experimental results and to show good faith. I’m more than willing to help out. Please get in touch. Arlo On Wednesday, March 11, 2015 at 9:10 AM, Chris Steipp wrote: On Mar 11, 2015 2:23 AM, Gergo Tisza gti...@wikimedia.org (mailto:gti...@wikimedia.org) wrote: On Tue, Mar 10, 2015 at 5:40 PM, Chris Steipp cste...@wikimedia.org (mailto:cste...@wikimedia.org) wrote: I'm actually envisioning that the user would edit through the third party's proxy (via OAuth, linked to the new, Special Account), so no special permissions are needed by the Special Account, and a standard block on that username can prevent them from editing. Additionally, revoking the OAuth token of the proxy itself would stop all editing by this process, so there's a quick way to pull the plug if it looks like the edits are predominantly unproductive. I'm probably missing the point here but how is this better than a plain edit proxy, available as a Tor hidden service, which a 3rd party can set up at any time without the need to coordinate with us (apart from getting an OAuth key)? Since the user connects to them via Tor, they would not learn any private information; they could be authorized to edit via normal OAuth web flow (that is not blocked from a Tor IP); the edit would seemingly come from the IP address of the proxy so it would not be subject to Tor blocking. Setting up a proxy like this is definitely an option I've considered. As I did, I couldn't think of a good way to limit the types of accounts that used it, or come up with an acceptable collateral I could keep from the user, that would prevent enough spammers to keep it from being blocked while being open to people who needed it. The blinded token approach lets the proxy rely on a trusted assertion about the identity, by the people who it will impact if they get it wrong. That seemed like a good thing to me. However, we could substitute the entire blinding process with a public page that the proxy posts to that says, this user wants to use tor to edit, vote yes or no and we'll allow them based on your opinion. And the proxy only allows tor editing by users with a passing vote. That might be more palatable for enwiki's socking policy, with the risk that if the user's IP has ever been revealed before (even if they went through the effort of getting it deleted), there is still data to link them to their real identity. The blinding breaks that correlation. But maybe a more likely first step to actually getting tor edits? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto:Wikitech-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org (mailto: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
