Hola,
if you have found yourself clicking the "History" link in Bugzilla
tickets way too often (to check who has set the Priority, or who has
changed the assignee and when), Bugzilla now has an opt-in to display
such metadata changes inline, between the comments of the bug report.
You can enable this by going to
https://bugzilla.wikimedia.org/userprefs.cgi?tab=settings
and setting "When viewing a bug, show all bug activity" to "On".
Cheers,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi all,
Due partly to the recent sparseness of traffic in #wikimedia-office, I've
scheduled an office hour [0] for the new BetaFeatures extension, which
the WMF is hoping to use for launching new features for beta testing.
This will primarily be a technical discussion focused on people who may
want to use the framework, or people who may want to help work on the
extension. Possible topics include:
* How do I use it?
* What features are under development in this framework right now?
* How does it work?
* Can I have feature X?
If you have any questions, or want to hear me wax on about what I've done
with the extension thus far, drop on by and have a chat. I'll be in
#wikimedia-office on Thursday at 21:00 UTC (14:00 PDT).
[0] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
Happy hacking,
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
I have contacted some wiki projects sending them the email below. If you
know good contacts out there please forward this invitation to them.
The FOSDEM organizers replied back saying that they preferred a
cross-project Wiki devroom. The more and more diverse support we get,
the better chances we will have to get the devroom proposal accepted.
... and if you want to help defining the proposal you are of course
invited too. I'll start drafting tomorrow.
-------- Original Message --------
Subject: Wiki DevRoom at FOSDEM?
Date: Wed, 04 Sep 2013 15:06:28 -0700
From: Quim Gil <qgil(a)wikimedia.org>
Organization: Wikimedia Foundation
To: qgil(a)wikimedia.org
Dear wikicolleague(s),
The Wikimedia/MediaWiki community is planning to propose a DevRoom for
FOSDEM (Brussels, February 1-2, 2014).
https://fosdem.org/2014/news/2013-08-06-call-for-participation/
The FOSDEM organizers promote cross-project devrooms and we think it is
a good idea as well. There is no lack of wiki projects and wiki topics
to present and discuss!
I'm coordinating the elaboration of the proposal from the Wikimedia
side. Deadline: 15 September. I will start drafting it at
https://www.mediawiki.org/wiki/Events/FOSDEM tomorrow, but first I
wanted to contact several projects seeking support and eventually
collaboration.
What we need:
* If you are interested, please give explicit support to this DevRoom on
behalf of your project.
* If you are quite interested, watch and edit the proposal.
* If you are really really interested and you will have the time, step
in to co-coordinate the DevRoom.
There are no more details so far. Following TheWikiWay ;) I decided to
start contacting you before getting too deep into the planning.
Let me know if you are interested!
Best regards,
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
FYI,
---------- Forwarded message ----------
From: <core-ops(a)rt.wikimedia.org>
Date: Mon, Sep 30, 2013 at 2:12 PM
Subject: Fwd: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade
etherpad-lite has been successfully update to version 1.2.11. The
upgrade procedure server-wise was uneventfull, however it will cause
some minor problems to existing users of the service. Specifically
CSS/JS elements of the page have changed and need to be re-downloaded
by the browser, however due to browser caching this does not happen
automatically. Users of the old version will have to FORCE REFRESH
their browser when accessing the service for the first time. Otherwise
they will get garbled versions of the user interface. Pad contents
will be intact, however a brief message suggesting the user does not
have permission to access a pad might show up. That message is
inaccurate and is a by-product of the garbled UI.
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
Hello,
I want to rewrite a couple of extensions to prevent them from loading
resources unless the extension is active on a page. Is there some
documentation on this somewhere, or an extension that does this whose code
I examine?
Thanks for any help!
--
Amelia Ireland
GMOD Community Support
http://gmod.org || @gmodproject
Hi,
I noticed that there is a high amount of suspicious edits that may be
vandalism but were never reverted because people who were dealing with
vandals (using some automated tool) in that moment weren't able to
decide if it was vandalism or wasn't. For example some "smart" changes
to statistical data, dates, football scores, changes that look weird
but aren't clearly vandalism etc. These edits should be reviewed by
expert on the topic, but in this moment, they aren't collected
anywhere.
I think we should create a new service (on tool labs?) that would
allow these tools to insert such edits to queue (or database) of
"suspicious edits" for later review by experts, this categorized
database / queue could be browsed by people who are experts on given
topics and got reviewed / reverted by them.
The database would need to be periodically scanned and all changes
that were reverted would need to be removed from it. The people who
reviewed the edits could also flag them as "ok".
This way we could improve the efficiency of anti-vandalism tools by
the amount of edits which are ignored or skipped these days.
Some suggestions or ideas how to implement such a feature?
Forwarded to wikitech-l
---------- Forwarded message ----------
From: Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il>
Date: Sat, Sep 28, 2013 at 10:38 AM
Subject: [WikimediaMobile] webfonts in mobile frontend
To: "mobile-l(a)lists.wikimedia.org" <mobile-l(a)lists.wikimedia.org>
Hi,
So today I worked with Kaldari (thanks for the help!!) and committed a
very simple module to enable webfonts support in MobileFrontend:
https://gerrit.wikimedia.org/r/#/c/86340/https://gerrit.wikimedia.org/r/#/c/86337/
Review and any comments are very welcome, of course.
The current implementation is very simple. It doesn't allow any
configuration or choice of fonts - if there is a default font for the
language, it is used wherever there's a lang attribute or a style or a
class the sets a font explicitly. (Some languages, like Tamil and
Hebrew have fonts, but they are not default, so none are used). It may
be worth optimizing it, for example:
* Only loading the font of the content language to save time and
bandwidth. (Loading additional fonts can be an option.)
* Only loading fonts on devices that are known to have bad font
support. On iPhone and it's pretty for many languages. On the latest
Windows Mobile version it's very good. On Android below 4.0, however,
it's very bad: most languages of India are completely unreadable,
which is the main reason to do this (the same goes for languages of
Ethiopia, South-East Asia and some others). Android 4 and above is not
always perfect either.
I'd love to hear more considerations about bandwidth, performance, testing etc.
Thanks!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Yuvi Panda T
http://yuvi.in/blog
FYI
---------- Forwarded message ----------
From: Core operations via RT <core-ops(a)rt.wikimedia.org>
Date: Thu, Sep 26, 2013 at 1:01 PM
Subject: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade
To: akosiaris(a)wikimedia.org
I am scheduling a downtime for etherpad.wikimedia.org on Monday 30/09/2013 in
order to upgrade it to the latest released version. The downtime is scheduled
to last one (1) hour and will start in 09:00 UTC. We will be upgrading from 1.0
(released 2 years ago) to 1.2.11 (released 3 months ago). Package has already
been created and will be made available on apt.wikimedia.org during the
upgrade. Hopefully a lot of the bugs we have witnessed that cause problems in
etherpad.wikimedia.org will be resolved.
--
(ticket has been created)
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
Apologies, I always forget to hit "Reply All".
-------- Original Message --------
Subject: Re: AbuseFilter error codes and MobileFrontend
Date: Sat, 21 Sep 2013 10:11:28 +1000
From: Andrew Garrett <agarrett(a)wikimedia.org>
To: Juliusz Gonera <jgonera(a)wikimedia.org>
Juliusz Gonera wrote:
>
> After getting some initial information from legoktm, my thoughts are:
>
> * Probably no changes to AbuseFilter are necessary and we should
> implement everything in MobileFrontend.
>
> * We should display the warning message (edit.warning in API response)
> for all codes (edit.code in API response) that start with
> abusefilter-warning* and allow the user to resubmit.
> * We should display the disallow message (edit.warning in API
> response) for abusefilter-disallow and not allow the user to resubmit.
> * We should display edit.warning message if present or a general one
> and not allow the user to resubmit for all the other error codes
> (until now we've got abusefilter-blanking, abusefilter-blank,
> abusefilter-imza, abusefilter-blocked-display and
> abusefilter-autobiography, but they don't happen too often).
You should know about this change[1], which corrects the error messages
to be more in line with the general case, as well as adding some
metadata. It's not been approved yet, so I'm nudging a few reviewers.
You can also determine which mobile edits are hitting filters, by
looking for edits in the filter log which have 'user_mobile = 1' set.
I'm not sure I quite remember how to search in that way, but I'll look
into it.
[1] https://gerrit.wikimedia.org/r/#/c/80137/