On mobile we continuously get bugs related to inline styles in
templates. For example:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68001
When these happen we usually spend time investigating, discover it is
because of a troublesome inline style in the template and then we
communicate this on the template talk page [1]
However, rarely do these get replies and rarely does anything get fixed.
Am I doing something wrong? Should I be posting these problems
elsewhere? It seems like a lot of templates do not have active
maintainers.
There has been an RFC [2] open for ages that when solved I hope will
lead to lots of discussions between developers and template
maintainers but right now it seems even without the tools we are
failing.
How can we get better at making our template styles more mobile friendly?
[1] https://en.wikipedia.org/wiki/Template_talk:Quotation#Padding_interferes_wi…
[2] https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templa…
Hi,
Google Code-In (GCI) will soon take place again - a contest for 13-17
year old students to contribute to free software projects.
Wikimedia wants to take part again.
Last year's GCI results were surprisingly good - see
https://www.mediawiki.org/wiki/Google_Code-in_2013
We need your help:
1) Go to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Mentors.27_corner
and read the information there. If something is unclear, ask!
2) Add yourself to the table of mentors on
https://www.mediawiki.org/wiki/Google_Code-in_2014#Contacting_Wikimedia_men…
- the more mentors are listed the better our chances are that Google
accepts us.
3) Please take ten minutes and go through open recent tickets in
https://bugzilla.wikimedia.org in your area of interest. If you see
self-contained, non-controversial issues with a clear approach which you
can recommend to new developers and would mentor: Add the task to
https://www.mediawiki.org/wiki/Google_Code-in_2014#Proposed_tasks
Helpful Bugzilla links:
* Reports that were proposed for GCI last year and are still open:
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=ALL%20whiteboard%3Ag…
* Reports marked already as "easy":
https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_statu…
Could you imagine mentoring some of these tasks?
Until Sunday November 12th, we need at least five tasks from each of
these categories (plus some less technical beginner tasks as well):
* Code: Tasks related to writing or refactoring code
* Documentation/Training: Tasks related to creating/editing
documents and helping others learn more - no translation tasks
* Outreach/research: Tasks related to community management,
outreach/marketing, or studying problems and recommending
solutions
* Quality Assurance: Tasks related to testing and ensuring code is
of high quality
* User Interface: Tasks related to user experience research or
user interface design and interaction
Google wants every organization to have 100+ tasks available on December
1st. Last year, we had 273 tasks in the end.
Note that you could also create rather generic tasks, for example fixing
two interface messages from the list of dependencies of
https://bugzilla.wikimedia.org/show_bug.cgi?id=38638
Thank you for your help in reaching out to new contributors and making
GCI a success again! Please ask if you have questions.
Cheers,
andre
PS: And in a future Phabricator world, Bugzilla tickets with the 'easy'
keyword will become Phabricator tasks with the 'easy' project.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Pencil the dates below, which need to be agreed with our close neighbors in
order to become official.
On Thu, Oct 30, 2014 at 11:05 PM, Quim Gil <qgil(a)wikimedia.org> wrote:
> Tomorrow, we will start discussing possible dates for the Bugzilla and RT
> migrations. While we keep working on open tasks, the next milestone is to
> announce the dates of these migrations.
>
As posted in https://phabricator.wikimedia.org/T15
The Wikimedia Phabricator team proposes to start migrating Bugzilla on
Friday 21 November and during the weekend, with a possibility to require
Monday 24 to complete the migration. Before that date, you can expect:
* T843: Complete Bugzilla migration test review period
<https://phabricator.wikimedia.org/T843> including a bugzillapreview
instance regenerated with a sample of 500 tasks, showcasing the fixes to
the bugs reported during the community review.
* Dates and procedure (T535) agreed with the Wikimedia Foundation
Engineering and Product Development management, with explicit approval from
the Release Team and Ops.
* Dates for the RT migration, which we plan to propose soon, considering
that they might be after the Bugzilla migration and therefore cause another
Phabricator downtime, theoretically shorter.
* All the tasks in #Bugzilla-Migration that must be completed before the
migration will be resolved; the rest of tasks in this project will be
assigned to people ready to proceed as planned during the migration.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_November_3rd>
A quick list of notable items...
== All Week ==
* HHVM is enabled for only 10% of anonymous users again, after issues
with the rollout the week of October 27th
* Fundraising tests throughout the week (on-going through the rest of
the yearly fundraising)
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf6: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf6>
== Wednesday ==
* New Search (Cirrus) to French Wikipedia
** <https://www.mediawiki.org/wiki/Search>
* MediaWiki deploy
** group2 to 1.25wmf6 (all Wikipedias)
** group0 to 1.25wmf7 (test/test2/testwikidata/mediawiki)
== Thursday ==
* Enable TemplateData GUI on all remaining wikis
** <https://www.mediawiki.org/wiki/Help:TemplateData>
Thanks and as always, questions and comments welcome,
Greg
--
Greg Grossmeier
Release Team Manager
Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2014.10. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.22.x releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.10.tar…
* sha256sum: 49707823ec19d9eed1c21c37550a3b0a2c81ff83855aea2706287a5169e90468
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR and LocalisationUpdate ==
* Only localisation updates.
== CleanChanges ==
* Localisation updates.
* Added support for ULS in language filter selector.
== Translate ==
* New feature: Remove any page from translation with two clicks from
Special:PageTranslation. Previously, translate tags had to be removed
manually first.
* Special:PageTranslation also has prettier warning and error notifications.
* The user group translate-proofr is no longer created by default. If
you were using it, you can add it back with following code in your
LocalSettings.php:
$wgGroupPermissions['translate-proofr']['translate-messagereview'] = true;
$wgAddGroups['translate-proofr'] = array( 'translate-proofr' );
* Removed $wgTranslatePageMigration (enabled by default),
$wgTranslateUseTux (no longer in use) and translate-proofr group
(needs sysadmin action if in use).
* Bug 48672: When marking page for translation, show a note before
submit if there are no differences.
* Added support for page status indicators. This alters very slightly
the way help icons are displayed on some special pages.
== UniversalLanguageSelector ==
=== Input Methods ===
* Fixed bug in Burmese (my-xkb) keyboard.
Thanks!
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
A random thought, maybe it's been discussed before here or on another ML,
but I couldn't find that discussion.
I've heard the argument that a lot of people who donate money to the WMF
don't necessarily understand that contributors aren't paid to write the
content on the site, etc. and might be donating with the impression that
they're directly rewarding the people who put the content together. Because
most readers don't know how wiki projects function. Which is a reason why
the proponents of sponsored/paid editing view this as a diversion of
donations that should go to the contributors and so on. I don't have a
particularly strong opinion on this, but it's something I hear on a regular
basis from community members.
I think there is a technological opportunity that changes the game
regarding this question, though, which is digital currencies. Bitcoin, or
whatever better shinier thing might take over its leadership position in
that domain, open opportunities with micropayments that were not possible
before.
It's possible, right now, to build something that would allow a reader to
donate an arbitrary amount of bitcoins for a specific article ("that
article or a portion of it helped me, here's some money for the people who
wrote it"), and the sum would be broken down into lots of smaller parts,
given to all the contributors of this article. This ability to break things
down into tiny fractions is something that isn't possible with regular
money.
I think this opens a lot of interesting questions:
- How would the breakdown be calculated? Moving content around, adding
citations, writing original content, etc. are tasks of very varied effort.
I imagine the community would probably have to define the compensation
rules here.
- What would the effects be on the community? This opens the hornet's nest
of mixing compensation and free knowledge. But in a way, the WMF is mixing
those already.
- Would it increase imbalance in article activity? It's easy to imagine
that people would flock to highly popular articles trying to update them
doing disguised null-edits just for the sake of joining the contributor
pool for future readers donating to that article. A community-driven
solution might be to decide that popular articles don't need this
compensation system and are blacklisted. This is after all most useful for
articles that require a lot of work with little reward. A whitelist
approach of putting "bounties" on areas that need work might be more
effective.
In my opinion I think that as everything that has ever been built on this
platform, it would be just a tool and the ways the community decides to use
it might not be what we expect. It's a technical possibility that didn't
exist before, though, so I think it needs to be studied, even if nothing
ends up being done with it.
Hello,
I am receiving lot of these warnings:
WARNING: API query (revisions): The rvtoken parameter has been deprecated.
According to current documentation for mediawiki at
https://www.mediawiki.org/wiki/API:Rollback which I follow, in order
to get a rvtoken I should use this query:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvtoken=roll…
however that very query returns this warning. Is this a bug in
documentation? Why do you first deprecate things and then, ages later,
update the docs? Shouldn't it be the other way? Mediawiki has worst
backward compatibility support I have ever seen and this is one of the
reasons for it.
Thanks
Hello
I am Manpreet Kaur, an undergraduate engineering student. I am interested
in contributing to a PyWikiBot project of extending PWB's support to all
sites listed in the InterWikiMap and a feasible wiki engine. XML-RPC is an
interface supported by many wiki-engines and hence I also wish provide
support for this interface.
My project proposal can be found at
https://www.mediawiki.org/wiki/User:Omegat_Project_Proposal_for_OPW.
I would be happy if other developers in the community review my proposal
and give feedback for improvement in the proposal or other project details.
This will also give me new ideas to approach the project and improve it.
Thank You
Phabricator milestone!
https://bugzillapreview.wmflabs.org/https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Test_instance
(please read)
A test instance is available for review, showing a sample of 10% of all the
Bugzilla reports, automatically migrated. Register with your Bugzilla email
address, wait for your activity to be assigned to you (might take a while),
and try to find problems that we should fix before the real migration
happens.
WE WANT YOUR FEEDBACK
https://phabricator.wikimedia.org/tag/bugzilla-preview/
Check the list of known issues before creating new tasks. We are leaving at
least one week for feedback, or more if there are issues that require fixes
and a second test. At the end of the review period we will be able to
commit to a Bugzilla migration date.
Thank you again to Chase, Mukunda, and Andre for opening a way that nobody
has walked before. Big Thank You also to the growing number of contributors
helping in this complex and terribly interesting migration process!
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil