Re: [Wikitech-l] Code ideas thread
On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen dan...@nadir-seen-fire.com wrote: On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp cste...@wikimedia.org wrote: On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadr...@gmail.com wrote: On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerro...@gmail.com wrote: Not a good idea: http://xkcd.com/927/ While OAuth has its problems, it's not a terrible protocol (or at least v1 isn't). Randall is right in general about standards proliferation for standards sake. But that's primarily about just writing a standard for other people to use. If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in. - OAuth 1 had some important issues too. In particular the temporary credentials and the limitations on the user experience caused by the single flow. - The flow limitations is probably a big one for us. And it is possible to work around the issue by separating OAuth into two parts. But by doing that you diverge from the spec and there isn't much more reason to stick with that standard. And afaik the libraries for doing OAuth 1 don't support these alternative types of flows. Seconded -- I'd rather see contributions to making OAuth less painful rather than invent Yet Another Standard. I have to agree too. OAuth has problems, but it would allow several of wmf's current integrations to be more secure overall, and that would be a win for us. If Daniel is able to create a protocol that is as secure, and easier for developers to use securely, then I will definitely push to switch over. But until then, I'm still going to try and get OAuth out. Thanks. I already know what I have lying around in my head will keep OAuth 1 level security while making signatures easier to implement. Although the fundamental idea in this area is auth should always be done by a library/SDK anyways. The stuff making my head spin actually isn't even any part of the basic auth. It's not even discovery itself. The hardest thing to figure out is what to do about making discovery and dynamic registration over HTTP secure. Which frankly is something that no protocol has anyways. The only problem with writing out an actual standard for the rest of the stuff is all my good hours are taken up by work. The leftovers wouldn't be enough to get out a good enough quality standard and reference/testing implementation. I just spent two ENTIRE days in a trance with nothing but auth flows spinning around in my head. All I was able to get out in writing so far is this draft collection of high-level auth flows to aim to support. https://github.com/dantman/protoauth-spec/blob/master/auth-flows.md Rather than jumping to get OAuth out what about first trying to get the fundamental base pieces we need for all of these into core. ie: Abstract authorizations and applications. Revocation pages. Attaching an authorization/application to changes like revisions, logs, etc... and tools to mass-revert by confidential application or multiple public authorizations. We'll need that stuff no matter what we implement. And it's going to take awhile just to implement those things. We can decide whether we want OAuth or something else when we finally get to that point. I'd also love to see MediaWiki support SAML too, for our .edu/.gov users. Did these organizations need to use those SAML credentials directly for API things or is this just another method we want to support for logging in? My personal wishlist: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. Mozilla is also interested in this. I don't think we can use it on wmf sites, but if you're interested in working on it, I can probably get you in touch with someone there. I think it would be a great feature. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikitext-l] [X-POST][GSoC] Realtime Collaboration on VisualEditor
I think the code has enough scope of getting refined before it is very much ready to be integrated, especially the client side code. Also, I think it would be enough time during which I can write some code for supporting multiple editors, while keeping the existing code robust. On Sat, Aug 25, 2012 at 1:07 AM, Sumana Harihareswara suma...@wikimedia.org wrote: Ashish, thanks for the writeup, and for your work! I see in https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#Visual_Editor that integration of your work into VisualEditor is scheduled for sometime in April-June 2013. What will you be doing to avoid code rot between now and then, to ensure that the VE team (including you) can perform that integration 8 months from now? Thanks again. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation -- Ashish Dubey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Appreciation thread
On 08/24/2012 09:28 AM, Derric Atzrott wrote: MZMcBride for sparking some discussions that really needed to be discussed. I was thinking of who I appreciated and thought I would mention MZ, too. I do, of course, appreciate every one else who has been mentioned, but I think it is important to mention MZ. Although he is often seen as an irritant, the Foundation needs a community member like MZ who sticks around (so he is familiar to the people working in the Foundation) and who consistently and loudly reminds the Foundation how they could better serve the community. MZ plays an important part: In an organisation like the WMF, groupthink can be a problem. MZ points out the problems that people would rather ignore or gloss over. Mark. -- http://hexmode.com/ Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Appreciation thread
MZ plays an important part: In an organisation like the WMF, groupthink can be a problem. MZ points out the problems that people would rather ignore or gloss over. +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughaksha...@gmail.com wrote: 6. Parser tags, Magic Words (Variables) and a parser function parser tags -- conference, page, account, registration,passport,author,submission,event,organizer and location This is a disgusting way to store data. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
-1 On Sun, Aug 26, 2012 at 11:34 PM, John Du Hart compwhi...@gmail.com wrote: On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughaksha...@gmail.com wrote: 6. Parser tags, Magic Words (Variables) and a parser function parser tags -- conference, page, account, registration,passport,author,submission,event,organizer and location This is a disgusting way to store data. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
On 08/24/2012 01:33 PM, Nabil Maynard wrote: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla. -- http://hexmode.com/ Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
2012/8/26 Mark A. Hershberger m...@everybody.org: On 08/24/2012 01:33 PM, Nabil Maynard wrote: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla. +[[Crore]]. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
On Aug 26, 2012, at 11:04 AM, John Du Hart compwhi...@gmail.com wrote: This is a disgusting way to store data. I don't think we need to talk to each other like this. --- Brandon Harris, Senior Designer, Wikimedia Foundation 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] Wikimedians are rightfully wary
Daniel, interesting experience. The case of requested configuration changes is rather simple though: they require consensus, so the place you were looking for is linked in comment 0. For the same reason, there's usually no need to tell the community, the reporter will take care of that. Focused centralnotices, as proposed by Alex, are a definitely better system than spam on village pumps (which not everyone reads by the way). Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Appreciation thread
Sumana Harihareswara wrote: How about a little email thread for us to say nice things about each other? Rules: be kind, thank someone, and say why you're thanking them. I know a few people have thanked you for starting this thread, but I actually came to appreciate you and your work much more in your absence earlier this month. It wasn't as obvious how much you do (particularly in bug wrangling and poking and prodding) until you were taking a well-deserved vacation. The reward for a job well done is another three jobs, as David Gerard says. Your ever-growing portfolio shows the truth in this. :-) I'm also very grateful for the patience of the wikitech-l community (and more broadly the MediaWiki development community), who choose to put up with me and other Wikimedians. It's no secret that Wikimedians are a pain in the ass to work with: they're quite often hyper-critical, needy, insolent, and stubborn. They complain loudly and congratulate softly. And this of course doesn't get into the problems they cause by speaking far too many languages and wanting MediaWiki to do everything under the sun. ;-) But the developers take it all in stride and they do their best to make the user experience (software, hardware, and everything in between) better each iteration, all while dealing with a sometimes painfully unsociable lot of people. For that, I'm have a deep amount of appreciation and respect. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
During your time in GSoC, what type of things did you mentor explain? Because i've had a quick peruse of your gerrit change sets and I know they are only minor but I do see a few things that our Coding Conventions cover as well as stylize (which is a script that is can be run) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
Hello Peachey, Honestly I never got into reading any Coding Conventions or style guide while I was developing code for my extension, but I have been going through them for the past couple of weeks and have been fixing those style issues with my code since. Its only a matter of time before all such issues will be addressed, I am continually working on fixing them. You can go and see my latest patches where you will get a sense of all those issues being taken care into account. I have kept a todo list of all such comments which were posted in my changesets, so before my code is finally ready to be tested or even reaches a point of being presentable it will have all such elements that you are trying to point out here. On Mon, Aug 27, 2012 at 2:54 AM, K. Peachey p858sn...@gmail.com wrote: During your time in GSoC, what type of things did you mentor explain? Because i've had a quick peruse of your gerrit change sets and I know they are only minor but I do see a few things that our Coding Conventions cover as well as stylize (which is a script that is can be run) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] replacing Planet software soon
Thanks so much for all of your help with this Daniel. The Planet feeds have been a bit neglected for a long while but I know that the people who read them really really appreciate that we keep them going. The new version is really nice and has fixed a couple weird issues we've been having. To 2.0! On Fri, Aug 24, 2012 at 4:49 PM, Daniel Zahn dz...@wikimedia.org wrote: Hi, i am planning to replace the current Planet Wikimedia software early next week. For those who might not even know planet: What is planet? -- http://meta.wikimedia.org/wiki/Planet_Wikimedia This is the current English planet as an example: -- http://en.planet.wikimedia.org/ The original planet software we have used up until now is unfortunately unmaintained and not available as a distribution package nor was it puppetized. First there was the original planet software (planetplanet.org), then development stopped and then later it was continued as Planet 2.0. Though there is also Planet Venus, a radical refactoring of Planet 2.0, and that is available as an Ubuntu package in universe :) -- http://intertwingly.net/code/venus/ , http://packages.ubuntu.com/da/precise/planet-venus --- quote from http://lwn.net/Articles/421348/: .. However, Planet's development seems to have slowed considerably — if not entirely stopped. The last updates in Jeff Waugh's repository are dated early 2007. Development seems to have carried on, somewhat quietly, with Planet Venus. It's not reflected on the Planet site at all, but digging through the mailing lists one finds development has continued under the name Venus or Planet Venus. Venus is a radical refactoring of Planet 2.0, and development discussions continue on the old Planet mailing lists --- Planet Venus uses html5lib, XSLT and Django templates to parse the feeds and create HTML. You can read more about it here: http://planet.wmflabs.org/html/ And here is a nice .svg showing the architecture is uses to parse feeds: http://planet.wmflabs.org/html/venus.svg I had this running in labs for a while at http://planet.wmflabs.org/ and puppetized it. You can find the puppet code in ./manifests/role/planet.pp and ./manifests/misc/planet.pp in the operations/puppet git repository. And recent changes can be found under topic branch planet. https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=blob;f=manifests/role/planet.pp;hb=HEAD https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=blob;f=manifests/misc/planet.pp;hb=HEAD Additionally, with the help of James Alexander (thanks!), we recently went through a major cleanup of feed URLs, fixing lots of redirected/moved feed URLs and removed broken feeds. This can be found here: http://meta.wikimedia.org/wiki/Planet_Wikimedia#Requests_for_Update_or_Removal which also links to gerrit. The new planet is already up here on a production host now: http://zirconium.wikimedia.org/planet/ The English planet looks like this: http://zirconium.wikimedia.org/planet/en/ That index.html page will disappear, it is just there to link to the different language planets for testing. So to get it live i will just switch DNS to point to the zirconium host and make the index redirect to the page on meta, as it does now. The feeds are currently all updated at 00:00 UTC via cron. If you see any issues with that, please speak up soon. And have a nice weekend, Daniel -- Daniel Zahn dz...@wikimedia.org Operations Engineer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- James Alexander Manager, Merchandise Wikimedia Foundation (415) 839-6885 x6716 @jamesofur ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in. But the problem is that it already exists is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have to make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss out their protocol because it isn't perfect (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2012/8/26 Mark A. Hershberger m...@everybody.org: On 08/24/2012 01:33 PM, Nabil Maynard wrote: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla. +[[Crore]]. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] CentralAuth API access
Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki-l] CentralAuth API access
You know the rules: If you suggest it and no one else volunteers, then you are now the primary person in charge of getting it done... On Sun, Aug 26, 2012 at 9:05 PM, John phoenixoverr...@gmail.com wrote: Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? John ___ MediaWiki-l mailing list mediawik...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki-l] CentralAuth API access
if i knew php (may it forever rot in hell) it would already be done. Since I dont know php it is up to someone else On Sun, Aug 26, 2012 at 9:24 PM, David Whitten whit...@netcom.com wrote: You know the rules: If you suggest it and no one else volunteers, then you are now the primary person in charge of getting it done... On Sun, Aug 26, 2012 at 9:05 PM, John phoenixoverr...@gmail.com wrote: Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? John ___ MediaWiki-l mailing list mediawik...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-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] [MediaWiki-l] CentralAuth API access
I would take it on, but unfortunately I'm trying to work on three different things (and classes are starting for me). But if my time frees up as winter draws closer I might consider doing it. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sun, Aug 26, 2012 at 9:26 PM, John phoenixoverr...@gmail.com wrote: if i knew php (may it forever rot in hell) it would already be done. Since I dont know php it is up to someone else On Sun, Aug 26, 2012 at 9:24 PM, David Whitten whit...@netcom.com wrote: You know the rules: If you suggest it and no one else volunteers, then you are now the primary person in charge of getting it done... On Sun, Aug 26, 2012 at 9:05 PM, John phoenixoverr...@gmail.com wrote: Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? John ___ MediaWiki-l mailing list mediawik...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] CentralAuth API access
John wrote: Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? This was kind of enjoyable to investigate. I was surprised to read that it's been five years. For the curious, Tim Starling is user ID 1 in the CentralAuth database. His registration date is 04:16, 13 March 2008, so it's a bit closer to four and a half years: https://meta.wikimedia.org/wiki/Special:CentralAuth/Tim_Starling. :-) Anyway, this is actually two bugs currently, both of which probably need to be split out into more specific bugs: * CentralAuth/global user rights/groups API; Get global user rights, membership to global groups; and userlist of global groups https://bugzilla.wikimedia.org/16860 * Write API for CentralAuth extension https://bugzilla.wikimedia.org/23821 The first bug is about read access; the second is about write access. The problem you're hitting here is that developers don't do well with broad, overly vague bugs like this. There needs to be something directly actionable (e.g., implement this specific feature link to GUI version into the API). The read bug can probably be left alone (though it really is three separate bugs rolled into one). It's straightforward enough, I think. I've gone ahead and marked it as easy (with a keyword), which should hopefully get a few more eyes on it. For the write bug (bug 23821), you should file separate bugs for each feature you want available in the API. Vague mega-bugs will almost always get no response and your most recent comment on the bug (when asked for clarification) was spectacularly unhelpful. You need to be specific and detailed as humanly possible, describing exactly what you want, if you have any chance of getting other who come along to help you out. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for August 20, 2012 - August 27, 2012 Status changes this week Bugs NEW : 413 Bugs ASSIGNED : 66 Bugs REOPENED : 32 Bugs RESOLVED : 247 Total bugs still open: 8342 Resolutions for the week: Bugs marked FIXED : 167 Bugs marked REMIND : 0 Bugs marked INVALID: 21 Bugs marked DUPLICATE : 25 Bugs marked WONTFIX: 19 Bugs marked WORKSFORME : 10 Bugs marked LATER : 7 Bugs marked MOVED : 0 Specific Product/Component Resolutions User Metrics New Bugs Per Component Scribunto 9 Parser 6 ArticleFeedbackv5 5 UniversalLanguageSelector 5 PageTriage 4 New Bugs Per Product MediaWiki 29 Wikimedia 14 MediaWiki extensions55 Wikipedia App 1 WikiLoves Monuments Mobile 7 Top 5 Bug Resolvers federicoleva [AT] tiscali.it45 jrobson [AT] wikimedia.org 21 s.mazeland [AT] xs4all.nl 11 tparscal [AT] wikimedia.org 10 hartman [AT] videolan.org 10 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [MediaWiki-l] CentralAuth API access
We need some sort of think tank (well some thing with a better name) non-profit that people donate to. To have it hire people to crank out MediaWiki features outside of just the stuff WMF wants. I'd love to spend 80% of my time cranking out fringe MediaWiki features where what the community wants and what my specialties are intersect. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On Sun, 26 Aug 2012 18:24:16 -0700, David Whitten whit...@netcom.com wrote: You know the rules: If you suggest it and no one else volunteers, then you are now the primary person in charge of getting it done... On Sun, Aug 26, 2012 at 9:05 PM, John phoenixoverr...@gmail.com wrote: Central Auth has been around for about 5 years now and we still lack a API to interact with it. There is no blocking/unblocking/locking/unlocking ability at all. see https://bugzilla.wikimedia.org/show_bug.cgi?id=23821 who do I need to bribe/torture/put a fire underneath in order to get basic access to said tools? John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
