Wikitech-l February 2013

wikitech-l@lists.wikimedia.org

161 participants
170 discussions

Congrats Yurik and Tyler Romeo, new core maintainers
by Sumana Harihareswara 19 Feb '13

19 Feb '13

Just wanted to note that volunteers Yuri Astrakhan (yurik) and Tyler Romeo (Parent5446) now have +2 rights in MediaWiki core and all MediaWiki extensions. They can thus give binding reviews to your changesets. You might remember Yuri from API work years ago and from his web API proposals and work recently. Parent5446 has been submitting changesets since July 2012 and was reporting bugs as long ago as 2008, and cares a lot about authentication and security. Thank you both for your work past, present, and future! Currently requesting consensus for maintainership in core: hoo ("Hoo man"). https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership#Hoo_.28Marius_H… Several other folks have gotten +2 on specific extensions recently, as you can see in https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership/Archive . Right now I am emailing wikitech-l when we have a new core maintainer but not for the more frequent new extension maintainers; hope that makes sense to list inhabitants. :-) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Grants available for anti-surveillance/anti-censorship design & other tech work
by Sumana Harihareswara 19 Feb '13

19 Feb '13

http://openitp.org/?q=openitp_first_round_of_2013_project_funding_now_open_… OpenITP's first round of 2013 project funding is now open for proposals! Deadline: 31 March 2013 "OpenITP project grants are meant to support specific technical efforts to improve users' ability to circumvent censorship and surveillance on the Internet. "Technical" doesn't have to mean software or hardware -- for example, we also consider efforts to improve user experience through translation, testing, projects to improve documentation, meetings that get developers together in person to solve specific problems, etc. The main thing we're looking for is that your proposed project is finite (e.g. has a deadline, is scoped) and contributes to OpenITP's core mission of enabling freedom of communication on the Internet. We're interested in all good proposals, but note we're especially receptive to proposals that improve user experience (UX) and in translation (of both software and documentation). Don't take that as a filter, though: if you have a good proposal that's not about UX or translation, we still want to receive it. While our grants don't have a hard limit, they tend to be in the $5k-$30k USD range: enough to fund a specific piece of work, or to provide seed funding for a new idea, but not enough to be a primary long-term funding source. Therefore we try not to burden applicants with a lot of bureaucratic overhead and paperwork to apply for a grant. It's enough to send us a brief description of what you have in mind, and point to public URLs for further details. Since we only fund open source work, we expect that most proposals we receive will already have been discussed in publicly-archived forums anyway, and perhaps written up on a public web page -- though there may be exceptions, such as projects that are becoming open source but aren't all the way there yet. In any case, we're comfortable clicking on links and reading stuff on the Web. You're not required to package everything up in one PDF to make a proposal. Just tell us what you want to do, make it easy for us to find what we need to find, and we'll take it from there. We'll ask you questions as we have them." The page also includes examples of things OpenITP funded in their last round. Please take a look! It would be *amazing* if someone could use this opportunity to help people read and contribute to Wikimedia safely. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Re: [Wikitech-l] Lua rollout to en.wikipedia.org and a few others
by Tim Starling 19 Feb '13

19 Feb '13

On 17/02/13 00:44, Luca Martinelli wrote: > As of now, we write templates and we put data into them, article by > article - but this is going to change during 2013, with the > implementation of Wikidata, since we'll put data in the common repo > and then just call them on local projects. > > Is this new prog language going to affect this? I mean, will it help > us to write new templates which will call those data more easily? I believe that some members of the Wikidata team are interested in allowing Lua modules to fetch data directly from Wikidata. We have added a couple of hooks to Scribunto to support this, but the library hasn't been designed or implemented yet, as far as I can tell. -- Tim Starling

8 10

MediaWiki BoF at the Southern California Linux Expo this weekend
by Mark Holmquist 19 Feb '13

19 Feb '13

Hello all, I just wanted to announce that SCaLE[0] has announced their Birds of a Feather schedule[1], and there's going to be a MediaWiki-related one! I intended mostly to have it be about extensions, gadgets, and modules, but if you want to come and talk about core development you're very welcome too. The conference is being held at the LAX Hilton in Los Angeles, CA, and it's relatively affordable to come into the conference. Even more so for students, who get half off the base price. I hope you can make it! The BoF session is on Saturday at 19:00, in the "Century CD" room. (and if you're interested, I'm also hosting an Etherpad Lite BoF at 21:00 in the "Los Angeles B" room) [0] https://www.socallinuxexpo.org/scale11x [1] https://docs.google.com/spreadsheet/pub?key=0AkLumNSkddf_dHRMVnhjZmxJTWdFT0… -- Mark Holmquist Software Engineer Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

1 0

Next Bugday: Feb. 19 17:00-23:00UTC
by Valerie Juarez 19 Feb '13

19 Feb '13

Hello! Please join us on the next Wikimedia Bugday: Tuesday, February 19th, 17:00-23:00 UTC [1] in #wikimedia-dev on Freenode IRC [2] Because of the recent upgrade, we will be looking at open bugs in Git/Gerrit [3]. Our focus will be on identifying bugs that are upstream issues, so we can close the bugs that have been fixed and comment on those that need status updates. Release notes for the issues fixed in the upgrade: [4] [5] [6]. Everyone is welcome to join, and no technical knowledge needed! It's a nice and easy way to get involved in the community or to give something back. This information and more can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20130219 For more information on Triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage I look forward to seeing you there! Valerie [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat [3] https://bugzilla.wikimedia.org/buglist.cgi?list_id=179823&resolution=---&qu… 70 bugs) [4] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.… [5] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.… [6] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.…

1 1

Re: [Wikitech-l] Using wiki pages as databases
by Johnuniq 19 Feb '13

19 Feb '13

On Feb 19, 2013 at 9:11 PM, MZMcBride wrote: > https://en.wikipedia.org/wiki/Module:Convertdata I'm guilty of that, and what's been worrying me is that there are hundreds more units to add. Some guidance on using Lua as a database would be very desirable. Quick tests suggest that if {{convert}} is used 100 times on a page (where that template invokes Module:Convert, which requires Module:Convertdata), then Convertdata is loaded 100 times. I've wondered if there might be a pragma in a module like that to set "read only" (at least a promise of read only, even if it were not enforced), then more aggressively cache the bytecode so it is loaded once only per page render, or even once only until the cache memory is flushed. Or, if performance due to such module abuse is a problem, the data could be split into, say, ten modules, and the code accessing the data could work out which of the smaller data modules needed to be required. I'm not going to worry about that until I have to, but some guidance would be good. I just had a quick look at one test page which invokes the module 66 times, and the "NewPP limit report" in the html source says "Lua time usage: 0.324s" (5 ms/invoke). http://en.wikipedia.org/wiki/Template:Convert/testcases/bytype/time Johnuniq

1 0

Using wiki pages as databases
by MZMcBride 19 Feb '13

19 Feb '13

Hi. In the context of <https://bugzilla.wikimedia.org/show_bug.cgi?id=10621>, the concept of using wiki pages as databases has come up. We're already beginning to see this: * https://en.wiktionary.org/wiki/Module:languages (over 30,000 lines) * https://en.wikipedia.org/wiki/Module:Convertdata (over 7,400 lines) At large enough sizes, the in-browser syntax highlighting is currently problematic. But it's also becoming clear that the larger underlying problem is that using a single request wiki page as a database isn't really scalable or sane. (ParserFunction #switch's performance used to prohibit most ideas of using a wiki page as a database, as I understand it.) Has any thought been given to what to do about this? Will it require manually paginating the data over collections of wiki pages? Will this be something to use Wikidata for? MZMcBride

1 0

Lua rollout to en.wikipedia.org and a few others
by Rob Lanphier 19 Feb '13

19 Feb '13

Hi everyone, We're planning to deploy Lua to a long list of wikis on Monday, February 18, 23:00-01:00 UTC (stretching into Tuesday UTC), including English Wikipedia. Details here: http://meta.wikimedia.org/wiki/Lua Jan Kučera (User:Kozuch) has placed notifications on many of the wikis. Those notifications and general communications listed here: http://en.wikipedia.org/wiki/User:Kozuch/Lua This is a really exciting deployment for the projects. We're really looking forward to seeing the great things that people do with this, and looking forward to making editing and previewing more responsive for template-heavy pages. Rob

13 16

Improving object lifecycle control
by Jeroen De Dauw 18 Feb '13

18 Feb '13

Hey, A lot of components in core, for instance SpecialPages, API modules and Actions allow registering new components as follows: $someList['some-name'] = 'YourHandlingClass'; The problem with this is that the extending code has no control over the instantiation of the handling object. So you can't inject any dependencies. That is more then a little bad design wise. == Dependencies need to be pulled == Even when trying to properly design your handler, you are forced to have some static calls to obtain your dependencies (at least one if you have any dependencies) for no good reason. I don't see any way to get from under that. Furthermore this design simply encourages pulling in dependencies, so this is often done, regularly involving global state (not talking about global variables here, global state in general), thus seriously hurting the quality of the wider codebase. == Cannot register a handler with state == You are forced to create different classes while different instances of a single class might suffice. Of course that just works in some cases, often you have to give up on the proper design altogether to make it work with the static registration system. This limitation seems to encourage abuse of inheritance as well, though it's certainly not the only thing doing that, and is not the focus of this mail. Are there any ways for the mentioned components (SpecialPage, API and Action) to do have control of the lifecycle of the handling object that I am not aware of? Does anyone have plans to address these issues in our internal API, or has any work been done in this direction already? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

2 3

improving gerrit workflow
by Moritz Schubotz 18 Feb '13

18 Feb '13

Hi, in the next version of the code review system, a way to classify the type of change would be great. Maybe the trac-system would a good inspiration. i.e. a critical bug may be more important to review soon than a new feature. Furthermore running stylize.php remotely might be helpful to avoid that people waste their time with those formal aspects. Best regards physikerwelt -- Mit freundlichen Grüßen Moritz Schubotz Telefon (Büro): +49 30 314 22784 Telefon (Privat):+49 30 488 27330 E-Mail: schubotz(a)itp.physik.tu-berlin.de Web: http://www.physikerwelt.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz(a)Schubotz.de

3 2

← Newer
1
...
6
7
8
9
10
11
12
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2013