Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
talked about the future of skins. Hopefully this mail summarises what
we talked about and what we agreed on. Feel free to add anything, or
ask any questions in the likely event that I've misinterpreted
something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it
currently is for developers to create a skin. The skin class involves
too many functions and does more than a skin should do e.g. manage
classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list
generator to generate things like a list of links to user tools. The
widgets will be agnostic to how they are rendered - some may use
templates, some may not.
We identified the new skin system will have two long term goals:
1) We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css
file.
2) Should be possible for us in future to re-render an entire page via
JavaScript and using the modern history push state re-render any page
via the API. (Whether we'd want to do this is another consideration
but we would like to have an architecture that is powerful enough to
support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and
has resulted in MobileFrontend rewriting it. We decided to target this
as it is a simple enough example that it doesn't need a template. It's
small and contained enough that we hope this will allow us to share
ideas and codify a lot of those. Trevor is hoping to begin working on
this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the
templating RFC [1] can get resolved however we are getting to a point
that we need one as soon as possible and do not want to be blocked by
the outcome of this RFC, especially given a mustache based templating
language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Dear all,
The Individual Engagement Grants Committee is seeking new members. We are
diverse, consensus-based committee with members on five continents and a
variety of skills. As a group we speak 16 languages and have over 500,000
edits to a variety of Wikimedia sites. We review grant applications twice
per year in four categories: Research, Tools (usually software), Online
community organizing, and Offline outreach and partnerships.
Members may specialize in as few or as many areas as they wish.
We look for the following qualifications. This information is taken from
our Meta page.
Mandatory:
1. Experience with the Wikimedia movement and at least one Wikimedia
project
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_projects>.
2. Experience with some aspect of Wikimedia programmatic or
project-based work, e.g. editor engagement, WikiProjects or other on-wiki
organizing processes, outreach, events, partnerships, research, education,
gadget or bot-building, etc.
3. Ability to edit basic wiki-markup (grant proposal discussions are
largely conducted on meta-wiki).
4. Reasonable facility with English, for reviewing and discussing grant
proposals.
5. In good community- and legal- standing (not currently blocked or
banned, involved in allegations of unethical financial behavior, etc).
6. Availability to actively engage in the selection process during the
published schedule for that round (time commitment is about 3 hours per
week, plus 1 extra day for scoring).
Preferable:
1. Experience leading, coordinating, or managing projects with an
intended on-wiki or online impact.
2. Experience handling externally provided money and working within
budgets, preferably in a non-profit context.
3. Experience applying for grants or working in grants programs (in the
Wikimedia, academic, or wider non-profit world).
4. Ability to read and write in multiple languages.
Acceptable:
1. Members may apply for an Individual Engagement Grant themselves, but
they will recuse themselves from reviewing proposals in the same category
as their own during that round.
2. Membership does not conflict with membership in other Wikimedia
committees, including the Grant Advisory Committee
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Grants:PEG/Grant_Advisor…>
or the Wikimania Scholarships Committee.
Please apply at
https://meta.wikimedia.org/wiki/Grants:IEG/Committee#ieg-candidates. The
close of the application period is September 21. The Committee will review
the applications internally and announce new members by early October,
coinciding with the start of the public review period for new grant
proposals.
For the Committee,
Pine
Hi all.
I'm including some thoughts on Echo below.
- *it* *doesn't* *scale* (constantly seeing a "(3)" or new emails pop up if you're active in ~6 discussions is a pain)
- _nothing_ on-wiki ever warrants an urgent reaction ever
- distracting, especially as I'm getting more active with talking
- this last point caused me to switch it off entirely everywhere
- I'm reading an article to get more information and this piece of software drags me back into editing while I'm merely reading something and intend to return to the watchlist in the evening
- Echo a consequence of newcomers being insufficiently communicated to (i.e. too few helpers involved talking with newcomers at big wikis, let's automate that - NO! THAT's STUPID! have it semi-automated -- the entire wiki software should be centered around a big edit box and a less prominent, but comfortable, box for leaving custom messages to articles and users talk pages)
- Echo is a consequence of a watchlist page which many people find insufficiently informative, intuitive, or easy to control.
- special:watchlist and special:notifications overlap in functionality
- the 'notifications' tab lacks a 'watchlist' column so that I can choose where events go (email, echo's nagging, or watchlist passively)
- the extra term ('notifications') is clutter
- please consider improving usability of the watchlist and integrating any echo fields into it
- and make watchlist easier to manage
- integrate these two tools together
- echo is really conceptually merely a new channel where to pipe watchlist items
- simplicity is the key to success
svetlana
--
(original rant attached for reference)
Dunno. I'm pissed by Echo.
Hundreds of hours of time wasted looking at a reply at a talk page or at an edit someone thanked me for.
Which are not urgent at all. Yet the software notified me of them real-time.
Echo is a consequence of newcomers being insufficiently communicated to (i.e. too few helpers involved talking with newcomers at big wikis).
Also, a consequence of a watchlist page which many people find insufficiently informative, intuitive, or easy to control.
----
looking at Echo's 'thanks' notifications for a few months before figuring out that it's possible to disable that
like I'm reading a page about electrons on-wiki and doing something of interest to me, it pops up with its number [1]
I have to go and watch it despite knowing it clearly that _nothing_ on-wiki ever needs an urgent reaction
about couple minutes on that daily.. clearly doesn't encourage me to talk more with people
if you sum that up, it's a few tens or hundreds of hours of time wasted this year
I'm supposed to concentrate and all those notifications are distracting -- I know where I am, I don't need them
I became remotely active at mediawiki or meta and started getting these notifications non-stop. Frick off. This doesn't scale.
does this explain the source of trouble? :-)
----
well, I ticked off everything 'web', this set it to 0 for now, but I wouldn't like to see it at all since it's bearing no extra information
and people who are not sitting in a cave will find that *it* *simply* *doesn't* *scale*
anyone active in ~6 discussions will find it a source of nag
----
I wouldn't like it to go forward really -- improve the watchlist instead and make it more useable please :)
spending time on a means to thank a user via software, or to ask him a 'mention' at a discussion, doesn't look very productive to me -- this all can be put into watchlist nicely
it doesn't need to be an extension, it needs to be an improvement in the core
what to do with watchlist -- web notify thru echo, or email, or nothing and just have me peek at it in the evening
extra concept 'echo', 'notification' is extra clutter
nobody needs it, both these lists should be configurable in one tab of prefs
add a 'watchlist' column to the 'notifications' tab -- so that I can tell whether I'd like to see thanks piped over to my watchlist
etc
I can see simplicity as a path to success
reword things a little, name it 'watchlist notifications', make it more flexible and make it pipe things over to a single special page instead of 2 special pages
this special page should remain as compact as a watchlist is -- the design of the current 'special:notifications' page is not at all good on a 600x800 screen
managing watchlist is hard, fixing that is long overdue
I'd _really_ like to see echo and watchlist back together in a simple intuitive system
TL;DR: Please review [1]
I was asked to discuss the topic on the mailing list, so here goes.
Since some time Siebrand is making an effort to improve code quality by
making it phpcs-strict compliant [0]. This involves explicitly declaring
the visibility of class members.
Alas, intended or not, in very many cases he did not only explicitly
declare the class variable's visibility, but he also changed it from the
implicit 'public' to explicit 'protected' or 'private', thus introducing
a major API change without a proper deprecation period. Apparently this
was not noticed (or at least not challenged) by the reviewers. I checked
a few of his commits and they were all merged within hours.
Now, to be clear about that, I appreciate both changes - the phpcs
compliance as well as the more limited accessibility of class variables.
This was long overdue. However, to introduce something like this a
proper deprecation period is in my opinion essential, in particular
considering the extent of the changes. I do believe that Siebrand
checked that the variables he declared protected or private were not
used by extensions. However, he missed one (EditPage::mTokenOk) which
subsequently resulted in a bug in an extension (SemanticForms). Given
the number of the now newly hidden variables I am quite sure, that there
are other cases. If only because many extensions are not hosted on WMF
servers, so they can not be checked.
To keep the changes and still be able to properly deprecate the direct
access to the member variables I submitted a patch [1] that makes use of
PHP magic functions [2]. They provide access to the class members and
issue a deprecation warning. The intention is to keep these functions
for the custom two releases [3], i.e. until 1.26, and then remove them.
This patch was shot down for three reasons:
<quote>
* it duplicates code
* there is no tests
* our code base barely use the magic methods and I am pretty sure Tim
Starling commented a while back about them being nasty.
</quote>
When I pointed out, that these functions are not re-entrant and thus
Tims warning [4] did not apply the answer was "I have merely copy pasted
Tim comment without even attempting to understand what it means". I was
subsequently asked to present this to the mailing list which I do with
this mail.
I would appreciate comments on the patch (preferably constructive), that
would allow us to not revert Siebrand's changes and still properly
deprecate formerly public class members.
Thanks.
Stephan
[0]
https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+bra…
[1] https://gerrit.wikimedia.org/r/#/c/151370/
[2]
http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overlo…
[3] https://www.mediawiki.org/wiki/Deprecation
[4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504
[x-posted]
Hello,
The next monthly IRC office hour of the Wikimedia Language Engineering
team will be on Wednesday, September 10, 2014 at 1700 UTC on
#wikimedia-office.
We will be taking questions and discussing about our ongoing work,
particularly around the Content Translation project[1], and upcoming
plans.
Please see below for event details and local time. See you there.
Thanks
Runa
[1] https://www.mediawiki.org/wiki/Content_translation
Monthly IRC Office Hour:
===================
# Date: September 10, 2014 (Wednesday)
# Time: 1700 UTC/1000PDT (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140910T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Content Translation project updates and plans
2. Q & A (Questions can be sent to me ahead of the event)
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
All users at fab.wmflabs.org have received this announcement. Forwarding it
here just in case.
---------- Forwarded message ----------
From: <PhabAnnounce(a)phabricator.wikimedia.org>
Date: Sunday, September 7, 2014
Subject: fab.wmflabs.org to go offline this Monday 18:00UTC
To: qgil(a)wikimedia.org
Summary: fab.wmflabs.org will be taken down this Monday 18:00UTC. Locally
save tasks or workboards that you might rely on for the week. Verify your
email address in fab.wmflabs.org if it's not already. The intention is for
the Phabricator production instance to be available by Sept 12th.
The Phabricator instance on fab.wmflabs.org has been used over the last few
months for both real and test data. On Mon, Sept 8th 2014 18:00UTC this
instance will be made unavailable to migrate content to the upcoming
production instance on phabricator.wikimedia.org. The Labs instance will
not come back online in the same form, if at all.
We take the Labs instance down because we cannot make the Labs instance
read-only while dumping its data. Neither can we easily display a banner on
all pages warning you to not make any changes which would get lost anyway.
Tickets from the following projects are marked for migration:
Analytics-EEVS
Architecture
bugzilla-migration
Chemical_Markup_for_Wikimedia_Commons
Code_review_in_Phabricator
Community-Engagement
dev.wikimedia.org
googlelogin
Growth
Human_Resources
Language_Engineering
logstash
phabricator
phabricator-request-project
Release_Engineering
rt-migration
Triagers
Trusted_User_Tool
UI_Standardization
UploadWizard_Refactoring
Upstreaming_to_Phabricator.org
Wiki-Release-Team
Wikimedia_Phabricator_Day_1
wikimedia_phabricator_maintenance
wikimedia_phabricator_rfc
Some metadata[1] for tasks associated with the above should be populated in
the new production system -- if the account used in fab.wmflabs.org has a
verified email that is also verified in the production instance. If you are
using an email
but have not verified it to the Labs instance you can go here:
http://fab.wmflabs.org/settings/panel/email/ and choose "verify". An email
will be sent with a link.
If you do not have a verified email address yet, or for some reason cannot
verify an email
with the Labs instance the relevant content (tickets, comments) will still
be
migrated. However, it will not be associated automatically with any new
account in
the production instance.
For questions catch us (chasemp and andre__) on Freenode IRC or drop into
the #wikimedia-devtools channel.
Thanks,
Phabricator Team
[1] metadata to be migrated: ticket: author, cc, assigned, blocking/blocked
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014 states
"project wrap-up post by 20 August" but I see very few.* Is it my
responsibility as mentor to remind/harass my student about it, or was
that already done by the admins? Thanks.
Nemo
(*) On the other hand I don't even know which projects were
completed/passed. The official answer by Google is that
http://www.google-melange.com/gsoc/events/google/gsoc2014 knows it all,
but I don't see explicit pass/fail information there.
The date comes from the git information, if there is no .git in the installation, then no date :) So tarballs don't have some iirc.
Gesendet mit meinem HTC
----- Reply message -----
Von: "Isarra Yos" <zhorishna(a)gmail.com>
An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Betreff: [Wikitech-l] Add release to special version page
Datum: Sa., Sep. 6, 2014 08:50
On 06/09/14 06:42, Chad wrote:
> Don't we already pull the date from git if it exists?
>
> http://en.wikipedia.org/wiki/Special:Version says yes.
>
> -Chad
Oh neat, is that new? Or am I just that unobservant? Well, nevermind, then.
What about the tarball ones, though? Do those do it? Seriously, I
haven't used a tarball in... quite awhile.
-I
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l