Hi folks,
I was too tired of semi-working unstable random IRC services that
provides IRC commit messages from github to your channel, so I created
a simple plugin to wm-bot which can handle that now.
Features:
* It's incredibly easy to setup (10 seconds setup)
* Requires no registration
* Pretty stable (running on wikimedia labs)
* Self-service - everyone can configure the bot as they want directly from IRC
How it works in few steps:
1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
2) type @github+ <full name of repository> for example for repository
http://github.com/benapetr/test it would be @github+ benapetr/test
3) Add web hook in github settings of your repository to
http://wm-bot.wmflabs.org/github/index.php
That's all
Example output:
(10:41:00) <wm-bot> GitHub [benapetr/test-wm] benapetr pushed 1
commits: https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
(10:41:00) <wm-bot> GitHub [benapetr/test-wm] commit by benapetr
(Petr Bena) https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed0142…
test
Formatting kind of suck, but you can fix it! Handler is written in
PHP: https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/Git…
Hello,
We are migrating Jenkins jobs to simply invokes [test entry points] (ex:
composer test, npm test).
Some repositories have documentation generated by Jenkins and pushed
under https://doc.wikimedia.org/ . I would like to make it as trivial
as possible for developers to configure Jenkins, hence I am looking to
establish a convention to generate doc.
We would need:
- a single command we agree on (ex: make doc)
- a way to pass/override the destination directory so the jobs in
Jenkins can enforce the output where it expects it
I have filled https://phabricator.wikimedia.org/T88999 for it.
Discussions on wikitech-l preferred.
If there is no objections by next week. I will define the convention to
be 'make docs' and create all the needed Jenkins jobs templates.
Thanks!
[test entry points]
https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points
--
Antoine "hashar" Musso
It turns out we are in 2015. :D
On Tue, Feb 17, 2015 at 10:05 AM, Quim Gil <qgil(a)wikimedia.org> wrote:
> Hi, just a reminder about the deadline to submit proposals for Wikimania:
> February 28.
>
> https://wikimania2015.wikimedia.org/wiki/Submissions
>
> The Hackathon program will be more flexible in terms of deadline, process,
> etc, but if you want to have a session scheduled in the main Wikimania
> program you need to submit your proposal before the end of this month.
>
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi, just a reminder about the deadline to submit proposals for Wikimania:
February 28.
https://wikimania2015.wikimedia.org/wiki/Submissions
The Hackathon program will be more flexible in terms of deadline, process,
etc, but if you want to have a session scheduled in the main Wikimania
program you need to submit your proposal before the end of this month.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I've opened a task on Phabricator[1] to attempt to merge the information
in extension.json with Composer's
already-used-by-several-extensions-and-skins composer.json.
Kunal has rightly pointed out that composer doesn't fit some use-cases
for MediaWiki. I see that as an opportunity to be good citizens in the
larger developer community by working to integrate MediaWiki into the
growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to
develop our own HTTP client.
If composer had been available, Brion could have released the work under
includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These
routines are meant to be reusable in other projects, so I'm not
tying them to the MediaWiki utility functions.
(Of course, there was PEAR, but that is ugly and centralized in a way
that composer is not.)
Using Composer for extensions also reduces the learning curve for
developers who want to adapt their work (which may already be available
via Composer) to be used in MediaWiki. It helps us increase the size of
the available developer community without too much effort.
Footnotes:
[1] https://phabricator.wikimedia.org/T89456
--
Mark A. Hershberger
NicheWork LLC
717-271-1084
Sorry for all the trolling, but why instead of discussing how we need a
responsive skin for MediaWiki and waiting for Winter to come don't we just
do it:
* Move Minerva out of MobileFrontend
* Leave all mobile-specific improvements, "improvements" and hacks in MF
* Polish Minerva to do everythig a normal desktop skin does
* Bundle it with MW by default
----
[0] https://en.wikipedia.org/wiki/James_Randi?useskin=minerva
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hi everyone,
There has been a lot of talk over the past year or so about SOA and
what it means for MediaWiki. What I've taken from the conversation is
the following:
1. There is a general desire for us to separate user interface code
from data manipulation code. This is mainly in service of making
alternative user interfaces simpler and cleaner (e.g. mobile web,
mobile apps, print, offline). The developers that are consumers of
said systems (i.e. user interface developers) probably don't care so
much what goes on inside the data manipulation sausage factory, so
long as the APIs used to access our data are well-defined and easy to
use. It may be one data manipulation service, it may be 100 tiny
little services with a brokering layer, but as long as there's a clean
split, all is well. I've created an RFC which basically spells this
out:
https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pre…
Note that there is nothing terribly creative about this idea, and
*that is the point*. With this RFC, let's document which aspects are
utterly uncontroversial so that we can make clear the urgency to come
to consensus on more specific proposals, such as Trevor and Timo's
proposal to redo the skin system[1]
2. Within the larger data manipulation area, there is also potential
for another split between public information (e.g. pages on public
wikis, the vast majority of old revisions, etc) and private
information (e.g. pages on private wikis, revdel'ed revisions,
CheckUser information). With public information, we can choose
technologies that optimize for replication and data delivery (speed
and volume). With private information, we can lock things down more,
possibly losing efficiency in exchange for greater security. Since
private information will presumably be accessed less frequently in
most cases, and the limited cases where high frequency access is
needed (e.g. authn/authz) typically don't involve a lot of data flow,
we can generally make different design decisions. I've also created
an RFC that spells this out too:
https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pub…
These RFCs are both admittedly vague, somewhat on purpose. It's
useful to agree on a general direction before getting down in the
weeds on specific proposals. Proposal #1, other than the lack of
specificity, is hopefully completely uncontroversial, and thus (maybe
with a *little* fleshing out) could sail through the process.
Proposal #2 may be a bit more controversial, but something that is
worth some discussion.
For the specifics on these proposals, the best place to discuss these
is the talk page. If/when the conversation dies out there (or if it
never really starts), I'll summarize on this list.
If there are other sensible places for cleaner fissures in the system,
please document where you think they should go. Even if the fissures
we define are not boundaries between hardware clusters, but instead
just library boundaries, that's still useful to mark where those lines
should go.
Rob
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework
Just a quick note that I have submitted a patch
<https://gerrit.wikimedia.org/r/190819> that will make MediaWiki avoid
serving SVG images to Opera 12 (the old, Presto-based one) when a PNG
fallback is available.
We support it as a Grade A browser, which means that we should do our best
to provide the best possible experience. In my opinion, the best possible
experience involves not giving it any SVGs.
Opera 12 has issues when rendering SVG background-images together with
border-radius or background-size rules (see task
<https://phabricator.wikimedia.org/T87504> for details and examples), and
both of these are becoming increasingly common in our codebase. One common
complaint was the new MediaWiki UI checkboxes, where the check icon would
sometimes not appear for Opera users.
--
Bartosz Dziewoński
Quarterly review minutes and/or slides of the following teams have
been posted in recent days:
Multimedia:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Legal & Community Advocacy:
https://commons.wikimedia.org/wiki/File:LCA_Q2_Slides.pdf (abridged slides only)
Fundraising and Fundraising Tech:
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
Communications:
https://commons.wikimedia.org/wiki/File:Communications_WMF_Quarterly_Review…
(slides only, as a report - no actual meeting took place)
With this, documentation from all 20 quarterly review meetings that
took place about Q2 (October-December 2014) has been published.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB