The application deadline for GSoC and FOSS OPW has passed. The pool of
candidates to choose from includes
* 43 GSoC proposals from 42 candidates
* 18 OPW proposals from 18 candidates, one of them a GSoC candidate as well
There are many projects that have received several proposals. In a few
hours the dust will settle in the wiki pages, where many candidates are
currently syncing their information.
https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8
Everybody is invited to join the selection process.
https://www.mediawiki.org/wiki/Mentorship_programs/Selection_process
All mentors must join the GSoC or OPW review websites in order to join the
private evaluation of candidates. The rest of the community is encouraged
to help reviewing proposals and asking hard questions to candidates and
mentors in their respective talk pages or Bugzilla reports.
By April 7 we need to decide how many slots we want to request in each
program. In GSoC we request a number of slots to Google, which we might or
might not get. In OPW we fund some slots, we might request more, and then
we might get them or not.
Questions? Just ask.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
As a complement to the upcoming Project Management Tools RfC --
https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tool…...
If Phabricator would substitute our current collaboration tools tomorrow,
what would you miss?
Please reply in the appropriate Phabricator tasks (here is also fine, we
just want to have the feedback in one place). If you are not sure whether
feature X is supported, under development, roadmapped... just ask. Let's
create new subtasks for features considered blockers.
Mingle
http://fab.wmflabs.org/T44
Trello
http://fab.wmflabs.org/T45
Bugzilla
http://fab.wmflabs.org/T46
Gerrit
http://fab.wmflabs.org/T47
Missing one tool? Just create the task.
I took the liberty of assigning each task to someone relevant to the topic.
Feel free to take them or leave them. If you are simply interested,
"subscribe".
All these URLs should be visible to anonymous users, otherwise please
report.
PS: if you are curious about how a migration to Phabricator would look
like, you can get an idea at http://fab.wmflabs.org/project/board/14/
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi everyone
I'm pleased to announce that Aaron Schulz is taking on a new role in
Wikimedia Foundation's Platform Team: Senior Performance Engineer.
Aaron works on MediaWiki internals -- components that every
user-visible feature depends on, but which are rarely user-visible
themselves. The impact of Aaron's work on the reliability and
performance of MediaWiki is felt by many, but fully known to few, so
I'd like to use this occasion to highlight some of this work.
Aaron is the primary author of MediaWiki's file handling backend, job
queue, its integration with Redis key-value database and the
OpenStack's Swift distributed filesystem -- just to name a few of the
more significant (and relatively recent) components. In addition to
these things, Aaron has designed a heavily-used set of generic
mechanisms for enabling concurrent access to shared resources, for
breaking up big computations into smaller units of work, and for
distributing those units of work across a cluster of machines that can
execute it. Aaron's code plays an important supporting role in most
(if not all) significant MediaWiki functionality.
Aaron's move to performance recognizes the critical role he has
already played in this area, and reflects our evolving understanding
of how important that work is. We are constantly striving to make the
experience of using MediaWiki snappy so that editors can do their work
without waiting on the software to acknowledge their actions. To meet
these standards, we need to tackle performance in (at least) two
areas:
1. Using data to provide a picture of how users experience the site,
identifying where users encounter latency, quantifying how it impacts
their engagement, and using this information to drive optimizations to
the code, paying particular attention to client-side network and
computational load. In making this a focal point, we are heeding Steve
Souders' Performance Golden Rule: "80-90% of the end-user response
time is spent on the frontend. Start there." [1] Our goal here is to
ensure that the visual display of information and the reactivity of
the user interface exhibit the kind of immediacy that is needed for
users to focus on and engage with content.
2. Building a well-integrated set of services that, when used in the
most obvious way, allows it to do as many things as possible, as fast
as possible, while remaining resilient to changes in site activity.
The vast majority of visits to our site never reach the backend of our
stack, but the minority that do involve really critical site
functions, such as all editor activity. We want the MediaWiki
ecosystem to have not only the capacity to sustain current levels of
activity, but to be an enabler of growth by making it possible for
many more people to contribute in new ways. To meet this challenge, we
need MediaWiki to be increasingly parallel, and to provide efficient,
concurrent access to a rich variety of content types and storage
layers.
This split maps neatly to Ori and Aaron's respective skill-sets and
experience, which makes for an effective partnership. Having Aaron
formally move to a performance role both recognizes the work Aaron is
already doing, and it lays the groundwork for a process for meeting
performance challenges that leverages their diversity of expertise.
Please join me in thanking Aaron for taking on this role!
Rob
[1] Steve Souders is formerly Head Performance Engineer at Google and
"Chief Performance Yahoo!" at Yahoo. Performance Golden Rule:
http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
Hi,
Sumana pinged me about this RFC but considering other things I am
working on that have a high priority, I'm unlikely to work on this in
the near future. If anyone is interested in picking it up, feel free to
do so.
https://www.mediawiki.org/wiki/Requests_for_comment/Scoping_site_CSS
--
Juliusz
On Wed, Mar 26, 2014 at 9:56 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> I agree Max, that would be a great patch to get finish.
>
> Pulling in wikitech for wider discussion since it seems Timo wanted a
> wider discussion.
>
> tldr: Let's add a method of template/blob delivery into ResourceLoader
> from server->client which is agnostic of which template library is
> being used and allows Flow and MobileFrontend to share code rather
> than running their own identical systems in 2 separate extensions.
>
>
> On Tue, Mar 25, 2014 at 6:01 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
>> On 26.03.2014, 3:37 Jon wrote:
>>
>>> Gabriel's work is on a standard templating choice for all projects.
>>> ResourceLoader support will inevitably be needed for that too. We
>>> believe that upstreaming this code and making it agnostic to the
>>> template language (which it will have to be if Flow is using
>>> Handlebars in the meantime) will lead to a good generic piece of code
>>> that Knockoff can be easily plugged into in future.
>>
>> I already experimented in this area: https://gerrit.wikimedia.org/r/111250
>> would be great if we finished this...
>>
>> --
>> Best regards,
>> Max Semenik ([[User:MaxSem]])
>>
I want to ask wikimedia , about the .wiki tld. I am AN IT expert and I
was going to register science.wiiki (example) in epa ( early phase
access) which will be in may for my firm.
I was surprised to find that it was already registered by Top Level Design.
Visit: http://whois.domaintools.com/science.wiki.
Your all domains like media.wiki , books.wiki etc are registered.
http://whois.domaintools.com/books.wiki
I want to know that "wiki" means collaborative web you have the
trademark on the tld or not.
TOP LEVEL DESIGN, LLC is a miscellaneous company. Why a registrar
will register all premium domains.
I have requested my client to ignore .wiki tld.
What will be your action?
Best Regards,
V.P. Singh
MediaWiki developers:
http://www.php.net/archive/2014.php#id2014-04-02-1 (02 Apr 2014):
The PHP development team announces the immediate availability of PHP
5.5.11.
Several bugs were fixed in this release, some bundled libraries updated
and a security issue has been fixed :
CVE-2013-7345. We recommend all PHP 5.5 users to upgrade to this version.