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] changing edit summaries
Indeed - I am somewhat surprised by James's firm opposition. I tend to agree with James on this one in that if the edit summaries are to be modified then they need a revision history. Typos in edit summary are fixed by releasing an errata corrige in a subsequent dummy edit. I question whether or not the ability to change edit summaries is really a needed feature though. I would prefer the approach that Nemo recommend of making a dummy edit. For me it's less about vandalism et al. and more about the principle of revision tracking and audit trails. When you make an edit that revision is fixed and should not be able to be modified. This is one of the core principles that makes wikis work. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] changing edit summaries
Am I missing something? I just tried making a null edit and it didn't change the edit summary. It doesn't change the edit summary; it was suggested you make a null edit, but leave an edit summary for that null edit. This way you can make an edit that only serves the purpose of saying Hey the previous edit had a wrong edit summary, this is what I really did. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor relay
This is great news! Mozilla just began hosting middle relays a few days ago as well. Facebook just set up a hidden service to allow Tor users to access Facebook entirely within Tor. It's been a good week for the folks over at Tor. * Advertised Bandwidth 3.3 MB/s, what does it mean and can it be increased? As we do not set any advertised bandwidth in our configuration, the value in Atlas is the bandwidth observed by the network. We are still in a ramp-up phase and going to continue being so for until approximately the end of 2014. Read https://blog.torproject.org/blog/lifecycle-of-a-new-relay for more. We do not plan to set an bandwidth limit at this point, either in the Tor configuration or externally, in our network. I would highly recommend the lifecycle blog post that was linked to for anyone wanting to understand the statistics mentioned in Atlas. If anyone has any questions about any of the information listed in Atlas, you are welcome to shoot them my way as well. I'd be happy to answer them or find someone who can. * I see in puppet that there is at least some logging enabled. What is being logged and why? The best policy is to keep no logs. https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity#MinimizeDataRetention What logs are you referring to? If you're referring to Log notice /var/log/tor/tor.log then this just logs statistics, nothing else. torrc's manpage says on the matter: [w]e advise using notice in most cases, since anything more verbose may provide sensitive information to an attacker who obtains the logs. We do not keep traffic/usage logs in any way nor are we planning to. By default Tor doesn't keep any meaningful logs and the folks at the Tor project get very upset if you change that, for obvious reasons. Thank you, Derric Atzrott Sidenote: I've just a few days ago been laid off. My last day at this job will be on Friday, at which point I will be re-subscribing to this list using the email address zellf...@zellfaze.org. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences
TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and release it with MediaWiki 1.24? A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to customize the appearance of their site. In a recent security release[1], support for JS and CSS with on-wiki origins was removed from being displayed on the Special:Login and Special:Preferences page. To be clear, only CSS was removed. JS was already not allowed on Special:Login/Preferences. Because of how the on-wiki MediaWiki:Common.* pages are used and the access restrictions on them, I think it is reasonable to allow JS and CSS from them while continuing to disallow individual's JS and CSS on the Special:Preferences and Special:Login page. Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow site-wide styling back on those pages. Right, the patch only re-adds site-wide CSS, not JS. This seems completely reasonable to me. I'd merge is personally. Is there any reason not to? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops
Agreed! Congrats! Awesome Yuvi. Congratulations! :D On Nov 6, 2014, at 10:47 PM, Danese Cooper dan...@gmail.com wrote: Woot! Way to go, Yuvi! D On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma m...@wikimedia.org wrote: Hi all, I'm very pleased to announce that as of this week, Yuvi Panda is part of the Wikimedia Technical Operations team, to work on our Wikimedia Labs infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile team in December 2011, where he has been lead development for the original Wikipedia App and its rewrite, amongst many other projects. Besides his work in Mobile, Yuvi has been volunteering for Ops work in Wikimedia Labs for a long time now. One of the notable examples of his work is a seamlessly integrated Web proxy system that allows public web requests from the Internet to be proxied to Labs instances on private IPs without requiring public IP addresses for each instance. This very user friendly system, which he built on top of NGINX, LUA, redis, sqlite and the OpenStack API, sees a lot of usage and has dramatically reduced the need for Labs users to request (scarce) public IP address resources via a manual approval process. Another example of his work that has made a big difference is the initiation of the Labs-Vagrant project; bringing the virtues of the Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to bring a MediaWiki development environment up in Labs with great ease. More recently Yuvi has been working on our much needed infrastructure in Labs for monitoring metrics (Graphite) and service availability (Shinken). We expect this will give us a lot more insight into the internals and availability of software and services running in Wikimedia Labs and its many projects, and we should be able to deploy it in Production as well. Of course all of this work didn't go unnoticed, and about half a year ago we've asked Yuvi if he was interested to move to Ops. With his extensive development experience and his demonstrated ability to join this with solid Ops work to create stable and highly useful solutions, we think he's a great fit for this role. Yuvi recently had his VISA application accepted, and is planning to move to San Francisco in March 2015. Until then he will be working with us remotely from India. Please join me in congratulating Yuvi! -- Lead Operations Architect Director of Technical Operations Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Marielle Volz joins Wikimedia as Software Developer
and started developing a node.js service Citoid[5] to
make it easy to insert citations using a URL/DOI/Title in VE/Wikitext.
To put that into perspective: she's working on a feature in VE that
will let you paste in a URL to, say, a New York Times article, and
will then automatically generate and insert a {{cite news}} template
for you with all the right information (title of the article, author,
date, etc.). Some of you may have seen the demo that she and Erik did
at a metrics meeting earlier this year. This is really exciting,
because it's a big step forward towards the goal of making even
relatively complex tasks like inserting citations more convenient in
VE than in wikitext.
Not going to lie, that sounds really cool. Can't wait to see that
finished.
Welcome Marielle. I wish you the best of times in everything you do
here.
Thank you,
Derric Atzrott
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Although my suggestion is similar in kind to what had already been proposed, the main object to it was that it would create too much work for our already constrained resources. The addition of rate limiting is a technical solution that may or may not be feasible. The people on this list can best answer that. Does anyone know of any extensions that do something similar to the rate limiting that he described? Force edits into a queue to be reviewed (sort of like FlaggedRevs), but limit selected users to only a single edit? I can't imagine something like that would be hard to modify to pull from the list of Tor nodes to get its list of users. I'll take a look at the TorBlock extension and the FlaggedRevs extension code and see what I can see. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor exit node rejects port 443 of WM, but it is disabled for editing
Well you can also edit from port 80 (unless we deployed site-wide SSL without me knowing). Has a bug been filed for this? This sounds like an Extension:TorBlock issue (and is also probably my fault in some manner assuming this is a regression, which it may or may not be). Are Tor exit relays that block access to Wikimedia in their rejection policies usually allowed to edit Wikimedia projects? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Hello everyone, [snip] There must be a way that we can allow users to work from Tor. [snip more] I think the first step is to work harder to block devices, not IP addresses. [snip] Focusing on what signature we can obtain from (or plant on) the device and how to make that signature available to and manageable by admins is the key. These things are also likely to be considered security vulnrabilities, so probably not something to be relied on over long term as people fix the issues that allow people to be tracked this way. The folks over at the Tor project actually pride themselves on making a browser that is hard to fingerprint. If we came up with any way to fingerprint individual browser sessions, they'd likely fix it pretty quickly. Once we have a system that allows us to block individual devices reasonably effectively, it won't matter whether those people are using Tor to get to us or not If you can find a way to link a tor user to the device they are using, then you have essentially broken Tor. Which is not an easy feat. And of course, this is where the difficulty comes in. All of our current blocking measures are based around using information that is specifically hidden by Tor. The idea is to find a way to block individuals on Tor without having any information about those individuals that might be useful to someone trying to kill them (or at least identify their real world identity). Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
The problem with proof of work things is that they kind of have the wrong kind of scarcity for this problem. *someone legit wants to edit, takes them hours to be able to. (Which is not ideal) Indeed, this isn't ideal, but its better than the current situation, and at least it is only a one-time thing. *someone wants to abuse the system, spend a couple months before hand generating the work offline, use all at once for thousand strong sock puppet army. (Which makes the system ineffective at preventing abuse) I mean, I know we have some crazy socks, but spend a couple months seems to me to indicate a fairly expensive attack. I imagine that this might be enough of a deterrence. If someone is willing to invest months of effort to sockpuppet on Wikimedia projects, I don't really think that there is anything we can do to stop them. We could probably reduce this risk slightly as well by providing software that provides a GUI for generating the GPG keys for the user. This software could impose a high-rate limit on how often new keys are made. This could be easily worked around by anyone who knows how to make their own GPG keys, or has access to several computers, but it would stop a lot of would-be-sockpuppeteers. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wrapping signatures with a span for discoverability
From the standpoint of programmatically detecting a signature, the above could be cleaned up and work well enough. Would this mean that if people had a fancy sig, and they changed it, it would automatically update everywhere with this magic tag instead of just applying to new signatures? (Which might be cool) Downside to that you might have some tricky issue where people change their sig after the fact to be something malicious (For some definition of malicious), and then all the old sigs change without an edit to track it and generally be a vehicle for mass vandalism. (Didn't that use to be an issue on /. ?) I haven't looked at the actual patch yet, but based on the discussion it seems like this code would allow us to update pages if people's signatures changed? I too am not sure this is a good idea. I do though support the idea of wrapping signatures in a sig markup to make it easier to programatically detect them. That sig markup could be rendered as a span with a class=sig as well which allow those who are just scraping the HTML of the page to be able to detect them as well. This also makes working out what the state of the page at time X quite hard for things like Please note that I am being paid to edit by XYZ Inc. that come and go from month to month to be seen. This is one of my biggest concerns as well. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
If, as it seems right now, the problem is technical (weed out the bots and vandals) rather than ideological (as we allow anonymous contributions after all) we can find a way to allow people to edit any wikipedia via TOR while minimizing the amount of vandalism allowed. Of course, let's not kid ourselves - it will require some special measures probably, and editing via TOR would probably end up not being as easy as editing via a public-facing IP (we may e.g. restrict publishing via TOR to users that have logged in and have done 5 good edits reviewed by others, or we can use modern bot-detecting techniques in that case - those are just ideas). I would be curious to see what percentage of problematic edits are caught by running all prospective edits through AbuseFilter and ClueBotNG. I suspect those two tools would catch a large percentage of the vandalism edits. I understand that they catch most of such edits that regular IP users make. This would be a good start and would give us a little bit of data as to what other sorts of measures might need to be taken to make this sort of thing work. AbuseFilter has the ability to tag edits for further review so we could leverage that functionality to tag Tor edits during a trial. I could reach out to the maintainer of ClueBotNG and see what could be done to get it to interface with AbuseFilter such that any edits it sees as unconstructive are tagged, and if that isn't possible maybe just have it log such edits somewhere special. We've had this conversation a few times and I'd love to see creative approaches to a trial/pilot with data driving future decisions. If I approached Wikimedia-l with the idea of a limited trial with the above approach for maybe two weeks' time with all Tor edits being tagged, do you think they might bite? It clearly is the kind of problem where people do like to _look_ for clever technical fixes, which is why it's a recurring topic on this list. I suspect one exists somewhere. I'll reach out to the folks at the Tor project and see if they have any suggestions for ways to prevent abuse from a technical standpoint. Especially in regards to Sockpuppet abuse. I agree with Giuseppe that the measures that will need to be put in place will make editing via Tor more difficult than editing without Tor, but that's acceptable so long as they are not as prohibitively difficult as they are currently. Without having spoken to the Tor Project though, the Nymble approach seems like a reasonable way to go to me. The protocol could potentially be modified to accept some sort of proof of work rather than their public facing IP address as well. If we had a system where in order to be issued a certificate in Nymble you had to complete a proof-of-work that took perhaps several hours of computation and was issued for a week, that might be a sufficient barrier to stop most socks, though definitely some more data needs gathered. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
If, as it seems right now, the problem is technical (weed out the bots and vandals) rather than ideological (as we allow anonymous contributions after all) we can find a way to allow people to edit any wikipedia via TOR while minimizing the amount of vandalism allowed. Of course, let's not kid ourselves - it will require some special measures probably, and editing via TOR would probably end up not being as easy as editing via a public-facing IP (we may e.g. restrict publishing via TOR to users that have logged in and have done 5 good edits reviewed by others, or we can use modern bot-detecting techniques in that case - those are just ideas). I would be curious to see what percentage of problematic edits are caught by running all prospective edits through AbuseFilter and ClueBotNG. I suspect those two tools would catch a large percentage of the vandalism edits. I understand that they catch most of such edits that regular IP users make. This would be a good start and would give us a little bit of data as to what other sorts of measures might need to be taken to make this sort of thing work. AbuseFilter has the ability to tag edits for further review so we could leverage that functionality to tag Tor edits during a trial. I could reach out to the maintainer of ClueBotNG and see what could be done to get it to interface with AbuseFilter such that any edits it sees as unconstructive are tagged, and if that isn't possible maybe just have it log such edits somewhere special. We've had this conversation a few times and I'd love to see creative approaches to a trial/pilot with data driving future decisions. If I approached Wikimedia-l with the idea of a limited trial with the above approach for maybe two weeks' time with all Tor edits being tagged, do you think they might bite? It clearly is the kind of problem where people do like to _look_ for clever technical fixes, which is why it's a recurring topic on this list. I suspect one exists somewhere. I'll reach out to the folks at the Tor project and see if they have any suggestions for ways to prevent abuse from a technical standpoint. Especially in regards to Sockpuppet abuse. I agree with Giuseppe that the measures that will need to be put in place will make editing via Tor more difficult than editing without Tor, but that's acceptable so long as they are not as prohibitively difficult as they are currently. Without having spoken to the Tor Project though, the Nymble approach seems like a reasonable way to go to me. The protocol could potentially be modified to accept some sort of proof of work rather than their public facing IP address as well. If we had a system where in order to be issued a certificate in Nymble you had to complete a proof-of-work that took perhaps several hours of computation and was issued for a week, that might be a sufficient barrier to stop most socks, though definitely some more data needs gathered. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Prior to TOR being enabled we need to be able to flag both logged in and logged out edits made via TOR. This is something that can be handled easily by AbuseFilter. It has the option to flag edits made by certain users or from certain IP addresses if I remember correctly. Even if it doesn't this should be fairly trivial to put together I would imagine (though correct me if I am wrong). Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Another idea for a potential technical solution, this one provided by the user Mirimir on the Tor mailing list. I thought this was actually a pretty good idea. Wikimedia could authenticate users with GnuPG keys. As part of the process of creating a new account, Wikimedia could randomly specify the key ID (or even a longer piece of the fingerprint) of the key that the user needs to generate. Generating the key would require arbitrarily great effort, but would impose negligible cost on Wikimedia or users during subsequent use. Although there's nothing special about such GnuPG keys as proof of work, they're more generally useful. As a proof of work I think it works out pretty well. The cost of creating a key with a given fingerprint is non-trivial, but low enough that someone wishing to create an account to edit might well go through with it if they knew it would only be a one-time thing. This doesn't completely eliminate the issue of socks, but honestly if we make the key generation time reasonably long, it would probably deter most socks as they might as well just drive to the nearest Starbucks. Someone else on the Tor mailing list suggested that we basically relax IPBE, which while not on topic for this list, I thought I'd mention just because it has been mentioned. They actually basically described our current system, except with the getting the IPBE stage a lot easier. The following was also pointed out to me: [I]t's also trivial to evade using proxies, with or without Tor. Blocking Tor (or even all known proxies) only stops the clueless. Anyone serious about evading a block could just use a private proxy on AWS (via Tor). [snip] The bottom line is that blocking Tor harms numerous innocent users, and by no means excludes seriously malicious users. I did respond to this to explain our concerns, which is what netted the GPG idea. Does anyone see any glaringly obvious problems with requiring an easily blockable and difficult to create proof of work to edit via Tor? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Hello everyone, I've been a Tor user for many years and I frequently make use of anonymising proxies services. Recently (yesterday), I set up my first Tor relay.[1] This has once again gotten the use of Tor and other anonymising services with Wikipedia on my mind again. In a recent article on the Tor blog,[2] Wikipedia is actually called out a number of times for being unfriendly to Tor, and I think they make a good point. [H]ow can we quantify the loss to Wikipedia, and to society at large, from turning away anonymous contributors? Wikipedians say 'we have to blacklist all these IP addresses because of trolls' and 'Wikipedia is rotting because nobody wants to edit it anymore' in the same breath, and we believe these points are related. There must be a way that we can allow users to work from Tor. My understanding of why we block Tor categorically is that it is very hard to block individual Tor users. Perhaps we could allow Tor users to only edit pages if they make an account? That would allow us to at least block those accounts, which increases the cost of being problematic on Wikipedia a bit. Or to take from the blog post, perhaps Tor users could be issued a certificate that they could use to prove their identity from one session to another. New Tor users would need to prove they are the same person as someone we already trust or their edits would be put in some sort of review queue. Or combine the two and new accounts made from Tor connections would need to have their edits reviewed, or perhaps just wouldn't get autopatrolled status as quickly (if ever). There has got to be a better solution to the problem than just blocking all Tor users completely. Thank you, Derric Atzrott [1]: https://atlas.torproject.org/#details/6413D947D15B81B423D65D76DA3F2BFEF76BEEF2 [2]: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept-anon ymous-users ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Hey, Overall you are suggesting that WMF changes the policy about anonymity and accept anonymous users. In my view it's not a technical thing and it should be brought up in wikimedia-l. I agree, it's a matter of consensus which is definitely beyond any technical discussion. Fair, I had thought that the decision to make the block had primarily been made by us in the technical community as I imagine the average editor knows little to nothing about Tor or other anonymising services. I'll bring up the topic in another venue. Some previous discussions on wikitech-l: Thank you for that list Sumana. I'll give it a look over and might continue to use this thread for anything that comes up from that that does seem appropriate for this list. Based on the number of times this has come up, it does at least appear there is at least some merit to discussing it, or aspects of it, on this list. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Alright, this is a long email, and it acts to basically summarise all of the discussions that have already happened on this topic. I'll be posting a copy of it to Mediawiki.org as well so that it will be easier to find out about what has already been proposed in the future. There is a policy side to this, Meta has the No open proxies policy, which would need to be changed, but I doubt that such policies will be changed unless those of us on this list can come up with a good way to allow Tor users to edit. If we can come up with a way that solves most of the problems the community has, then I think there is a good chance that this policy can be changed. Table Of Contents 1. Relavent Quotes 2. Ideas 2.1. Nymble 2.2. Blind Signing 2.3. FlaggedRevs 2.4. Tor Exemption Userright 2.5. Policy Changes 2.6. OAuth 2.7. Donate for Access 2.8. Account creation off Tor 2.9. Fingerprinting 2.10. Tor Hidden Service 3. A Note on Current Policy 4. References Relavent Quotes Not every Tor user is vandal or troll, and assuming that all of them are by default is not assuming good faith. Some people are just really paranoid about their internet anonymity or live in restrictive countries (both of which I sympathize with), so this idea would let them edit in good faith while filtering out vandal/troll edits. -- Arcane 21 Well the issue is not whether we want Tor users editing or not. We do. The issue is finding a software solution that makes it possible. -- Tyler Romeo (Though Risker disagrees with the quote above, I get the feeling Tyler encapsulates the overall consensus, based on the discussions I've read.) Many people believe that Wikipedia has become so socially important that being able to edit it even if just to leave talk page comments is an essential part of participating in worldwide society. Unfortunately, not all people are equally free and some can only access Wikipedia via anti-censorship technology or can only speak without fear of retaliation via anonymity technology. -- Gregory Maxwell 'Preventing' abuse is the wrong goal. There is plenty of abuse even with all the privacy smashing new editor deterring convolutions that we can think up. Abuse is part of the cost of doing business of operating a publicly editable Wiki ... The goal needs to merely be to limit the abuse enough so as not to upset the abuse vs benefit equation. Today, people abuse, they get blocked, they go to another library/coffee shop/find another proxy/wash rinse repeat. We can't do any better than that model, and it turns out that it's okay -- Gregory Maxwell My personal view is that we should transition away from tools relying on IP disclosure, given the global state of Internet surveillance and censorship which makes tools like Tor necessary. -- Erik Moller The vast majority of socks are blocked without checkuser evidence, and always have been, on all projects; the evidence is often in the edits, and doesn't need any privacy-invading tools to confirm. -- Risker Ideas: ==Nymble== http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php Users get a psuedonym from a Psuedonym Manager which maps a psuedonym to an IP address for a defined duration (linkability window, default 24 hours). This must be done from a unanonymised connection. All steps after this can be done anonymised. The user passes that psuedonym to a Nymble Manager to get a Nymble ticket which is good for a defined duration (time period, default 5 minutes). This ticket is passed to the service anytime an action is performed. If a Nymble user acts up, the service can contact the Nymble Manager and get a Linkability Token which allows the service to link all Nymble tickets that a psuedonym used and uses during a single linkability window. The Psuedonym Manager, the Nymble Manager, and the Service would have to cooperate to deanonymise a users actions. Assuming that they do not, and that all three maintain minimal logs, this should protect the users privacy while still allowing them to perform actions and be blocked for misbehaving. It additionally appears that with its default settings, the Nymble Manager rate limits the user to a single action per time period. This means that they should in theory only be able to make a single Wikipedia edit every five minutes, which while not great, is a definite improvement. There is a negative in that misbehaving users could only be blocked for a single linkability window (so one day) using this scheme. Still blocking was never meant to be punitive, so perhaps that might be acceptable. I don't know, and it really isn't a discussion for this
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
On the other hand there are no evidences blocking TOR significantly reduced the number of editors. Btw anyone with a good reason to use TOR has been granted with global exemption. This is demonstrably not true. I for one have a good reason to use Tor and have not been granted an IPBE. Contact me off-list for more information, I'd be happy to talk about it in a less public venue. The lack of an IPBE is one of the primary reasons I don't use Tor or my anonymous proxy all the time when using the web at home. I hate to say it but I am often times willing to give up the privacy I get when browsing the rest of the web just to not have to disconnect from Tor or my VPN in order to fix a typo on Wikipedia. Actually makes me feel like quite the hypocrite at times as that very behaviour is something I'm always nagging folks about... Additionally in the environment we currently live in, with the NSA doing their thing, I feel we shouldn't be punishing those who care about their privacy. You don't need to have anything to hide to want to protect yourself. Thank you, Derric Atzrott (Also, and not to nitpick, Tor not TOR, please see https://www.torproject.org/docs/faq#WhyCalledTor) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Speaking frainkly I find (on a daily basis) too many abused VPNs to think TOR won't bring tons of abuses. Some months ago (I cannot remember when) TORblock stopped working. Having a look at what did happen at time would be an interesting path. In my perception it did bring to an increase in abuse (spam/trolling/vandalism). Might you have been talking about Bug #30716? [1] It happened in September of 2011. In May of 2012 the bug was re-opened and it hasn't yet been closed. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)
Okay, so I have to ask. What is this obsession with enabling TOR editing? It's the most well-known of the anonymizers and probably has the most traffic. I'd encourage all of you to focus on technical ways to prevent abusive/inappropriate editing from all types of anonymizing edit platforms, including VPNs, sites like Anonymouse, etc. TOR is but one editing vector that is similarly problematic, and it would boggle the minds of most users to discover that developers are more interested in enabling another of these vectors rather than thinking about how to prevent problems from the ones that are currently not systemically shut down. I'd completely agree with this. Most of the suggestions that were outlined in my summary email would work for more than just Tor. There is a great quote from Erik that I included in there as well that points towards this. We need to transition away from a framework where IP addresses are our only means to block problematic editors and towards a framework where we can do so via other less intrusive means. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'm leaving the Wikimedia Foundation
You will be serverly missed. You've always been one of my favourite people at the Foundation. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is simplicity is the key to success of Echo and Watchlist?
- *it* *doesn't* *scale* (constantly seeing a (3) or new emails pop up if you're active in ~6 discussions is a pain) OK, so how do you suggest changing it? - _nothing_ on-wiki ever warrants an urgent reaction ever All the community members who clamored for the return of the Orange Bar of Death seem to disagree with you. You use the past tense. I *still* clamor for the Orange Bar of Death. Agreed! I participate in a fair number of discussions pretty regularly, and being notified of mentions and pings is probably my favourite thing about echo. Perhaps I am just a WP:Wikipediholic, but there are definitely things that happen on-wiki that warrant urgent reactions. Just last night I accidentally screwed up someone's talk page and I'm very happy for the notification that I was left a message (What the hell were you doing in this edit?!?) so that I could revert my edit quickly and apologise. To me, the answer is obvious: pull messaging out of echo, and summarize notifications on echo for the remaining notifications (i.e. if a notification for a given page is already sitting unread, don't bump the number, and replace the message with x AND y have happened on z. For messages, give us back the OBOD. This is actually a good idea. You could have the individual items listed on Special:Notifications and just have the summarized items under the list in echo. - Echo is a consequence of a watchlist page which many people find insufficiently informative, intuitive, or easy to control. Yes, the watchlist page needs a total overhaul. Notifications aren't necessarily about articles though. We considered having Echo integrated into the watchlist, but this would have make the project much more complex and politically contentious. As you say below, simplicity is the key to success. Don't get that. You can't change things too much without it becoming politically contentious. One needn't look any further than the Mediaviewer controversy to see that. I'm sure there are other reasons as well that I am unaware of. I want Flow notifications if someone replies to me, or mentions me in a talk post. Or even for everything if that Flow board would happen to be my own talk page for instance. BUT, that is separate from watching a page. Normally, when watching a page, I would not want notifications on every page that I visit, for every reply to every post, new post or retitled post. I want to see what the last major changes were. Mostly, new topics, and the last change to a new topic. Currently, I feel like Echo is forcing me to consume Flow discussion, where rather, I only want to be 'subscribed' to them and then consume the subscription at the moment that I feel comfortable doing that. It is like it is mixing my mailbox with my newspaper... I haven't played around with Flow yet, but if that is how Flow integrates into Echo, I can definitely see that being a huge complaint from a ton of people. I'd find that somewhat annoying too. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template RFC
Just in case it helps, I have created a task for this RfC at http://fab.wmflabs.org/T572. Please identify current blockers there (or here) in order to focus the contributions in the tasks that matter. Shouldn't this be on Bugzilla instead of Phabricator? This bug has nothing to do with Phabricator and I thought we were currently only using Phabricator for bugs related to Phabricator. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Template RFC
The architecture committee and the engineering community team agreed to use Phabricator in this fine-tuned RfC process. See https://lists.wikimedia.org/pipermail/wikitech-l/2014-August/078025.html for the related announcement. I remember that now. Thank you. I was a bit concerned because I could see people looking for it in Bugzilla and not finding it there. We need to agree on Requests for comment/HTML templating library is not a bug strictly speaking. Nor is a lot of what is in Bugzilla. Hopefully in a month we will not need to discuss about Bugzilla vs Phabricator because we will all be using the latter. Indeed! Very much looking forward to that! Phabricator looks like a great piece of software. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] planned move to phabricator
Because we decided to work on the Phabricator project in Phabricator, to learn in depth how it works and how could we work best with it. Eating your own dogfood and all that. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings
When someone creates a product specifically for a certain group of users (in this case folks installing extensions) without actually knowing what is useful to them (never even mind 'important' at this stage), there is something seriously wrong with that process. Though I might only be a single voice, I just want to say that as someone who installs extensions, I support this project. While its generally pretty easy to tell that an extension is abandoned, it isn't always easy to tell if it is any good. I would consider a rating system for extensions a perfectly viable GSoC project that has both useful and important implications. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings
Has it already been asked anywhere *whether* to make these ratings available on mediawiki.org? How useful is it really to know that Extension:ConfirmEdit scored 3 on some external website, especially without knowing that that 3 comes from a grand total of 1 person? Relevant: http://xkcd.com/1098/ -Chad Also: http://xkcd.com/937/ -- Legoktm Is it really necessary for people to openly mock the work of a volunteer developer on the list? No wonder we have so few volunteer developers. I do think that they are legitimate complaints, though I also agree that there might have been a better way to point them out. While doing a bit of research for something else I came across a rating display that might help solve some of these problems at least. http://easycaptures.com/fs/uploaded/831/6188233746.png Source: Spiceworks (product page) (when hovering over a number of stars it says how many people gave it that rating) I think that this sort of display solves at least the problem shown in XKCD 1098 along with the complaint of not knowing how many people actually scored something someway and whether or not it's a significant percentage. The visual display of the information can solve the issue in 1098 if we tweak the colours a bit to show some of the lower ratings as more greenish. The use of a rotating display of top rated comments allows problems like those highlighted in XKCD 937 to be solved. Hopefully we can find some way to allow the more helpful ratings to be shown to users. Amazon does a pretty good job with this as well. Does Wikiapiary collect data on how many wikis make use of any given extension? Exposing that data may also help someone make an informed decision about whether or not to use an extension. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Superprotect user right, Comming to a wiki near you
Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. Sorry, I strongly disagree that the current system works. Every so often we discover that a wiki has been loading external resources in site-wide JS for months. Local sysops might have no idea on what they're doing, and just copy and paste what someone told them to do. Edits like [1] make that terribly obvious. I filed bug 69445[2] as a tracking bug to implement a sane code review process for these pages. I don't imagine it will happen anytime soon, but now seems like a good time to start discussion about it. I'm fine with having some sort of code review system, so long as it is implemented in such a way that there are volunteers with +2 for it. I'm not sure implementing this user right though was the best way to go about beginning that implementation, at least with the sort of charged atmosphere that currently exists within the Wikimedia editor communities. Perhaps the change could be reverted and we could spend some time on this list discussing how such a code review system would work? Give some time for the editors to calm down and all of us to calm down. (A quick look at Meta shows a lot of hate.) I think if this is implemented slowly with lots of notice it might have a better chance of succeeding. I think Erik's commit is likely poisoned at this point and any work that stems from it is unlikely to be accepted by the wider community. I like the discussion that is going on in #69445, thank you for filing that Legoktm. If nothing else, this whole debacle brought this issue back to the center of discussion, somewhere where it needs to be. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Mediawiki-enterprise] MediaWiki for the third party community: get involved!
This reply is as I understand the situation to be. If anyone else can provide a bit more insight into things, or correct me where I am wrong, I would be grateful. Hi, What would be the purpose of this organisation and separate community, exactly? Has there been any demonstrated need or even want for such an organisation amongst the community it would proportedly serve? This is something that has been in the works on Wikitech-l for some time now. The folks on Wikitech-l and the WMF have come to the decision that they can't really dedicate the resources required to handle third parties properly (someone correct me if I am wrong on this). They are going to be working with the folks over at Debian, among other places, to get the vary Linux distributions packages up-to-date and keep them up-to-date. They are also going to be giving the installer a little bit more love than it currently has, and working on additional database support. The WMF is paying them for their work. Its a contracted deal to offload some of the development and release tasks that primarily benefit third-party users to someone who can actually dedicate the time and effort to listen to third- party users. Given the luck that enteprise has had in the past at getting some features added to Mediawiki (without coding them ourselves that is), I believe that a need has definitely been demonstrated. As an enteprise user myself, I personally want this and like the idea, so while I can't speak for everyone, at least one person in the community wants it. I ask in particular because as a third-party sysadmin myself, it's hard enough following all the relevant discussion and information that concerns releases as it is already. I think the idea is that they will be consolodating these as much as possible. Though, I will say that I think they should keep using this list as the primary list for enteprise instead of having their own mailing list as well. Unless the enterprise list is to be deprecated. It would be nice to just be able to subscribe to two lists as a third-party user, mediawiki-enteprise-l and announcements-l. Adding another organisation on top of that, with its own lists and websites to check and follow, and another layer of community to go through to get things upstreamed, seems highly premature when we can't even consolidate the basics (release notes, date announcements, even testing) at home. I suspect that they will be more able to help third-party users get things upstreamed. Or at least that is my hope. They should also be handling release notes and date announcements entirely now for third-party users (assuming I've understood correctly). I think that this will lead to more consistent and easier to understand release notes and announcements. I can't really say anything about testing. I'm not terribly familiar with any of our testing infrastructure to be honest. Considering we also have no guarantee that any new organisation would be more receptive to the needs and concerns of the third-party end users than the WMF is currently, and there would still be things we would need to go to the WMF directly about anyway (thus making it even harder to figure out where to go for something), I find this all very worrying. They are being paid to be more receptive, so I hope that they will be. I should hope that they will also be able to act as a liason between third-party users and the Mediawiki development community. Personally, I don't find it worrying, I actually find it quite refreshing. Its about time third-party users were treated as first-party citizens! :D Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Policy on browser support
I would like to make a case for moving more browsers into the grade C category. Yes please. As a project that must live the test of time I think we should be focusing our energy on building for future browsers. Our main goal is to provide people knowledge which can be done without JavaScript. Older browsers hold us back in my opinion. I would also support this, for similar, but slightly different reasons. I agree that we need to make sure that the project stands the test of time, and for that reason I think we need to make Grade C a first class citizen. I think because of the relative ease of parsing and saving a javascriptless page, it stands the best chance of being accessible long into the future. This would, of course, also allow us, as others have pointed out, to reduce our maintenance burden and focus on building the best experience that new browsers can provide. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Include an updater
Hi could we develop an in wiki upgrades meaning we could ether put the upgraded in the special version page or create its own special page and then add a notification to the special version page that tell them about upgrades for extensions and Mediawiki. It will help people migrate and know when updates are avalible instead of keep checking so for example a stable version would check for ref1_xx and the alpha one would look for the master branch. I would support this. Its not too uncommon for me to send an email to a wiki administrator to let them know that their installation of Mediawiki is both out of date and vulnerable. Just a few days ago I let the Free Software Foundation know that they were running Mediawiki 1.16, which is vulnerable and hasn't been supported for some time. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] tool for quickly uploading 10000 images with description
glamwikitoolset might be an option as well. http://m.mediawiki.org/wiki/Extension:GWToolset/Technical_Design Yeah, I was just about to mention that. The GLAM Community seems reasonably satisfied with it and as far as I know it supports adding a lot more metadata to images than the image importer does. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] HTML Forms class, multiple forms
I have a special page on which I am using HTMLForm. Previously in developing Mediawiki extensions I had just outputted raw HTML and done everything myself, trying to move away from that I've started using HTMLForm. I'm running into a problem with how to handle multiple HTMLForm forms on a single page. I have a separate callback set for each of them, but anytime one form is submitted, the callbacks for all of the forms are executed. Am I doing something wrong with my usage of this class? Is there a way to only have the callback for the submitted form be called? Or will I have to come up with a way to determine which form on the page was filled out? Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] English Wikipedia Homepage Framework
Hello, I just wanted to make everyone aware of a discussion going on at the English Wikipedia. They are discussing changing the Main Page, not visibly, but just changing the page from a table based layout to one that is a little bit more modern. The discussion can be found here: https://en.wikipedia.org/wiki/Talk:Main_Page#Proposal_to_implement_new_framework _for_main_page One of the things that came up during the discussion was testing the framework with a wide variety of browsers. A lot of the opposition to it that I could see came from the lack of testing. I feel like I remember us discussing here previously a framework for testing stuff across many browsers. If we have something of the like here, I think that it could be well deployed to help them out. No reason for them to re-invent the wheel or do all of the testing manually. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] SSL Cert Change?
Hey, I just had Certificate Patrol in Firefox let me know that the SSL cert for Wikimedia.org was changed? Does anyone know anything about that? Are multiple certificates in use? Old cert: - Builtin Object Token:Equifax Secure CA - *.wikimedia.org SHA1: BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E Issued: 2010-08-03 11:43:56 (1346 days ago) Expires: 2015-08-22 18:23:10 (499 days ahead) New cert: - GeoTrust Global CA - RapidSSL CA - *.wikimedia.org SHA1: A4:5B:84:1B:A8:00:DC:1B:2E:11:71:E6:31:C6:5D:0E:AF:50:10:95 Issued: 2014-04-06 18:31:08 (4 days ago) Expires: 2015-08-24 19:09:19 (501 days ahead) I rejected the certificate for the moment, but saved a copy of both if anyone wants to take a look. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SSL Cert Change?
I just had Certificate Patrol in Firefox let me know that the SSL cert for Wikimedia.org was changed? Does anyone know anything about that? Are multiple certificates in use? FYI, this has been widely covered in a lot of mainstream press. (but not necessarily well. Some call OpenSSL a protocol) http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075801.html https://xkcd.com/1353/ Ah. I'm still reading emails from Monday on the list. So I must have just missed out on the SSL cert change. I did hear about the Heartbleed issue (actually had a few users here at the office come to me very concerned about what they heard on the news). Glad to hear that the certs were reissued to take care of that. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] .wiki gTLD
For the record media.wiki is registered by Top design LLC or reserved. You have to sue them to get the name or just ignore them. My understanding from before was that the WMF was in talks with them about our trademarks. Erik had earlier stated: We've been in discussions with Top Level Design, both to look into potentially appropriate uses (e.g. URL shorteners) and to prevent squatting of WMF trademarks. I imagine that this is just that in action. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] .wiki gTLD
ICANN just delegated the gTLD .WIKI yesterday. It's being managed by Top Level Design, LLC. I'm not entirely sure what that means for all of us exactly, but I suspect that the WMF is going to want to at least register Wikipedia.wiki and Wikimedia.wiki once the gTLD is open for registration. Some of the new gTLDs are already opening up for registration. .sexy and .tattoo will be opening for registration on 25 February. It looks like if we want to get .wiki domains we will be getting them sometime in May or June during the sunrise period.[1] ICANN also has a full list of new gTLDs that they have approved.[2] Thank you, Derric Atzrott Computer Specialist Alizee Pathology [1]: http://www.namejet.com/Pages/newtlds/tld/WIKI [2]: http://newgtlds.icann.org/en/program-status/delegated-strings ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Non-Violent Communication
Question for Derric: why didn't you formulate your suggestion using NVC? I was excited and in a hurry. In retrospect I really think that I should have. After reading some of the replies I felt rather disappointed and frustrated, and even a little sad as I didn't feel my need for understanding was met. In the future I will try to take a little more time writing emails to the list. I'm sorry to anyone who felt offended by it or felt that my email was, well, violent. That was not my intention at all. I just began myself looking into and trying to practice NVC in the past six months or so, and I am, as of now, still not terribly great at it. Again, I want to express my apologies, and I really hope that I didn't turn anyone off to the subject. I guess all I was really trying to say in that email is that when conversation on this list gets heated, I feel frustrated because my needs for calm and community are not met. I end up not wanting to participate because I don’t think that I will be heard or understood. I would like to request that people onlist look into strategies to help everyone get along, whether that is AGF, or NVC, or something else, does not matter as much to me. I suggested NVC because it has been a very useful tool for me in the past. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visual Editor and Parsoid New Pages in Wikitext?
In the longer term we are working on the ability to store HTML instead for new wikis, in which case it might become possible to run without Parsoid if you don't need a wikitext editor front-end. This is not going to happen over night and will just be an option, so no reason to worry. So right now, assuming I don't have Parsoid, Visual Editor creates pages in Wikitext, it just can't edit previously existing pages? I would assume that this also means that without Parsoid if I edit a page in the regular Wikitext editor, I won't be able to use Visual Editor with it anymore. VisualEditor is an HTML editor and doesn't know about wikitext. All conversions between wikitext and HTML are done by Parsoid. You need Parsoid if you want to use VisualEditor on current wikis. This is what I had originally thought, but then somehow along the way I managed to get confused. Thank you for clarifying. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Non-Violent Communication
Hoy all, I've been meaning to start a thread about this for a while, but just hadn't gotten around to it. Things have been rather heated the past few days, so I figured now would be as good a time as any to go about starting this thread. Have any of you ever heard of Non-Violent Communication (NVC). It's a method of communicating, well really more a method of thinking, that aims to reduce and resolve conflicts between people. NVC has sometimes also been called Empathetic Communication or Needs Based Communication. The idea of NVC is to frame the discussion in terms of needs and feelings, followed up by requests. Nonviolent Communication holds that most conflicts between individuals or groups arise from miscommunication about their human needs, due to coercive or manipulative language that aims to induce fear, guilt, shame, etc. These 'violent' modes of communication, when used during a conflict, divert the attention of the participants away from clarifying their needs, their feelings, their perceptions, and their requests, thus perpetuating the conflict. [0] The core of NVC is an NVC expression, which is made up of four components: Observations (When I see/hear/notice...), Feelings (...I feel...), Needs (...because I need/value...), and Requests (Would you be willing to...?). Observations are the facts themselves, and are not broad generalizations. Feelings are emotions, they are distinct from stories, thoughts, and evaluations. Feelings are also self-owned and not attributed to others (so one doesn't feel attacked, one feels angry, likewise one doesn't feel betrayed, one feels hurt or stunned, or perhaps even outraged). Finally requests are simply that requests, but they are not demands. You have to be willing to hear the other person say no. To take a recent example from the mailing list: Cool, I'll just pop in. Oh, wait. (David, I want you to know I am not picking a quote from you specifically for any reason, it was just one that stood out to me as something that could have been much better expressed within the NVC framework) This could have been expressed as: When people talk about things off-list, I feel resentful and frustrated because my needs for community, consideration, and to be heard are not being met. Would you be willing to keep the discussion on-list so that I can participate? NVC values honestly expressing your own needs and feeling and empathetically listening to those of others. Two things that really harm this connection are blaming others and blaming ourselves. I really encourage everyone on this list to do a little bit of reading into NVC. I've linked to the Wikipedia article at the bottom of this email along with the website for the Center for Non-Violent Communication. The NVC way of thinking has really made a huge difference in how I understand and express myself to people. I'm by no means perfect at it myself, but even with the practice that I have I've already seen a huge improvement in how I relate to others. I really think that it could do a lot of good here. Thank you, Derric Atzrott Computer Specialist Alizee Pathology [0] https://en.wikipedia.org/wiki/Nonviolent_Communication NVC on Wikipedia [1] http://www.cnvc.org/ Center for Non-Violent Communication [2] https://www.cnvc.org/Training/feelings-inventory Feelings Inventory (really useful for those of us who aren't in touch with our feelings, like myself) [3] http://www.cnvc.org/Training/needs-inventory Needs Inventory (also very useful for those of us who aren't in touch with our needs, again, like myself) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Non-Violent Communication
NVC values honestly expressing your own needs and feeling and empathetically listening to those of others. You know, I'm generally considered to be reasonably skilled at communications; and I think that I have had some success in remaining cordial and attentive to both my colleagues and the members of the community I often interact with. To be honest, if someone were to address me in the way you describe in your examples, I would almost certainly be seriously offended. You call this Non-Violent Communication, but I find it both condescending and dismissive, and would certainly perceive it as a deliberate attempt at being passive-aggressive. TL;DR: YVVM. Not all methods of communication are appropriate for all media, or of all audiences. I'm sorry if I offended you. That was not my intent. I was only trying to help us all communicate and get along better. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Visual Editor and Parsoid New Pages in Wikitext?
If I install the Visual Editor mediawiki extension on the Wiki that I manage here at my work and also setup Parsoid, will new pages be saved with Wikitext still? The documentation for the extension's installation mentions that after you install Visual Editor you won't be able to edit Wikitext pages, but you will be able to create new pages. It also mentions that with Parsoid you will be able to edit Wikitext pages again. This leaves unclear whether or not having Parsoid installed makes Visual Editor save new pages as Wikitext as well, or just previously existing pages. I'm thinking about letting folks try Visual Editor here, but I need to be able to work with Wikitext still as there are definitely some unusual things I do in Wikitext from time to time. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visual Editor and Parsoid New Pages in Wikitext?
If I install the Visual Editor mediawiki extension on the Wiki that I manage here at my work and also setup Parsoid, will new pages be saved with Wikitext still? Yes. All content is currently stored as wikitext, so you are naturally able to use the wikitext editor to create pages or edit existing pages. In the longer term we are working on the ability to store HTML instead for new wikis, in which case it might become possible to run without Parsoid if you don't need a wikitext editor front-end. This is not going to happen over night and will just be an option, so no reason to worry. So right now, assuming I don't have Parsoid, Visual Editor creates pages in Wikitext, it just can't edit previously existing pages? I would assume that this also means that without Parsoid if I edit a page in the regular Wikitext editor, I won't be able to use Visual Editor with it anymore. The documentation for the extension's installation mentions Do you have a link to this documentation? I was reading this page: https://www.mediawiki.org/wiki/Extension:VisualEditor Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] February '14 appreciation thread
Hi! In a shameless copy of Sumana's August 2012 idea, I'd like to send public thanks to some people who have helped me get some things done in the past few weeks/days: * Guillaume Paumier, for his overall amazingness and his help in creating and distributing the weekly Tech News bulletin; * Daniel Zahn (mutante) and Sam Reed (Reedy) for their help in getting my Gerrit patches reviewed merged (long overdue!); * Ariel Glenn (apergos) for triaging my latest RT ticket and for being so nice and understanding on a Sunday evening ;-) So, if you'd like to thank someone, now is a good time and opportunity to do so! Following Sumana's example, the rules are: be kind, thank someone, and say why you're thanking them. Thank you Sumana for getting me to come back to the list. I'll start a thread here once I get time! Also thank you Sumana for starting that thread about seeing what we could do about Tor. As a user of Tor who is sometimes frustrated by not being able to edit while using Tor, I really appreciate that! Thank you Jeremy Baron, Tyler Romeo, Chad, Andre Klapper, Risker, and Nathan Larson for all your help with helping me debug things and pointing me in the right direction when I have problems to report. Thank you to everyone who I missed who have helped me out on this list! Finally thank you to everyone on the Visual Editor team. You got a lot of crap a while back from everyone, including myself, but you really are working on an awesome product, and I'm glad to see it happening. Thank you, Derric Atzrott (Hmmm this signature looks like I'm thanking myself given the rest of the mail. I'm not, just to be clear) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Toolserver Error 502
Any idea what is going on with Toolserver? I've noticed several times over the past few days that it's been very slow to run tools, or just non-functional at all, giving a 502 error. With the Steward elections going on, I suspect a lot of people will be trying to make use of the tool at [0] to check their eligibility to vote. Is there a bug in bugzilla that I might be able to watch? Or is this a new issue? Thank you, Derric Atzrott [1] https://toolserver.org/~pathoschild/accounteligibility/?event=31 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option. You mean kind of like this? https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication Pretty close. I was actually thinking well known PGP keypair, but SSL cert signed by a trusted CA works just as well. I'll fool around with that extension later today. Thank you! Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] English Wikipedia Issues
Hey all, Not sure if anyone else noticed or not yet, but at least the English Wikipedia appears to be having some intermittent issues. Request: GET http://en.wikipedia.org/wiki/Super_Bowl_XXVII, from 10.64.32.105 via cp1052 cp1052 ([10.64.32.104]:3128), Varnish XID 4288339681 Forwarded for: 162.17.205.153, 208.80.154.76, 10.64.32.105 Error: 503, Service Unavailable at Thu, 06 Feb 2014 16:40:23 GMT (Missed the Super Bowl and attempting to figure out what all the big talk about it is about, apparently it was a slaughter?) Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
Well if we are going to go down that road, requring public/private key pairs would also be more secure. However i doubt either would be acceptable to users. Actually, I think it might be better if we just have people come on down to the San Francisco office and show their government ID. Then we have Tim or Brion log them in personally. ;) Actually to be honest, if I could login to Mediawiki with a public/private keypair I would actually really enjoy that. Certainly it shouldn't be the default, but in a very non-joking way, I would support an initiative to add that as an option. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Let's improve our password policy
For example, MZMcBride, what if your password is wiki, and somebody compromises your account, and changes your password and email. You don't have a committed identity, so your account is now unrecoverable. You now have to sign up for Wikipedia again, using the username MZMcBride2. Of course, all your previous edits are still accredited to your previous account, and there's no way we can confirm you are the real MZMcBride, but at least you can continue to edit Wikipedia... Obviously you are not the best example, since I'm sure you have ways of confirming your identity to the Wikimedia Foundation, but not everybody is like that. You could argue that if you consider your Wikipedia account to have that much value, you'd put in the effort to make sure it is secure. To that I say see the above paragraph. What if all of the email addresses that a user has ever used were to be stored permanently? Then in the event of an account hijacking, he could say to WMF, As your data will confirm, the original email address for user Foo was f...@example.com, and I am emailing you from that account, so either my email account got compromised, or I am the person who first set an email address for user Foo. The email services have their own procedures for sorting out situations in which people claim their email accounts were hijacked. I feel as though this idea does not meet my need for privacy. I can guess that at least a portion of the community would agree. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Issue
We were dealing with cascading site issues due to excessive database queries, and are still investigating the root cause, but site should be recovered by now. I couldn't find an post-mortem on the Wikitech. Did one end up getting made, or is that perhaps still a work in progress? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikipedia Issue
Just got this when trying to read an article. Not sure if anyone is doing anything, but if you are, you might have broken something. If you report this error to the Wikimedia System Administrators, please include the details below. Request: GET http://en.wikipedia.org/wiki/Johnny_the_Homicidal_Maniac, from 10.64.32.106 via cp1067 cp1067 ([10.64.0.104]:3128), Varnish XID 2127871567 Forwarded for: 162.17.205.153, 208.80.154.76, 10.64.32.106 Error: 503, Service Unavailable at Thu, 14 Nov 2013 18:48:33 GMT Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Issue
Just got this when trying to read an article. Not sure if anyone is doing anything, but if you are, you might have broken something. If you report this error to the Wikimedia System Administrators, please include the details below. Request: GET http://en.wikipedia.org/wiki/Johnny_the_Homicidal_Maniac, from 10.64.32.106 via cp1067 cp1067 ([10.64.0.104]:3128), Varnish XID 2127871567 Forwarded for: 162.17.205.153, 208.80.154.76, 10.64.32.106 Error: 503, Service Unavailable at Thu, 14 Nov 2013 18:48:33 GMT The issue seems to be confined to Wikipedia. I am not seeing it affect Mediawiki.org Additionally the issue seems to be affecting more than just the English language Wikipedia. The lojban language Wikipedia is also experiencing difficulties. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Google Code-in: are you in?
Google Code-in has been announced: http://www.google-melange.com/gci/homepage/google/gci2013 This is about 13-17 year old students performing tasks that can be isolated and a skilled contributor would complete in a couple of hours. The tasks mjust have a mentor and can be related to code, documentation, outreach, QA or UX. Participants get one point for each task completed and they can complete as many as they can between 18 November and 6 January. Wikimedia can apply thanks to our participation on GSoC 2013. The deadline is 28 October. Only 10 organizations will be accepted. I think we should apply. Main reasons: ... But of course this will only work if many projects want to step in with a task and a mentor for it. So what do you think? I personally think this is a great idea. I would have killed (metaphorically speaking) to have been able to participate in something like this with Mediawiki when I was in that age range. I concur that it seems like a good way to get annoying little bugs solved. Beyond having mentors are there anymore requirements that we need to fulfil as an organisation? I wasn't able to find an FAQ for organisations wishing to participate. Do you know if one exists? If I had more time, and had contributed more code (or any code) to the Mediawiki codebase (which I mostly don't due to the aforementioned lack of time), I would offer to mentor even. This seems like a really great opportunity to pick up some new volunteers and get some annoying bugs out of the way. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Exceptions, return false/null, and other error handling possibilities.
Out of curiosity, what's an actual example of code where the execution flow of exceptions is significantly more surprising than the execution flow of a billion manual checks to avoid Fatal error: Call to a member function foo() on a non-object? I've heard the vague claim that exceptions are confusing for years, but for the life of me I've never seen exception-handling code that looked more complex or confusing than code riddled with checks for magic return values. My experience has been similar. I personally prefer exceptions as they at least let me know in a highly visible way when I forget to do something about them, unlike magic return values which may cause problems which do not surface right away if a check is forgotten. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] File cache + HTTPS question
I disagree. For a low traffic site, its probably performant enough with just APC caching, which the installer sets up for you. Vanilla mediawiki does the things you expect a wiki to do. I doubt these types of users want/need complex things like abuse filter and lua. (Unless you are copying templates from wikipedia) The major thing out of the box mw is missing is confirm edit. The other stuff is cool but non-essential imo. Just want to throw in my hat here as well. I use Mediawiki on my personal website, my laptop, and my place of business. In each case it fulfils a different role. In the case of my laptop, I don't need caching it just acts a good place to take notes on a variety of projects that I working on. I went with it because I was used to how it worked from editing Wikipedia and it was easy to set up. My laptop runs Windows with a copy of Apache and PHP installed on it for development work. On my personal website I have a wiki that requires an account to edit with account creation disabled. I don’t use caching their either, but if my site got more traffic I would. In this case I installed Mediawiki in order to be able to quickly create pages of text for documentation or when translating news articles for people for political advocacy. On my personal website Mediawiki is set up on a shared host with all of the disadvantages that come with such a setup. At my work we use Mediawiki as a knowledge base and to document standard operating procedures. Here Mediawiki was chosen for its ease of use for an end user and the audit trail that articles inherently leave. It was a bonus that I have experience writing Mediawiki extensions as well. Here we run it on a dedicated web server running Ubuntu Server Edition that I have root on. Anyhow, I guess I didn't really make what I'm trying to say here terribly clear. Lots of people use Mediawiki for a lot of different reasons in a lot of different enviornments. I can't easily set up many of the items that are used by the WMF on my Windows laptop, nor on my shared hosting account. Personally in those situations I would enjoy Mediawiki to still work reasonably well. By all means drop the file cache if no one really uses it, but I personally would be against dropping support for people who are in shared hosting environments or other environment that don't match up with the typical VPS or dedicated server. Thank you, Derric Atzrott ...now back to lurking. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Improving anti-vandalism tools (twinkle, huggle etc) - suspicious edits queue
Is it possible to
enable them in reverse-mode so that all edits are flagged as good, but
editors can flag them as bad? If not, I can't see how it could be
useful for this purpose...
flagging as bad? Do you mean reverting?
I just don't see what you are trying to accomplish. Sorry.
I think he's looking to flag as suspect, not to revert as bad. Are you
really not following, or just not agreeing?
A possibility is to use a maintenance template, like {{cn}} or {{dubious}},
but this solution shares with using flagged revs for it - which would be a
great solution - that it might be viewed as negative by the en.wp community.
I thought FlaggedRevs prevented the newest version of the page from being shown
until it has been approved?
Flagged Revisions allows for Editor and Reviewer users to rate revisions of
articles and set those revisions as the default revision to show upon normal
page view. These revisions will remain the same even if included templates are
changed or images are overwritten.
I think he also wants the edit to go through and be visible right away. I
believe that he is trying to assume good faith in these types of edits. Trust,
but verify, if you will.
I'm not entirely sure that FlaggedRevs is the best solution here.
Thank you,
Derric Atzrott
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Use of http:// urls in wikimedia wiki emails
Problem is (I think) we defaulted it on, so most users in China have the preference turned on, it just doesn't effect the login process since it's overriden by the geoip lookup. Mhm makes sense. Could the geoip check also disable the preference check mark? What if I am on vacation in China and want the preference to still be checked when I return home? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
Well if it's a MediaWiki extension, it has to be GPL-compatible, otherwise using it as part of MediaWiki violates the core's own GPL license. Wrong. WMF can use any software they like on their servers... even propriatary software. They are _using_ it, not _distributing_ it. Compatible licencing is only relevant on software that is distributed, in the WMF's case, MediaWiki and related extensions. I wasn't even aware though that extensions to be distributed needed to be licensed under something that is GPL compatible. It's been a while since I read the GPL. Looking back over it again (well the FAQ actually), that is very non-intuitive... we'd need to fork the Mediawiki process to allow non-GPL extensions to be distributed? I might have to look into licenses again and make sure what I use is GPL compatible. The GPL is such a pain sometimes Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Error Creating Thumbnail?
I noticed that one of the images uploaded to my Wiki is showing the following: Error creating thumbnail: Invalid thumbnail parameters instead of a thumbnail. Its a PNG image, not an SVG. There is no message in any of the log files that I can see. Im not entirely sure how to go about diagnosing this. Image Details: File:Lab Map.png (6,001 × 2,387 pixels, file size: 1,003 KB, MIME type: image/png) Any ideas what the issue might be or where I could look for more info? Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
Oh - if anyone can authoritatively compose a WMF blog post on the state of the move to SSL (the move to logins and what happened there, the NSA slide, ongoing issues like browsers in China, etc), that would probably be a useful thing :-) I'll be posting blog posts each step of the way as we move to SSL. We have plans on SSL for anons by default, but there's no official roadmap for doing so. Something sooner than later might be good. Also have you guys read the presentation. A lot of this is very chilling I agree with Jimbo. We need to fix this as best we can. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs
I made the call about a year ago, and mentioned it in several of the dozens of mailing list and on-wiki posts made about the development of VisualEditor since then. Clearly my communication about it wasn't read, or wasn't understood, by the people who subsequently complained, but I wouldn't describe it as being done silently. I guess the next question is what can we do to ensure that something like this doesn't happen again? I think everyone would have been a lot more calm if they had read and understood your communication in the months leading up to this. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] CustomEditor Hook
It appears that CustomEditor is no longer in includes/Wiki.php like the documentation says it is.[0] Any idea where this hook relocated to? Thank you, Derric Atzrott Computer Specialist Alizee Pathology [0]: https://www.mediawiki.org/wiki/Manual:Hooks/CustomEditor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs
snip Since the devs implemented resource loader it has become harder and harder to block the poorly developed bloat that has crept into mediawiki. I used to be able to isolate the JavaScript file causing the issues (I remember BITS geolocation being a major hog) and just block it. Now thats not possible any longer. snip Slightly off topic, but for this problem at least you could try using ?debug=true which will turn off that portion of Resource Loader. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Remove 'visualeditor-enable' from $wgHiddenPrefs
However, from a user's standpoint, it still doesn't make a ton of sense to do it that way. If I just want to add a category, I shouldn't have to invoke an editing surface at all. Similarly, if I want to turn a page into a redirect, I shouldn't have to edit the page at all. As most of you know, some gadgets like HotCat already operate on a similar principle. Why should VE be doing this if you're not entering the editor. HotCat (and the future extension based on it) can handle categories just fine. The VE team should focus on fixing its current issues before attempting to introduce new features. I agree with Tyler here. This should really be deployed as a separate extension that perhaps makes use of Visual Editor. I also agree with the sentiment that we need to fix the current issues before we try to add more features, though looking towards the future is still reasonable. Also I don't see why we can't work out that problem though when it arrives. Currently we have a very immediate issue though of the masses politely requesting and then demanding that this option be added back. If we need to remove it again later, I don't see why we can't. There were a large number of us who argued that this deployment was inappropriate to begin with, and I personally still stand by that. Visual Editor is not yet ready for the masses and the masses have made it clear that they don't want to use it (see source edits vs visual edits as discussed earlier). We're not asking that you disable Visual Editor as the default editor, if you still feel that it needs to be the default in order to collect the data you need for bug testing, that's fine by me (though I continue to disagree with the decision), go ahead and do that. For the people though that do not foresee themselves using Visual Editor anytime soon, it would be nice for them to have an option that isn’t a hack. I know I'm repeating arguments here that have already been covered in previous posts, but I really think that adding the option back is the way to go. I would go as far as to say enable the option and then continue the discussion as to whether or not the option is appropriate. Every day that passes that it is not around is another huge PR hit for all of us developer types. From what I have seen on this mailing list the past few days, please correct me if I am wrong, is that the community feels frustrated that the product team for Visual Editor is failing to acknowledge their needs. Enabling this preference would likely clear the air a lot and allow us to have a much saner discussion as to the direction this project needs to go. Thank you, Derric Atzrott ps. Really looking forward to when Visual Editor is done. This has been the most exciting extension I've seen in a long time and I really do want it to succeed. I've seen a large many people turned off by Wikitext, but we can't afford to create the rift we are making right now. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Gitblit down?
Afternoon, Anyone else having issues getting at Gitblit? I've not been able to get at it for the past half hour or so. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins
When I attempt to upgrade MediaWiki I currently have to write down all of the extensions, and ensure all of them are compatible with MediaWiki. With some subsets, I need to ensure they are compatible with each other (like SMW, SF, SRF). Now I'm going to need to do that and track the compatibility between extensions and dependency extensions. I'm actually going to have to write an upgrade matrix to upgrade, and that's not OK. Why would you want to manually keep track of the dependencies when a tool such as composer can handle it for you? To throw another viewpoint into the mix. If we require composer, we require users to learn to use composer. Some like myself have never used it, and while it’s a skill I should probably learn that will save me considerable time, it may be that not all will find being forced to learn a new piece of software so great. Of course I could be missing something here. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 120, Issue 54
Give them time Edmund. Alternatively, you can go to the following URL and remove yourself. https://lists.wikimedia.org/mailman/listinfo/wikitech-l Thank you, Derric Atzrott -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Edmund Sent: 19 July 2013 15:25 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Wikitech-l Digest, Vol 120, Issue 54 HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST?HOW ABOUT YOU REMOVE ME FROM THIS MAILING LIST? On 19 July 2013 19:56, wikitech-l-requ...@lists.wikimedia.org wrote: Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-requ...@lists.wikimedia.org You can reach the person managing the list at wikitech-l-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than Re: Contents of Wikitech-l digest... Today's Topics: 1. Re: MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins (C. Scott Ananian) 2. Re: Request for Comments: New Search (C. Scott Ananian) 3. Re: MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins (Ryan Lane) 4. Re: Git config trick. (Tyler Romeo) 5. Re: MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins (Jeroen De Dauw) 6. Re: Git config trick. (Roan Kattouw) 7. Re: MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins (C. Scott Ananian) 8. Re: MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins (Tyler Romeo) 9. Re: Git config trick. (C. Scott Ananian) -- Message: 1 Date: Fri, 19 Jul 2013 14:20:28 -0400 From: C. Scott Ananian canan...@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] MediaWiki extensions as core-like libraries: MediaWiki's fun new landmine for admins Message-ID: cak5kh3xyp5ry+gsq3la3t1qp7fcpbfpf9ex0yz7z0mdx1p6...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 It might also be worth going a wikibase release (on its own schedule or else scheduled shortly after each MW release), that contains a particular MW version along with version of the extensions that have been tested to work with it. This is the usual way in which these sorts of dependency chains
[Wikitech-l] Alternative editor?
Good day, Now I finally do have a question that might make some sense. I'm attempting to replace the editor for Mediawiki for certain pages. Are there any examples of how to use the AlternateEdit hook beyond looking at the code for Mediawiki itself? Are there any extensions that make use of this hook? Does VisualEditor? I just want a second example of how to build an edit page that does things a little differently so that I can compare the two and learn a bit more about ways that I can go about this. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Strange Visual Editor Diff
Where do we send diffs from Visual Editor that look strange? Such as this one: https://en.wikipedia.org/w/index.php?title=Polycarbonatediff=prevoldid=5646183 11 Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Strange Visual Editor Diff
Where do we send diffs from Visual Editor that look strange? Such as this one: [snip] Thank you, Derric Atzrott Computer Specialist Alizee Pathology The link arrived broken. Here's an attempt to unbreak it: http://j.mp/12VNTD6 And Bugzilla is probably the right place. I suspect that I saw similar comments already, about mysteriously deleted templates, but I can't point to a particular reported bug, so reporting it won't hurt. You correctly fixed the link. I'll report it on Bugzilla. It appears that along with breaking a template, an entire chunk of the article was copy/pasted to the bottom of the article. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ContentHandler Questions
Good Day, I'm thinking about creating another Mediawiki extension here at my work (well actually, more likely starting over on one I haven't touched in several months) and I have a few questions about ContentHandler and if it is an appropriate mechanism to make use of in this extension. ...snip... Thank you, Derric Atzrott It appears that I misunderstood what ContentHandler is and what it does. This misunderstanding has been corrected. If I have any more questions, I'll send them though. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ContentHandler Questions
Good Day, I'm thinking about creating another Mediawiki extension here at my work (well actually, more likely starting over on one I haven't touched in several months) and I have a few questions about ContentHandler and if it is an appropriate mechanism to make use of in this extension. The extension I am planning on (re)making handles some data entry type stuff about some of our computer systems here. I was thinking of creating a new namespace called MP for the extension and then having articles in it named after our various systems. There would then be a Special Page that keeps track of all of these articles and provides some summary information on them in a table. The articles, would contain several pages of structured information about our computer systems. I feel like I had read that ContentHandler lets me define my own editor for that type of content. [0] Would I be able to define an editor that has multiple pages? The workflow that I would like to create splits the editing of the information into several pages (one for intake questions, another for documentation, yet another for regulatory related questions, etc.). I could make this all as a standalone program, but I don't want to re-invent the wheel if I don't have to when it comes to keeping track of revisions and displaying diffs and the like. Plus keeping it in Mediawiki gives my users an interface for that they are already familiar with. I feel as though I was not at all clear in this email, so if I didn't give enough information or you have questions that might clarify both in my mind and yours what I am trying to accomplish feel free to ask. Thank you, Derric Atzrott Computer Specialist Alizee Pathology [0]: https://www.mediawiki.org/wiki/Manual:ContentHandler/Doc At least, this is alluded to in action=edit will fail for pages with non-text content, unless the respective ContentHandler implementation has provided a specialized handler for the edit action. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please identify your Wikimedia handles
PS: why a Google form and not something better? See https://bugzilla.wikimedia.org/show_bug.cgi?id=51050 :) That page does not mention anything of the sort. True, strictly speaking. Let me explain: Ideally this information would be defined by Wikimedia contributors through their user profiles at http://wikitech.wikimedia.org Since we don't have such feature implemented, we are using a Google form to get the data with certain privacy and order (at least compared to a public wiki page). Then that data needs to be introduced manually in the database powering http://korma.wmflabs.org/ Additionally, not everyone who uses the Mailing list and associated items that are asked about on the Google Form has a Wikitech account. I, for instance, don't have a Wikitech account, but do contribute to the Mailing list whenever I feel I can (and I read everything). Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Visual Editor Roadmap
Good day all, I was just taking a look at the Roadmap page[0] and the Engineering goals page[1] and noticed that on both the Visual Editor section ends right about now. I found these from the FAQ page [2] so we may want to update that with links to any pages that any of you are able to locate. Is there anywhere that I can find the Roadmap going forward until the end of the year? [0] https://www.mediawiki.org/wiki/Roadmap#VisualEditor [1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/2013-14_Goals#VisualEditor [2] https://www.mediawiki.org/wiki/Help:VisualEditor/FAQ Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Visual Editor Roadmap
Good day all, I was just taking a look at the Roadmap page[0] and the Engineering goals page[1] and noticed that on both the Visual Editor section ends right about now. I found these from the FAQ page [2] so we may want to update that with links to any pages that any of you are able to locate. Is there anywhere that I can find the Roadmap going forward until the end of the year? My apologies, I just noticed that the Engineering Goals page does go into 2014, I misread the dates. Nevertheless though, my question still remains, is there a document, like the Roadmap document, that outlines the upcoming goals for VisualEditor for the remainder of the year? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Problems Updating from 1.18 to 1.21.1
Good morning all, I have a question about a problem that cropped up during my update from 1.18 to 1.21.1. With one exception everything went smoothly during my update, but now all of my images, appear to be without thumbnails and inadvertently using File protocol links. The generated source for embedded images looks like this: p[a rel=nofollow class=external text href=File:ReportedTime.jpg%7C451px%7CReportedtime per activity on Project/a]/p Generated from: [[File:ReportedTime.jpg|451px|Reported time per activity on Project]] Any idea what I may have done wrong. Is there a new setting that I may have missed? Has anyone ever seen this sort of issue before? Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problems Updating from 1.18 to 1.21.1
Good morning all, I have a question about a problem that cropped up during my update from 1.18 to 1.21.1. With one exception everything went smoothly during my update, but now all of my images, appear to be without thumbnails and inadvertently using File protocol links. ...snip... Any idea what I may have done wrong. Is there a new setting that I may have missed? Has anyone ever seen this sort of issue before? Thank you, Derric Atzrott I determined the issue. I had $wgUrlProtocols[] = file:; in my LocalSettings.php from an earlier attempt to get File protocol links working (would have required me to write Firefox and Chrome extensions so it was abandoned as too much effort to securely manage). Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Problems Updating from 1.18 to 1.21.1
What happened is that url protocols became case insensitive. So if you had added file: as a url protocol, previously it would trigger only on file:foo not File:foo. The solution is to change your entry in $wgUrlProtocols so that it is 'file://' instead of 'file:'. --bawolff Thank you bawolff. That explains the root of the issue much better as opposed to the change I needed to make to fix it, which would have been much more useful had I decided to keep File protocol links enabled. I've opted to just disable file protocol links in general though as it was just a left over configuration change from some time ago that I had forgotten to remove when we determined we wouldn't be using it. I think that's now twice in as many days I've been ninja'd in an email. Makes me laugh a little bit every time it happens. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Possibly malicious script inside United_Kingdom article
Dear ladies and gentlemen! Every time when I go to this page: http://en.wikipedia.org/wiki/United_Kingdom, the following script causes my browser (Firefox) to freeze. Script, which causes harm: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=falselang=enmodules=ext.centralNotice.bannerController%7Cext.uls.displaysettings%2Cime%2Cinit%2Cinputsettings%2Cinterface%2Clanguagenames%2Clanguagesettings%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CdelayedBind%2Ci18n%2Cime%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Uri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.api.parse%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cskins.vector.js%7Cwikibase.client.initskin=vectorversion=20130708T181033Z*:280 This occured only on aforementioned web page. All other pages work normally. Sort this thing out, please! Might be https://bugzilla.wikimedia.org/show_bug.cgi?id=49935 andre Sergey Might be worth trying to use debug mode for ResourceLoader? Not sure if that is enabled on WMF Wikis, but it would help narrow down which script actually caused the problem. You can add ?debug=true to the end of the URL to enable that. Right now the script you linked to is all the scripts on the page pretty much compressed into one file. Thank you, Derric Atzrott Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF Deployment Highlights - Week of June 17th
Can you explain how to set a user preference based on the number of edits a new user has? Has the VisualEditor team set up a script to roll back (i.e., undo) this change to the user preferences of new users if this experiment doesn't work well? Personally, I think it would be a little crazy to press forward with this experiment on June 19 as planned. Based on what I have seen the few times I have fooled around in Visual Editor (not sure if I actually saved any edits or just said screw this and went with the regular editor), I also think that this is a bit premature. If we need additional feedback, rather than automatically enabling it for half of the new editors, or even half of the new editors with X number of edits, we could provide a notice to new editors with X number of edits that asks them if they would like to try Visual Editor. We could provide a notice at the top of Visual Editor to allow them to easily change the preference back as well. While this doesn't solve the template issue (and the clean-up that will inevitable come of that), it might work as a solution to the getting new users to test VE issue. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Not to nitpick, but in your particular example one can use the __TOC__ magic word you can place the table of contents wherever you want in the document.[0] At least in that case, parsing the entire document might be best. /me goes back to lurking. Thank you, Derric Atzrott [0]: https://www.mediawiki.org/wiki/Help:Magic_words ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Can we help Tor users make legitimate edits?
As for legitimate users, probably the most useful thing to do would be ensuring that the TorBlock extension shows an understandable error message and sends people to a translatable page with instructions valid for all language editions of our projects with current poliecies (most projects will have none). I think this would be a great improvement to the situation. I personally use Tor pretty regularly, but seldom go to Wikipedia when using Tor because I know I'll be frustrated if I try to fix something. Up until this discussion, I had no idea it was possible to request an exemption to the Tor block. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
| I understand the concern, but if we're creating a world | where tests have to wait for developer review, we're doing | CI the wrong way around. The whole point of automated | testing is to minimize the need for human review, so we | should aim to run as many tests as possible as early as | possible. Both test performance and security considerations | are problems to be gradually resolved in aiming for highest | possible test execution for all code that gets submitted, | and minimizing the need for human review on code which is | obviously broken. Why not just add (more) slaves? Computing power is much cheaper than developer time. I absolutely agree. I'm also in agreement on this one. Having tests run after code review negates the point of having tests run in the first place. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki
Throwing in my 10 cents on the matter. I was going to go on a long rant here in response to your assertion that we shouldn't have a flashy interface, but I'll spare everyone and just say that I strongly disagree. I am not opposed to having a flashy interface at all and did not assert anything like that. However, having flashy interfaces does not automatically mean that the user experience for users with older soft / hardware has to be bad. In many cases, it is actually pretty easy from a technical perspective to provide a reasonable experience for older browsers while still having flashy things where supported. I agree with this. And I think that gracefully degrading should be the policy wherever possible. If I want to do things on Wikipedia from Lynx [0] I should be able to do as much as Lynx supports, not less because my useragent doesn't match something that we support. I fear that a binary browser policy would discourage people from keeping this in mind, and think that we can do better than that. /\ This. I also agree with this 100%. It could be fairly easily solved though by simply mentioning that the intention of the policy is not to discourage people from making gracefully degrading interfaces. That would solve the problem of people pulling out that policy and pointing to it as a reason for why their stuff doesn't at least semi-work. On the topic of which browsers to include, I recommend against having a hard list (Firefox, Chrome, IE, etc.). I think it would be preferable to use percentages, but keep a list of what browsers meet that criteria at any given time (preferably automatically updated). I think a static list of browser, while correct and relevant now, may not be 5 years down the line. Although everyone at the WMF and who volunteers with the WMF is a lot better about updating outdated policies than almost anywhere else I have ever seen, we all know that we have our fair share of outdated policies and documentation. Anyhow, that's where I stand at least. Thank you, Derric Atzrott Computer Specialist Alizee Pathology [0] http://lynx.browser.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] HTTPS Mobile en.wikipedia.org
My phone's homepage is set to https://en.wikipedia.org/ . Yesterday I noticed for the first time that the redirect to the mobile site sends you to http://en.m.wikipedia.org/ regardless of whether or not you used http or https to begin with. I'm not sure if this is the right list for this (as I'm not on any other lists, so I don't know their culture and scopes as well), but I believe that it is on topic. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On GitHub, rename wikimedia/mediawiki-core - wikimedia/mediawiki
The fact that mediawiki's repository is named mediawiki-core doesn't make sense to me. The chief benefit provided by GitHub is its popularity and visibility. We don't manage our code review or release process in GitHub anyway, so I see no reason not to give the most weight to aesthetic / populistic considerations. Let's make it github.com/wikimedia/mediawiki. Visibility helps! This is not possible. Repos are the same name on the source and destination. -Chad Not to mention that might be confusing down the road for someone looking to find our copy of mediawiki-core on Github. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org is no more
Following last year's Native HTTPS efforts¹, I've pushed a change² today that redirects all the old secure.wikimedia.org URLs to the respective native HTTPS ones, e.g. https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page gets redirected to https://en.wikipedia.org/wiki/Main_Page Does anyone know if EFF's HTTPS Everywhere extension is set up to redirect to secure.wikimedia.org? If so, someone might want to let them know that we've made this change. I'll volunteer to do so if no one else wishes to. The redirects are HTTP temporary redirects (302) for now. I'll soon switch them to permanent (301), please do let me know if you see any breakage in the meantime. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
* we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers. I think somebody (or possibly a few somebodies with knowledge of different parts of the code) should at least quickly scan these lists, since some of the things marked as LATER might have been fixed in the meantime (and nobody found the bug to close, since it was RESOLVED) or have been made irrelevant (such as https://bugzilla.wikimedia.org/show_bug.cgi?id=34329 which I found skimming the list a few days ago). A week provides ample time to do that. Although, I'm sure if there are disagreements on that length of time, another could easily be decided upon. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Coordination between developers in Free/libre open source projects
Your survey doesn't allow one to select an age lower than 18 years old, and MediaWiki has some younger developers. It also doesn't allow for an education level below high school / technical school, and for example I, being 18, haven't finished high school yet. So yeah, I'd like to take part in the survey, but I can't. -- Matma Rex You should also add N/A options to many of your questions. Some of them are not applicable to all of us, or make very little sense in the context of some of us. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A bot to create articles about species
No one has ever suggested for Wikidata to create articles. OK; then I misunderstood and generate the article on the fly.. So to make sure that I understand this correctly, this is the idea: * Let's say I search on the lojban Wikipedia for Creagerstown, Maryland * The article doesn't exist, but Wikidata has information on it. * I'm told the article doesn't exist, but presented with a template showing when the town was founded etc. along with search results Assuming the above is correct: Would they be able to make use of that template if they wanted to quickly throw together a stub on the topic? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome Željko Filipin, QA Engineer
I am pleased to announce that Željko Filipin joins WMF this week as QA Engineer. All right! Welcome, Željko! It will be great to have some more power behind our QA. I look forward to seeing you around the mailing list and IRC! Forgive me for asking, this is by no means meant to be rude, but how does one pronounce your name? It is very unique looking to my uncultured eyes. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dependency management, MediaWiki and modularity (was Re: New extension: Diff)
After the ones about sending email and Common Lisp, we can add: Every app also expands until it contains a sketchy rewrite of apt-get. c.f. Perl, PHP, Ruby, Python, WordPress ... One thing to possibly think about: compatibility of any new system with Linux distro packaging mechanisms, like apt-get and yum. The less distro maintainers have to mess with MediaWiki the better. Wanted to send this to you directly, since it is off topic. Where is that quote from? It is so incredibly true. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dependency management, MediaWiki and modularity (was Re: New extension: Diff)
After the ones about sending email and Common Lisp, we can add: Every app also expands until it contains a sketchy rewrite of apt-get. c.f. Perl, PHP, Ruby, Python, WordPress ... One thing to possibly think about: compatibility of any new system with Linux distro packaging mechanisms, like apt-get and yum. The less distro maintainers have to mess with MediaWiki the better. Wanted to send this to you directly, since it is off topic. Where is that quote from? It is so incredibly true. Sorry all. I meant to send that to just him. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dependency management, MediaWiki and modularity
I do agree with David Gerard's assessment, though. We need to make sure that whatever we use is going to work with package management tools that Debian and Redhat and the like already use. The other reason is, of course, making the distro versions of MediaWiki not suck. A great place to start would be the SMW Bundle: http://www.mediawiki.org/wiki/Semantic_Bundle Oh man, if I could apt-get that my life would be way easier. (Looking into the future when there's a current, maintained, not-insane MediaWiki in Debian/Ubuntu.) With the exception of phpMyAdmin, I don't think I've ever seen a piece of PHP software that you could really just apt-get and have easily installed. So this is definitely a worthy goal to pursue. I too would love it if I could set up a simple Wiki on an Ubuntu/Debian box by typing apt-get install mediawiki mediawiki-extension-XYZ mediawiki-extension-ZYX. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] shortened links (was Re: MediaWiki 1.20 release candidate (and triage announcement))
I personally agree it's annoying and wish you didn't. But maybe there's mangling examples I've not seen. IMHO, it should usually be enough to either wrap in angle brackets or put the URL in a footnote on it's own line with just the footnote number. Anyway, I do certainly think we have bigger fish to fry. Agreed on all counts. As a compromise, might I suggest including both? [0] [0-short]: http://exam.pl/ [0-long]: http://www.example.com/ Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to add an API/Developer/Developer Hub link to the footer of Wikimedia wikis
Is anyone else excited about this idea or is it just me...? That is an intriguing concept that could indeed work quite well to get people interested, but how many will remain interested after they encounter gerrit? I can't actually say I like this idea a whole lot. Here's why: * Personal appeals have to be well written in order to work. A poorly written personal appeal will not actually appeal to someone and may in fact turn them away. * We use personal appeals for the fund raising drive. I think using them here as well, especially when we have these [1] going on every year is a bad idea. * A personal appeal on a page like this is a wall of text. We need to be very careful not to elicit the TL;DR response from people. ** On a similar vein: This page needs to be fairly appealing in appearance, like the MediaWiki.org homepage is, or people will leave. In my experience, programmers are very practical pragmatic people. I don't think that a personal appeal is the best way to appeal to them. At least not how the idea is currently presented. The Mediawiki.org homepage does a better job of getting my hyped to use Mediawiki right now. [1]: http://knowyourmeme.com/memes/wikipedia-fundraising-campaign ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTML5 and non valid attributes/elements of previous versions (bug 40329)
1: Disable the transform and output the align attribute even though it's not valid HTML5. Solve validness later. 2: Remove the attribute from HTML5 and 'break' the content. Fix by users (or bot). 3: Disable HTML5, correct the content of the wiki's (possibly with a bot) and remove the attribute in HTML5 mode, reenable HTML5. 4: Fix the transform (not that easy) My personal preference is with 1, since this is causing trouble now and with 1 we solve immediate problems, we just add to the lack of valid HTML5 output that we already have. In my opinion 2 would be too disruptive and 3 would take too long. Danny is of the opinion that we should never transform at the parser side and that we should fix the content instead (2 or 3). So, how best to fix the issue/what should be our strategy with regard to content that is not HTML 5 valid in general ? Can't we do both 1 and 4. Remove it for now, fix the transform, and then re-enable the transform and disable the align attribute? Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
