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
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
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
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
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
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
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
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.
--
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