Hi, I have proposed a list of seven Wikimedia Hackathon 2015 projects that
should be supported further:
https://phabricator.wikimedia.org/T101151
Anybody can help improving this list; this is not some sort of Academy
Awards.
How to support these projects? Everything goes down to follow, comment, and
contribute. Wikimania's hackathon is a good next step for those projects
having the right people at the event. Also, everybody at the Wikimedia
Foundation is defining quarterly team and individual goals, so you might
want to consider to set a goal related to one of these projects.
Once the Wikimania & WMF goals dust settles, we will check how each project
is doing and what are the appropriate next steps.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello wikitech-l,
We will be doing a test run of lightning talks on June 23.
~ Details are below ~
If you would like to do a lightning talk yourself on whatever project you
are working on please feel free to add yourself - also please add contact
information (or email it to me) so we can coordinate with you to make sure
and get you on the hangout in advance to be able to present.
If you watch the lightning talks and appreciate them please let us know and
will enough interest and content we will continue to do them in the future.
A youtube stream will be sent out to this list just before the talks start
so you can join in and ask questions, and the talks will also be recorded
so that you can watch them whenever you like.
These lightning talks should be relevant to something related to our
movement and will mostly be focused on tech related projects however some
may be unrelated to tech.
We will adapt this process as we go to make it as interesting and useful to
everyone as we can.
Rachel
---------- Forwarded message ----------
From: Kevin Leduc <kevin(a)wikimedia.org>
Date: Mon, Jun 15, 2015 at 3:44 PM
Subject: Lightning Talks June 23
To: wmfall(a)lists.wikimedia.org, Engineering list <
engineering(a)lists.wikimedia.org>
Cc: Rachel Farrand <rfarrand(a)wikimedia.org>, Megan Neisler <
mneisler(a)wikimedia.org>
Hello!
Due to high demand, we are starting up Lightning Talks again! This effort
will not work without your participation...
Lightning Talks are an opportunity for teams @ WMF to showcase a milestone,
exciting developments, releases, or anything of significance to the rest of
the foundation and the movement as a whole, as these talks will be open to
our communities.
Each presentation will be 10 minutes or less, the formal part should be not
be longer than 5 minutes and the remainder can be used for questions.
Too many questions to answer in the allotted time? No worries, your
lightning talk will be a great candidate for a future Tech Talk.
First Round of Lightning Talks:
When: Tuesday June 23, 1800 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Lighting+Talks%2C+…>,
11am PDT
Where: 5th Floor
Remotees: On-Air google hangout will be provided just before the meeting
IRC: #wikimedia-tech
Sign up for a 10 minute slot here:
https://www.mediawiki.org/wiki/Lightning_Talks
With interest, this meeting will become a monthly event.
Thanks!
Kevin Leduc, Rachel Farrand, Megan Neisler
Hello everyone,
there will be a leap second on June 30th 23:59:60 UTC (
https://en.wikipedia.org/wiki/Leap_second) The adjustment of the leap
second is normally handled as part of the NTP time synchonisation protocol
(which all our hosts run): On the day of a leap second, NTP notifies the
Linux kernel about the leap second and the kernel adds it after 23:59:59.
(The insertion of the kernel flag that the day has a leap second happens
well before 23:59:59, specifically at 00:00:00 of the same day.)
The last time a leap second was added, happened in 2012: Bugs in the Linux
kernel and Java caused problems on a number of services (especially Search
and LDAP). The underlying bugs in the Linux kernel and OpenJDK have been
fixed and the updates are present across all systems, but due to leap
seconds only occurring every few years, we might encounter totally new bugs
when the leap second is added at midnight. (We made sure that the existing
kernel bug from 2012 is fixed using test cases). There might also be
problems in applications or language interpreters which bail on the
existence of a 23:59:60 time.
As such, we've decided to follow a safe approach, outlined below:
* NTP will be disabled on the 29th for most systems in production. We'll
keep a few non-critical systems on the default behaviour/NTP, with the
intent of gathering data/experiences for future leap seconds, without
however compomising the stability of the infrastructure. The other systems
will run on hardware-clock starting then. The hardware clocks shouldn't
deviate significantly over the approx. two day period, but if you're
concerned that a service will cause problems w/o clocks being precisely in
sync, please get in touch with ops@. Do note that deviations should be in
the order of milliseconds.
* Most systems in Labs will also get NTP disabled.
* Our NTP servers will keep synching with their upstream peers.
* On the 1st of July we'll re-enable NTP in batches. System clocks will
move forward by a second once NTP is started again, but acting on normal
clock changes should be something every application gets along with just
fine.
Alexandros / Moritz
Hi,
Krinkle wanted to use BotBot.me log viewer as a frontend for wm-bot's
logs. It unfortunatelly uses slightly different database schemas, but
I managed to create some views in wm-bot's db that actually produces
similar columns and behold! It works:
http://botbot.wmflabs.org/freenode/15/
Well, to a point. Some features do not work yet, such as searching,
but I will look into it. Let me know if anything didn't work as
expected! Also, don't even bother unchecking hide join / part it will
not work. wm-bot stores irc commands as numerics while BotBot uses
text column here. I can create some procedure in SQL to convert this,
but it wouldn't work with indexes and that would totally kill the
performance of log viewer, so I am afraid these won't be available for
a while.
Have fun
Dear Smriti,
Thanks for raising the point about easy tags.
I am guilty as charged.
Once a year I (wpmirrordev) file a large number of tasks.
Most of them involve changing file permissions.
I have now marked these tasks as easy.
These tasks are appropriate for a first-time contributor.
They would give you a reason to wander through the directory tree
of core/, skins/, and extensions/ and learn where everything lives.
Sincerely Yours,
Kent
> Thank you so much Andre and Tony! :D
> As for what I am interested in, as long as it is not python and does not
> have the design tag, I would love to work on it. With the links now though,
> bugs that interest me will be much easier to find :)
> Thank you for addressing this. Seeing more easy tags makes it easier for
> new developers like myself to contribute actively :)
> -Smriti (Galorefitz)
Updated URLs, we're in R37
on air stream: http://youtu.be/RcE2kecrsIk
Max of 15 users:
https://plus.google.com/hangouts/_/hoaevent/AP36tYdub-Rs4mI_4UjTEzTgU7GKBkg…
On Tue, Jun 23, 2015 at 12:18 PM, Vibha Bamba <vbamba(a)wikimedia.org> wrote:
> This sounds fairly dev centric with Front end/ UX implications.
> Will the discussion be fairly technical? Let us know if Design should
> attend.
>
> ----
> Vibha Bamba
> Senior Designer | WMF Design
>
>
>
>
>
>
>
> On Tue, Jun 23, 2015 at 11:12 AM, Gabriel Wicke <gwicke(a)wikimedia.org>
> wrote:
>
>> Reminder: This is today!
>>
>> When: *Tuesday, June 23rd, 13:00 - 14:30 PT* [3]
>> Where:
>> * *https://plus.google.com/hangouts/_/wikimedia.org/contentplatform
>> <https://plus.google.com/hangouts/_/wikimedia.org/contentplatform>*
>> * *room 37* in the office
>>
>> On Fri, Jun 19, 2015 at 12:00 PM, Gabriel Wicke <gwicke(a)wikimedia.org>
>> wrote:
>>
>>> Hi all,
>>>
>>> a few of us have recently collected and roughly prioritized some open
>>> architectural questions [1]. The area that stood out as needing most urgent
>>> attention is adapting our content platform to long-term changes in the way
>>> users interact with our site [2]. People are using a wider range of
>>> devices, from feature phones to multi-core desktops. Many users are looking
>>> for short factoids and definitions, while others prefer to immerse
>>> themselves in detailed articles with rich multimedia content.
>>>
>>> MediaWiki is currently not very optimized to support such a diverse set
>>> of use cases. To address this, we see a need to improve our platform in the
>>> following areas:
>>>
>>>
>>> - Storage: To better separate data from presentation, we need the
>>> ability to store multiple bits of content and metadata associated with each
>>> revision. This storage needs to integrate well with edits, history views,
>>> and other features, and should be exposed via a high-performance API.
>>> - Change propagation: Edits to small bits of data need to be
>>> reliably and efficiently propagated to all content depending on it. The
>>> machinery needed to track dependencies should be easy to use.
>>> - Content composition and caching: Separate data gives us the
>>> freedom to render infoboxes, graphs or multimedia elements dynamically,
>>> depending on use case and client. For performance and flexibility, it would
>>> be desirable to assemble at least some of these renders as late as
>>> possible, at the edge or on the client.
>>>
>>>
>>> We don't expect to tackle all of this at once, but are starting to look
>>> into several areas. If you are interested in helping, then we would like to
>>> invite you to join us for a kick-off meeting:
>>>
>>> *When: Tuesday, June 23rd, 13:00 - 14:30 PT [3]*
>>> *Where: *A *hangout* link will be posted here before the meeting; room
>>> 37 in the office.
>>>
>>> If you can't attend, then please have a look at our current notes and
>>> let us know what you think [2].
>>>
>>> Gabriel Wicke, Daniel Kinzler, Brion Vibber, Tim Starling, Roan Kattouw,
>>> Ori Livneh
>>>
>>>
>>> [1]: https://phabricator.wikimedia.org/T96903
>>> [2]: https://phabricator.wikimedia.org/T99088
>>> [3]:
>>> http://www.timeanddate.com/worldclock/fixedtime.html?msg=MediaWiki+content+…
>>>
>>
>>
>>
>> --
>> Gabriel Wicke
>> Principal Engineer, Wikimedia Foundation
>>
>> _______________________________________________
>> Engineering mailing list
>> Engineering(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/engineering
>>
>>
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
remove my email I've requested this multiple times.
lora
On Jun 25, 2015 8:02 AM, <wikitech-l-request(a)lists.wikimedia.org> wrote:
>
> Send Wikitech-l mailing list submissions to
> wikitech-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
> 1. "Architecture meeting 2015" summary (Matthew Flaschen)
> 2. Barry the browser bot (Jon Robson)
> 3. Re: [Engineering] Modernizing our content platform: Kick-off
> meeting on Tuesday (S Page)
> 4. Re: "Architecture meeting 2015" summary (MZMcBride)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Jun 2015 18:39:16 -0400
> From: Matthew Flaschen <mflaschen(a)wikimedia.org>
> To: EE List <ee(a)lists.wikimedia.org>, Wikitech
> <wikitech-l(a)lists.wikimedia.org>
> Subject: [Wikitech-l] "Architecture meeting 2015" summary
> Message-ID: <558B3194.7020302(a)wikimedia.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Today's RFC meeting was regarding general priorities for the coming
> months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
>
> One of the key issues discussed was the idea of widgets, which is a new
> approach to representing and editing bundles of content (such as an
> infobox or a graph).
>
> We also talked about canonical formats, and whether content should be
> stored in wikitext and extracted out (like a more sophisticated version
> of https://www.mediawiki.org/wiki/Extension:TextExtracts), or stored
> elsewhere (e.g. Wikidata) and assembled. Gabriel Wicke noted the
> importance of minimizing disruption for existing editors and tools, and
> Bryan Davis suggested this could limit the flexibility editors now have.
> This led us to discuss further what areas likely made sense to be
> generated. I.E. graphs and data tables, probably not prose (but Daniel
> Kinzler suggested possibly auto-generating prose if there was no
> human-written prose).
>
> We talked about some approaches to backend storage. Timo Tijhof
> suggested allowing a page to be built from multiple blobs that reference
> each other.
>
> We talked about some approaches to widgets like infoboxes and inline
> editing of templates more generally.
>
> We also talked about testing coverage and code architecture guidelines.
>
> Daniel Kinzler plans to update the document in response to feedback.
>
> Matt Flaschen
>
> ---
>
> Minutes at
>
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
>
> Log at
>
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Jun 2015 16:55:59 -0700
> From: Jon Robson <jrobson(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Internal
> communication for WMF Reading team <
reading-wmf(a)lists.wikimedia.org>,
> mobile-l <mobile-l(a)lists.wikimedia.org>, "QA (software
quality
> assurance) for Wikimedia projects." <qa(a)lists.wikimedia.org>
> Subject: [Wikitech-l] Barry the browser bot
> Message-ID:
> <CALMndh=a-2PEAi+xENcNNCVG42yv4ZLPaCo0oDrt5qek8ww=
tg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Some of you may have noticed a bot [1] providing reviews for the
> Mobilefrontend and Gather extensions.
>
> This is a grass routes experiment [2] to see if we can reduce
> regressions by running browser tests against every single commit. It's
> very crude, and we're going to have to maintain it but we see this as
> a crude stop gap solution until we get gerrit-bot taking care of this
> for us.
>
> Obviously we want to do this for all extensions but we wanted to get
> something good enough that is not scaleable to start exploring this.
>
> So far it has caught various bugs for us and our browser test builds
> are starting to finally becoming consistently green, a few beta labs
> flakes aside [3].
>
> Running tests on beta labs is still useful but now we can use it to
> identify tests caused by other extensions. We were finding too often
> our tests were failing due to us neglecting them.
>
> In case others are interested in how this is working and want to set
> one up themselves I've documented this here:
> https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot
>
> Please let me now if you have any questions and feel free to edit and
> improve this page. If you want to jump into the code that's doing this
> and know Python check out:
> https://github.com/jdlrobson/Barry-the-Browser-Test-Bot
> (Patches welcomed and apologies in advance for the code)
>
> [1]
https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c…
> [2] https://phabricator.wikimedia.org/T100293
> [3]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 24 Jun 2015 17:19:13 -0700
> From: S Page <spage(a)wikimedia.org>
> To: Dan Garry <dgarry(a)wikimedia.org>
> Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>,
Development
> and Operations Engineers <engineering(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] [Engineering] Modernizing our content
> platform: Kick-off meeting on Tuesday
> Message-ID:
> <CAJg1jJVrs8BM5w-z=9+eQO6cwpNvXU=
td6j0cZ2WFTvw0-7meA(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Jun 23, 2015 at 10:01 PM, Dan Garry <dgarry(a)wikimedia.org> wrote:
>
> > My takeaway from this was that there are strong arguments both for and
> > against keeping the representation of an article as a single blob of
> > wikitext/HTML.
> >
>
> In the Architecture focus discussion, Krinkle, tgr, and others expressed a
> more optimistic idea, that the wikitext of an article is "a sea of prose
> with isles of non-prose content, which could come from structured data"
[1].
>
> I wasn't properly aware that the <graph> [2] and <templatedata> [3] parser
> tags are examples of this already. Their content is highly structured and
> VisualEditor or dedicated code can provide a specialized editor for it. If
> you edit source of a wiki page containing them and garble their content,
> you get a syntax warning or fail.
>
> Wiki pages need more of these, <drumroll> Structure Content Blobs™ (or
> sPage Components? anything but "widget"). Are they necessarily parser
tags,
> or is a parser function like {{#graph: *some parameters*}} equivalent?
>
> To be concrete, does this mean the way forward for specifying lead images
> [5] is a parser tag
> <leadimage>{
> "imagepage": "File:Einstein_1921_by_F_Schmutzer_-_restoration.jpg",
> "focalarea": {"rect": [0.20, 0.20, 0.12, 0.12]}
> }
> </leadimage>
> in wikitext, with a MediaWiki API to add this to a document and a WYSIWYG
> property editor in VisualEditor for humans?
>
> AIUI, the *Architecture focus 2015* document discusses this under
> "Generalized transclusion" [4] and comments:
> Over the next months, the MediaWiki developer community and staff should
> investigate how the different transclusion mechanism used with wikitext
> content can be unified and extended to work with non-wikitext content.
>
> Exciting stuff.
>
> [1]
>
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
> starting at 21:21:05
> [2] e.g.
https://www.mediawiki.org/wiki/Extension:Graph/Demo/Map?action=edit
> [3] e.g. https://www.mediawiki.org/wiki/Template:Phabricator?action=edit
> [4]
>
https://www.mediawiki.org/wiki/Architecture_focus_2015#General_architectura…
> [5] https://phabricator.wikimedia.org/T91683
>
> --
> =S Page WMF Tech writer
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 25 Jun 2015 00:00:05 -0400
> From: MZMcBride <z(a)mzmcbride.com>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] "Architecture meeting 2015" summary
> Message-ID: <D1B0F350.93021%z(a)mzmcbride.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Matthew Flaschen wrote:
> >Today's RFC meeting was regarding general priorities for the coming
> >months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
> >
> >[...]
> >
> >Daniel Kinzler plans to update the document in response to feedback.
>
> I just wanted to say thank you to you and to Dan for these recent e-mails
> summarizing larger technical discussions. :-) While I appreciate the
> value of synchronous chats, supporting asynchronous communication is also
> important and these notes are very helpful in understanding, at a high
> level, what's being discussed and why. They also help ensure that everyone
> is aligned and informed and they make jumping into the discussions easier.
>
> MZMcBride
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> End of Wikitech-l Digest, Vol 143, Issue 48
> *******************************************
Today's RFC meeting was regarding general priorities for the coming
months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
One of the key issues discussed was the idea of widgets, which is a new
approach to representing and editing bundles of content (such as an
infobox or a graph).
We also talked about canonical formats, and whether content should be
stored in wikitext and extracted out (like a more sophisticated version
of https://www.mediawiki.org/wiki/Extension:TextExtracts), or stored
elsewhere (e.g. Wikidata) and assembled. Gabriel Wicke noted the
importance of minimizing disruption for existing editors and tools, and
Bryan Davis suggested this could limit the flexibility editors now have.
This led us to discuss further what areas likely made sense to be
generated. I.E. graphs and data tables, probably not prose (but Daniel
Kinzler suggested possibly auto-generating prose if there was no
human-written prose).
We talked about some approaches to backend storage. Timo Tijhof
suggested allowing a page to be built from multiple blobs that reference
each other.
We talked about some approaches to widgets like infoboxes and inline
editing of templates more generally.
We also talked about testing coverage and code architecture guidelines.
Daniel Kinzler plans to update the document in response to feedback.
Matt Flaschen
---
Minutes at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Log at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Hey!!
The "Easy" tag is becoming rarer and rarer as new tasks are coming in. This
would make it pretty difficult for new developers like myself to sort
through tasks to look for ones we can do. Could the community come up with
something for this? It would be great if people could start adding an
"Easy" tag if they think a task they come across is in fact an easy one :)
-Smriti (Galorefitz)