Re: [Wikitech-l] [Foundation-l] Data Summit Streaming
* Andrew Dunbar hippytr...@gmail.com [Sat, 12 Feb 2011 03:58:49 +1100]: On 11 February 2011 22:18, Chad innocentkil...@gmail.com wrote: On Fri, Feb 11, 2011 at 5:57 AM, Andrew Dunbar hippytr...@gmail.com wrote: It doesn't work for me )-: Your input can't be opened: VLC is unable to open the MRL 'http://transcode1.wikimedia.org:8080'. Check the log for details. It was a stream. It's not streaming anything right now. Dunno if videos will be posted somewhere. oh (-: You can read the notes: http://eiximenis.wikimedia.org/DataSummitParsers http://eiximenis.wikimedia.org/DataSummitSMW http://eiximenis.wikimedia.org/DataSummitAnalytics Very interesting insight into the perspectives of development. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
Greetings, As you may know, the Wikimedia teach team has started to upgrade MediaWiki on some wikis. MediaWiki is the software that runs all Wikimedia wikis. The most visible change for Wikimedia users will be the deployment of ResourceLoader [1]. ResourceLoader optimizes the use of JavaScript in MediaWiki, speeding up its delivery by compressing it sometimes, and cutting down on the amount of unused JavaScript that gets delivered to the browser in the first place. The installation of ResourceLoader may cause compatibility issues with existing JavaScript code. Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader, will be available on IRC [2] on Monday, February 14th, at 18:00 (UTC) [3], to answer questions and help fix issues related to ResourceLoader. *If you maintain JavaScript code on your home wiki, please attend.* Don't wait until your wiki's JavaScript is all broken. Please spread this information as widely as possible; it's critical to reach as many local JavaScript maintainers as possible. Logs of the session will be published publicly. [1] http://www.mediawiki.org/wiki/ResourceLoader [2] http://meta.wikimedia.org/wiki/IRC_office_hours [3] All timezones: http://ur1.ca/3819u -- Guillaume Paumier Product manager - Wikimedia Foundation Support free knowledge: http://donate.wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
What kind of issues are expected concretely? Is there any kinds of checklist or todo? Original Message Subject: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens From: Guillaume Paumier gpaum...@wikimedia.org To: Wikimedia Foundation mailing list foundatio...@lists.wikimedia.org, Wikimedia Developers wikitech-l@lists.wikimedia.org, Coordination of technology deployments across languages/projects wikitech-ambassad...@lists.wikimedia.org Date: 2011年2月12日 18:49:27 Greetings, As you may know, the Wikimedia teach team has started to upgrade MediaWiki on some wikis. MediaWiki is the software that runs all Wikimedia wikis. The most visible change for Wikimedia users will be the deployment of ResourceLoader [1]. ResourceLoader optimizes the use of JavaScript in MediaWiki, speeding up its delivery by compressing it sometimes, and cutting down on the amount of unused JavaScript that gets delivered to the browser in the first place. The installation of ResourceLoader may cause compatibility issues with existing JavaScript code. Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader, will be available on IRC [2] on Monday, February 14th, at 18:00 (UTC) [3], to answer questions and help fix issues related to ResourceLoader. *If you maintain JavaScript code on your home wiki, please attend.* Don't wait until your wiki's JavaScript is all broken. Please spread this information as widely as possible; it's critical to reach as many local JavaScript maintainers as possible. Logs of the session will be published publicly. [1] http://www.mediawiki.org/wiki/ResourceLoader [2] http://meta.wikimedia.org/wiki/IRC_office_hours [3] All timezones: http://ur1.ca/3819u -- 青子守歌 aokomoriuta e-mail: aokomori...@enmps.net URL: http://bgs.jpn.ph/ blog: http://bgs.jpn.ph/blog/ twitter: http://twitter.com/aokomoriuta jawp: http://ja.wikipedia.org/wiki/User:aokomoriuta mixi: http://mixi.jp/show_friend.pl?id=19926155 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
2011/2/12 青子守歌 (aokomoriuta) maill...@enmps.net: What kind of issues are expected concretely? Is there any kinds of checklist or todo? Trevor probably knows more about this, but what I can tell you at least is that some wikis load their own version of jQuery in their site JS, which can break things terribly because plugins can get deregistered. Also, site JS overwriting jQuery with a different version can obviously cause issues. A few subtleties with regards to the timing of JS loading and execution have changed, but Trevor is really the person to ask about that. Also, site and user JS/CSS is now served from bits.wikimedia.org as well, which means things like relative @import statements in CSS are broken at this time; we're working on a fix for that. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Gender preference
On 11/02/11 00:24, Platonides wrote: snip And many don't even perform one edit. As I don't believe so many people create them just to change their preferences, it is a mistery for me why do they do so. My brother is always logged in but barely edit anything. The top reasons are: - he uses the watchlist - the edit interface makes it too long / too hard to correct minor typos or rephrase a sentence. - trolls I am myself mostly logged in but barely edit now a day (I prefer contributing to the MW code base). -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Roadmaps and getting and keeping devs
These have been circulating in the open source Twitterspere today. They struck me as apposite to discussions on these topics around MediaWiki. How to write a roadmap: http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote: How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ and imo, wikimedia fails at a lot of these points: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Leo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
For the last months I have been going through Bugzilla and what strikes me is that we are not using it as efficiently as other communities do. In particular, there is little follow up to reported problems (as Leo mentioned as well). On the short term, I think we can have a bugathon to clean up the buglist a little bit and re-energize some community members: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? On Sat, Feb 12, 2011 at 3:41 PM, Leo diebu...@gmail.com wrote: On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote: How to grow your contributor community (and how to decimate it): http://www.codesimplicity.com/post/open-source-community-simplified/ and imo, wikimedia fails at a lot of these points: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Leo ___ 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] Roadmaps and getting and keeping devs
Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
Thank you for your advice. You mean we should be careful about upgrading jQuery's version if the script uses jQuery, i.e. the problem you refer to is not caused if we dont' use jQuery, right? Original Message Subject: Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens From: Roan Kattouw roan.katt...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Date: 2011年2月12日 20:23:14 2011/2/12 青子守歌 (aokomoriuta)maill...@enmps.net: What kind of issues are expected concretely? Is there any kinds of checklist or todo? Trevor probably knows more about this, but what I can tell you at least is that some wikis load their own version of jQuery in their site JS, which can break things terribly because plugins can get deregistered. Also, site JS overwriting jQuery with a different version can obviously cause issues. A few subtleties with regards to the timing of JS loading and execution have changed, but Trevor is really the person to ask about that. Also, site and user JS/CSS is now served from bits.wikimedia.org as well, which means things like relative @import statements in CSS are broken at this time; we're working on a fix for that. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- 青子守歌 aokomoriuta e-mail: aokomori...@enmps.net URL: http://bgs.jpn.ph/ blog: http://bgs.jpn.ph/blog/ twitter: http://twitter.com/aokomoriuta jawp: http://ja.wikipedia.org/wiki/User:aokomoriuta mixi: http://mixi.jp/show_friend.pl?id=19926155 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JavaScript may break on your wiki: Fix it before that happens
Another thing: The html might have changed at a few places (for example galleries), so scripts which do some dom manipulation could be affected as well Leo On Saturday, February 12, 2011 at 10:53 PM, 青子守歌 (aokomoriuta) wrote: Thank you for your advice. You mean we should be careful about upgrading jQuery's version if the script uses jQuery, i.e. the problem you refer to is not caused if we dont' use jQuery, right? Original Message Subject: Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens From: Roan Kattouw roan.katt...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Date: 2011年2月12日 20:23:14 2011/2/12 青子守歌 (aokomoriuta)maill...@enmps.net: What kind of issues are expected concretely? Is there any kinds of checklist or todo? Trevor probably knows more about this, but what I can tell you at least is that some wikis load their own version of jQuery in their site JS, which can break things terribly because plugins can get deregistered. Also, site JS overwriting jQuery with a different version can obviously cause issues. A few subtleties with regards to the timing of JS loading and execution have changed, but Trevor is really the person to ask about that. Also, site and user JS/CSS is now served from bits.wikimedia.org as well, which means things like relative @import statements in CSS are broken at this time; we're working on a fix for that. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- 青子守歌 aokomoriuta e-mail: aokomori...@enmps.net URL: http://bgs.jpn.ph/ blog: http://bgs.jpn.ph/blog/ twitter: http://twitter.com/aokomoriuta jawp: http://ja.wikipedia.org/wiki/User:aokomoriuta mixi: http://mixi.jp/show_friend.pl?id=19926155 ___ 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] Roadmaps and getting and keeping devs
I think one way that non technical people can help is by trying to replicate bugs, if they follow the steps as described in the bugreport Do you get the same malfunction or not. That would be a great help as it weeds out invalid bugreports Sent from my iPhone On 2011-02-12, at 17:26, phoebe ayers phoebe.w...@gmail.com wrote: On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane I'm curious: is there a way that non-technical people can help with sprints like this? Documentation-building, maybe? Something else? I'm interested in development sprints, bugathons etc that involve both technical non-technical people; I've been involved in a few and it's pretty fun. But I don't know how many useful ways non-programmers non-developers can help. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ 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] Roadmaps and getting and keeping devs
On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs We can provide a simple ready to go Wiki installation for people to use for bug triaging and that way we can re-energize developers and clean up some of the backlog of bugs. Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they have this planned. It's apparently GLAM focused (which excludes devs like me), so I'd imagine not, unless the bugs targeted are GLAM related. - Ryan Lane I'm curious: is there a way that non-technical people can help with sprints like this? Documentation-building, maybe? Something else? I'm interested in development sprints, bugathons etc that involve both technical non-technical people; I've been involved in a few and it's pretty fun. But I don't know how many useful ways non-programmers non-developers can help. -- phoebe -- * I use this address for lists; send personal messages to phoebe.ayers at gmail.com * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
On Sat, Feb 12, 2011 at 9:41 PM, Leo diebu...@gmail.com wrote: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. This has gotten better lately, WMF created a bugmeister position and the bugmeister tries to respond to most if not all bugs after being reported. We should definitely keep up with this and try to at least confirm every problem that is being reported. The difficult part I think is responding to every patch. I don't believe that we currently have the capacity to review those patches. (In fact we barely have sufficient capacity to review the contributions of our core developers!) *Create and document communication channels. This has been talked about before, and maybe it did indeed get it little better. Being a volunteer, I believe that the staffvolunteer communication have greatly improved over the last couple months. I can't speak for the developernon-technical community communication though. We're obviously not there yet, but we are definitely improving. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In article AANLkTi=nq2tookvgmhrxbegvr6fzxe1wzv9dbzde4...@mail.gmail.com, Ryan Lane rlan...@gmail.com wrote: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs [...] Is this something that we should be doing? This is something we do at hack-a-tons. I don't remember the number of bugs smashed at the last one, but it was a decent number. I believe the next hack-a-ton is in Berlin, soon. Perhaps requiring people to travel to another country to participate in this is part of the problem. I don't doubt that real-life meetings are useful for Wikimedia Foundation employees and existing MW contributors, but it doesn't do much to encourage new people to join in. - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (NetBSD) iEYEARECAAYFAk1XJGEACgkQIXd7fCuc5vL5UgCfQGe4tQa61xOev8fzBmOosmc1 VE0Anie2oDODr9mU+jXE+tkANJnfjpY6 =dJKA -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
I believe the next hack-a-ton is in Berlin, soon. Perhaps requiring people to travel to another country to participate in this is part of the problem. I don't doubt that real-life meetings are useful for Wikimedia Foundation employees and existing MW contributors, but it doesn't do much to encourage new people to join in. We also plan to have two US-based hack-a-ton's a year, and I believe there is some form of one at Wikimania too. You don't always necessarily need to travel to another country to get to one. I don't disagree with your sentiment though. We should likely make these events easier to attend online. We already put in the effort to mark bugs before hand, and we all work on IRC while at the event, so I don't see anything stopping online participation from happening. The hack-a-tons usually don't have presentations, so that part isn't much of an issue. We can likely stream out anything that needs to be, if it comes up. I believe that in-person events are key for people to get to know one another, though. Maybe not everyone feels that way, but I definitely do. I've worked on MediaWiki for years, and I feel I know other community members much better since I've been meeting them in person, much more so than the years prior. The hack-a-tons may not be effective at bringing in new people, but I feel they are very effective at solidifying the current community that we have. - Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Roadmaps and getting and keeping devs
Leo diebu...@gmail.com writes: *Quote: Respond to contributions immediately. This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately. This is one of the things I've been trying to do as the new Bugmeister. Every day, about 20-30 bugs are created. Especially in those cases where the bug reporter is not a MediaWiki developer or regular user of Bugzilla, I try to make sure that they hear back from me, even if it is just “Thanks for reporting this, I'll try to make sure someone looks at it.” But, to your specific complaint about patches submitted through Bugzilla, I like Diederik's suggestion: Have a bugathon where we label a lot of bugs as appropriate bugathon bugs that need either: a) test patch / update patch to recent svn version a) confirmation / replication of new / unconfirmed bugs In fact, although I've been focused on the 1.17 release, I've also been thinking about the 1.18 release. This would be a great way to start addressing the creeping normalcy[1] that people have experienced with MediaWiki. I definitely want to have one or two of these bugathons during the next release cycle. If there is enough interest, perhaps we can plan something for Berlin. The other thing that will help is making more releases more often. This is one area that I want to use my new role within the community: until now, no one has been expected to make sure MediaWiki releases are made “early and often” and we were all happy enough to focus on writing new code while making software relases someone else's responsibility. More frequent releases communicate vitality to software developers. [1] http://en.wikipedia.org/wiki/Creeping_normalcy -- Mark A. Hershberger Bugmeister Wikimedia Foundation mhershber...@wikimedia.org 717.271.1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] secure.wikimedia.org commons sockpuppet site
Someone posted a link to https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage Delving further, we find https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page says Welcome to Wikimedia Commons, when in fact the real site is http://commons.wikimedia.org/wiki/Main_Page . Or is it? In fact on any page on either site, one cannot find any link to the corresponding page on the other site. So now everybody will be passing around two times the amount of links to what in fact is the same material. OK, I found the pattern for converting one to the other: https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage _ http://commons.wikimedia.org/wiki/Category:Hogtie_bondage One would hope the owners of Wiki[pm]would redirect etc. one to the other, to stem the proliferation of non-canonical links. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
I don't understand the email also... The secure site has been arround for years... 2011/2/13, MZMcBride z...@mzmcbride.com: jida...@jidanni.org wrote: Someone posted a link to https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage Delving further, we find https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page says Welcome to Wikimedia Commons, when in fact the real site is http://commons.wikimedia.org/wiki/Main_Page . Or is it? In fact on any page on either site, one cannot find any link to the corresponding page on the other site. So now everybody will be passing around two times the amount of links to what in fact is the same material. OK, I found the pattern for converting one to the other: https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage _ http://commons.wikimedia.org/wiki/Category:Hogtie_bondage One would hope the owners of Wiki[pm]would redirect etc. one to the other, to stem the proliferation of non-canonical links. What in the Christ are you talking about? Reading with squinted eyes and a cocked head, it sounds like you've discovered the secure site. It's documented here: * http://en.wikipedia.org/wiki/Wikipedia:Secure_server * http://wikitech.wikimedia.org/view/secure.wikimedia.org I have no idea what this has to do with hogtie bondage or why a post to this mailing list (or the gendergap mailing list, for that matter) was necessary. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Verzonden vanaf mijn mobiele apparaat Regards, Huib Abigor Laurens Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
On Sat, Feb 12, 2011 at 10:02 PM, jida...@jidanni.org wrote:
Someone posted a link to
https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage
M.
Delving further, we find
https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page says
Welcome to Wikimedia Commons, when in fact the real site is
http://commons.wikimedia.org/wiki/Main_Page . Or is it?
They're the same site. Served from two different domains.
In fact on any page on either site, one cannot find any link to the
corresponding page on the other site.
Yeah, secure.wikimedia.org's URL scheme isn't really friendly
to outsiders. Historically, this is because SSL certificates are
expensive, and there just wasn't enough money in the budget
to get more of them for the top-level domains. Maybe this isn't
the case anymore.
So now everybody will be passing around two times the amount of links to
what in fact is the same material.
If people are pasting double links, then they're being silly. I
imagine a lot of stuff on Commons uses {{fullurl:}} so the links
are properly generated by MediaWiki.
One would hope the owners of Wiki[pm]would redirect etc. one to the
other, to stem the proliferation of non-canonical links.
Redirection would be pointless. Serving them from the same
domain (eg: https://commons.wikimedia.org) would be great
and is already posted as a bug[0]. I think this is your primary
complaint, but as usual you spent half of your post insulting
people and creating straw men.
-Chad
[0] https://bugzilla.wikimedia.org/show_bug.cgi?id=20643
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [ResourceLoader] JavaScript may break on your wiki: Fix it before that happens
Guillaume Paumier wrote: The installation of ResourceLoader may cause compatibility issues with existing JavaScript code. It'd be nice to have a list of things that will definitely be problematic (must be fixed), things that might be problematic (should be fixed), and things that are generally discouraged (can be fixed). For example, Meta-Wiki was returning completely blank pages due to the use of document.write() on pages that contained a particular CSS class. If document.write() is completely disallowed, it should be noted somewhere prominently along with other problematic or possibly problematic bits of code. I briefly checked http://www.mediawiki.org/wiki/ResourceLoader but didn't see this kind of list off-hand. I wrote http://www.mediawiki.org/wiki/ResourceLoader/Coding_changes as a stub, though shortly after doing so, I discovered http://www.mediawiki.org/wiki/ResourceLoader/Documentation/Migration_guide which was commented out from the list of documentation pages. It may or may not make sense to merge these pages (it's still a little unclear to me who the migration guide is intended for). MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
Fine. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
jida...@jidanni.org wrote: Someone posted a link to https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage Delving further, we find https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page says Welcome to Wikimedia Commons, when in fact the real site is http://commons.wikimedia.org/wiki/Main_Page . Or is it? In fact on any page on either site, one cannot find any link to the corresponding page on the other site. So now everybody will be passing around two times the amount of links to what in fact is the same material. OK, I found the pattern for converting one to the other: https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage _ http://commons.wikimedia.org/wiki/Category:Hogtie_bondage One would hope the owners of Wiki[pm]would redirect etc. one to the other, to stem the proliferation of non-canonical links. What in the Christ are you talking about? Reading with squinted eyes and a cocked head, it sounds like you've discovered the secure site. It's documented here: * http://en.wikipedia.org/wiki/Wikipedia:Secure_server * http://wikitech.wikimedia.org/view/secure.wikimedia.org I have no idea what this has to do with hogtie bondage or why a post to this mailing list (or the gendergap mailing list, for that matter) was necessary. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site
He's complaining, in effect, that there are more than one URL for identical content, which is in fact generally a bad idea, but in this case, of course, he's wrong: different *access protocols* are being used, so it's not possible to conform the two... Whether it is in fact still a Best Practice to make sure that they're the same is another matter; I understand *why* we have a separate domain name for https, architecturally, but I'm not sure I *like* it. Cheers, -- jra - Original Message - From: Huib Laurens sterke...@gmail.com To: Wikimedia developers wikitech-l@lists.wikimedia.org Sent: Saturday, February 12, 2011 10:18:33 PM Subject: Re: [Wikitech-l] secure.wikimedia.org commons sockpuppet site I don't understand the email also... The secure site has been arround for years... 2011/2/13, MZMcBride z...@mzmcbride.com: jida...@jidanni.org wrote: Someone posted a link to https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage Delving further, we find https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page says Welcome to Wikimedia Commons, when in fact the real site is http://commons.wikimedia.org/wiki/Main_Page . Or is it? In fact on any page on either site, one cannot find any link to the corresponding page on the other site. So now everybody will be passing around two times the amount of links to what in fact is the same material. OK, I found the pattern for converting one to the other: https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Hogtie_bondage _ http://commons.wikimedia.org/wiki/Category:Hogtie_bondage One would hope the owners of Wiki[pm]would redirect etc. one to the other, to stem the proliferation of non-canonical links. What in the Christ are you talking about? Reading with squinted eyes and a cocked head, it sounds like you've discovered the secure site. It's documented here: * http://en.wikipedia.org/wiki/Wikipedia:Secure_server * http://wikitech.wikimedia.org/view/secure.wikimedia.org I have no idea what this has to do with hogtie bondage or why a post to this mailing list (or the gendergap mailing list, for that matter) was necessary. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Verzonden vanaf mijn mobiele apparaat Regards, Huib Abigor Laurens Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ 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] secure.wikimedia.org commons sockpuppet site
- Original Message -
From: Chad innocentkil...@gmail.com
In fact on any page on either site, one cannot find any link to the
corresponding page on the other site.
Yeah, secure.wikimedia.org's URL scheme isn't really friendly
to outsiders. Historically, this is because SSL certificates are
expensive, and there just wasn't enough money in the budget
to get more of them for the top-level domains. Maybe this isn't
the case anymore.
Is that in fact the root cause, Chad? I assumed, myself, that it's because
of the squid architecture.
So now everybody will be passing around two times the amount of
links to what in fact is the same material.
If people are pasting double links, then they're being silly. I
imagine a lot of stuff on Commons uses {{fullurl:}} so the links
are properly generated by MediaWiki.
No, in fact the root cause of his complaint is pretty likely to be
HTTPS-everywhere, which redirects users to the https site in case they're
at an insecure wifi spot, so their creds don't get stolen.
This is likely to markedly increase https traffic; I've myself been wondering
if that's been noticed the last month.
Redirection would be pointless. Serving them from the same
domain (eg: https://commons.wikimedia.org) would be great
and is already posted as a bug[0]. I think this is your primary
complaint, but as usual you spent half of your post insulting
people and creating straw men.
Aspergers' syndrome is a bitch.
Cheers,
-- jra
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
