This, all of this.
On 21/02/15 21:26, Brian Wolff wrote:
However that's not a reason to have no IEG grants for tech projects
ever, its just a reason for code review to be specifically addressed
in the grant proposal, and for the grantee to have a plan. Maybe that
plan involves having a
On 21/02/15 15:21, MZMcBride wrote:
Instead of deletion, blanking the user page might be a neat way of
triggering the global user page to re-appear (a version of pure wiki
deletion). Though, of course, some users might want a 0-byte user page.
With interface messages, setting the content to
On 20/02/15 17:28, Brion Vibber wrote:
IMO we should strongly discourage use of multiple accounts with the same
email to the point of forbidding it in software for new accounts.[1]
Figuring out how to migrate those old accounts is something that needs to
be considered and worked out, but it
On 15/02/15 21:03, Bartosz Dziewoński wrote:
On Fri, 13 Feb 2015 23:14:59 +0100, Max Semenik
maxsem.w...@gmail.com wrote:
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
On 28/01/15 06:43, Erik Moeller wrote:
Just a quick note that I really appreciated everyone's help making the
summit come together. As always, we'll be doing lots of second-guessing of
everything we did and didn't do, and how we want to use future time
together. Before we go into that, I'd like
On 16/01/15 19:05, Trevor Parscal wrote:
I challenge the very foundation of arguments based on this 95% statistic.
The 95% statistic is bogus, not because it's inaccurate, but because it's
misleading.
The number of MediaWiki instances out there is meaningless. The value we
get from 3rd party
On 16/01/15 20:28, Brion Vibber wrote:
On Fri, Jan 16, 2015 at 12:09 PM, Isarra Yos zhoris...@gmail.com wrote:
The 95% statistic may not be meaningful, but neither is this. The number of
users involved does not reflect the importance of the information presented
any more than that a project
On 16/01/15 21:20, Erik Moeller wrote:
On Fri, Jan 16, 2015 at 1:14 PM, Ryan Lane rlan...@gmail.com wrote:
On Fri, Jan 16, 2015 at 12:27 PM, Ryan Lane rlan...@gmail.com wrote:
What you're forgetting is that WMF abandoned MediaWiki as an Open Source
project quite a while ago (at least 2 years
On 24/11/14 07:41, Quim Gil wrote:
Happy Monday!
We did it. https://phabricator.wikimedia.org now contains all the Bugzilla
reports. If you need to check the original Bugzilla, it can be found at
https://old-bugzilla-wikimedia.org (never mind the certificate warning, it
will go away today or
On 07/11/14 13:08, Dan Andreescu wrote:
At the same time I find it sad that he moves to the USA because he was
invaluable because he was available when the other Labs people were not
around. As such he provided a much needed service exactly because he lives
in India.
Oh that's a common
On 07/10/14 22:02, Jon Robson wrote:
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
On 07/10/14 22:17, Isarra Yos wrote:
On 07/10/14 22:02, Jon Robson wrote:
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
On 01/10/14 01:25, Jackmcbarn wrote:
On Tue, Sep 30, 2014 at 8:58 PM, Brian Wolff bawo...@gmail.com wrote:
Would this mean that if people had a fancy sig, and they changed it,
it would automatically update everywhere with this magic tag instead
of just applying to new signatures? (Which might
On 23/09/14 08:25, Gergo Tisza wrote:
For accessing the git server, you should check that
1) git remote show origin (or git remote show gerrit - depends on your
git-review version + config) returns ssh://gerrit user@
gerrit.wikimedia.org:29418/project name as the push fetch URL
2) ssh -p 29418
On 23/09/14 21:13, Gergo Tisza wrote:
On Tue, Sep 23, 2014 at 8:29 PM, Isarra Yos zhoris...@gmail.com wrote:
As I understand it, the remotes for the submodules are all set in the
parent repository's configuration, and thus will always be the same
regardless of how you dowloaded or set up
On 21/09/14 22:41, Markus Glaser wrote:
Hi Isarra,
Why is this ahead of schedule? Two months before release seems pretty
reasonable to me; ...
You don't want to rush this stuff, especially when balancing with breaking
changes in the next release.
It's ahead of the planned release schedule
On 16/09/14 13:34, Quim Gil wrote:
Hi, if you were wondering what is going on in Phabricator land...
Summary: You can see https://phabricator.wikimedia.org , you can touch
https://phab-01.wmflabs.org/ , you will have a chance to provide feedback
about the Bugzilla migration before the
Hi, I had to switch computers the other day, which resulted in my having
to reinstall git-review, and now it... doesn't work. Basically there are
two problems: for every new repository I use, I now need to add a
commit-msg hook to the .git directory, and also ssh doesn't work at all,
so I have
On 23/09/14 00:26, Isarra Yos wrote:
Hi, I had to switch computers the other day, which resulted in my
having to reinstall git-review, and now it... doesn't work. Basically
there are two problems: for every new repository I use, I now need to
add a commit-msg hook to the .git directory
On 23/09/14 00:34, Isarra Yos wrote:
On 23/09/14 00:26, Isarra Yos wrote:
Hi, I had to switch computers the other day, which resulted in my
having to reinstall git-review, and now it... doesn't work. Basically
there are two problems: for every new repository I use, I now need to
add a commit
On 21/09/14 20:42, Mark A. Hershberger wrote:
Dear Wikitech-l
REL1_24 was branched and announced ahead of schedule[0].
Our schedule[1] clearly states that we will announce a branch one week
before we make one in order to allow developers to put any necessary work
into the branch and keep
On 05/09/14 22:45, Thomas Mulhall wrote:
Can we add a section for release date of the extension or skin release. because
it would be easer to view the release date in the special version page then go
to the extension page and try to look it up.
This does sound like it could be useful, and
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
On 06/09/14 16:28, Thomas Mulhall wrote:
What I mean is for the extension to add there own release date so that when
they release an updated version like for example 1.0 updated to 1.0.1 or 1.1
and the user goes to the extension and page and sees there is an updated
version with an updated
On 21/08/14 13:13, Quim Gil wrote:
On Wednesday, August 20, 2014, Legoktm legoktm.wikipe...@gmail.com wrote:
At Wikimania, we had a good conversation and a proposal (that was
basically agreed upon by everyone in the room IIRC!) about creating a
gold standard for extensions, judging them based
On 20/08/14 11:48, Quim Gil wrote:
For those interested in the process of proposing and accepting internship
projects, here you have a post mortem of this specific case:
On Tuesday, August 19, 2014, Strainu strain...@gmail.com wrote:
This sounds like a serious miscommunication before the
On 18/08/14 14:54, Brad Jorsch (Anomie) wrote:
On Sun, Aug 17, 2014 at 6:06 PM, Aditya Chaturvedi
aditya.iiita...@gmail.com wrote:
However, to run the system in production first, we need assistance on how
to make these ratings visible on the pages of extension.
Has it already been asked
On 11/08/14 16:54, Tyler Romeo wrote:
There are many legitimate cases (e.g., office actions and copyright-related
issues) where I could see the superprotect level coming in handy. There are
some cases where the WMF simply cannot afford (usually b/c of legal
reasons) to trust the community, even
On 08/08/14 14:24, Jon Robson wrote:
On 8 Aug 2014 04:23, Antoine Musso hashar+...@free.fr wrote:
Le 07/08/2014 22:05, Erwin Dokter a écrit :
I now have to submit two patches and hope they both get merged at the
exact same time.
The world we should be working towards is one where you'd only
On 07/08/14 14:32, Bartosz Dziewoński wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke
me on IRC if the email I send earlier and the instructions don't help :)
Would it be possible to get the common directory out of core/skins/ as
well?
I prefer Bob.
On 07/08/14 08:40, Pine W wrote:
We could name it in honor of Jimbo. ;)
On Aug 7, 2014 1:18 AM, David Gerard dger...@gmail.com wrote:
Call it Bob. Bob is always a good name.
- d.
___
Wikitech-l mailing list
Hi,
What would be the purpose of this organisation and separate community,
exactly? Has there been any demonstrated need or even want for such an
organisation amongst the community it would proportedly serve?
I ask in particular because as a third-party sysadmin myself, it's hard
enough
Aye, these are valid points, and there are very real issues with what we
have (and don't have) currently.
But why do we need a separate organisation to address them? Why can they
not be addressed at home, on mw.org? Why hasn't any of this
consolidation happened already, before adding another
On 14/07/14 18:41, Jon Robson wrote:
I just wanted to thank Bartosz for all the good work he's done here!
It's great that finally installing a skin is consistent with
installing an extension :)
I wonder if we should create a skin boilerplate repository, to make it
really easy for people to get
On 16/07/14 02:50, Risker wrote:
On 15 July 2014 22:28, Steven Walling steven.wall...@gmail.com wrote:
On Tuesday, July 15, 2014, Jon Robson jdlrob...@gmail.com wrote:
(Forked from Re: [Wikitech-l] Not logged in page)
Is it time to revisit this behaviour? It's come up as being a usability
On 10/07/14 10:21, Quim Gil wrote:
On Wednesday, July 9, 2014, Isarra Yos zhoris...@gmail.com wrote:
Interesting that these are two translation folks, and nothing from the
wider development community. I'm sure they're lovely people, but I must say
this doesn't represent our diversity very well
On 09/07/14 10:38, Quim Gil wrote:
Siebrand and Kartik have been selected to participate in the GSoC Reunion o
behalf of Wikimedia.
https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_mentors#Delegates_for_Google_Summer_of_Code_Reunion
Reasoning pasted here for your convenience:
On 27/06/14 19:02, Jeffrey Barish wrote:
On Friday, 27 June 2014 10:24:57 Ryan Kaldari wrote:
Works for me. I added the background-color rule to
https://en.wikipedia.org/wiki/User:Kaldari/vector.css and it took effect
immediately.
Ryan Kaldari
On Fri, Jun 27, 2014 at 8:31 AM, Jeffrey Barish
Hey all,
We've posted our proposal for the release management RFP. You can find
it at https://www.mediawiki.org/wiki/Release_Management_RFP/2014/Consortium
Our team includes me (Kim Schoonover), Ryan Schmidt (Skizzerz), Benjamin
Lees (Emufarmers), Jack Phoenix, and Bartosz Dziewoński (Matma
On 11/06/14 05:01, Matthew Walker wrote:
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements
On 11/06/14 22:26, Tim Starling wrote:
One thing that concerns me about the proposed composer setup, that I
haven't mentioned yet, is the nesting of the project hierarchy, with
mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of
On 11/06/14 23:21, Tyler Romeo wrote:
On Wed, Jun 11, 2014 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
Problem with composer is it doesn't actually work for all use cases (farms
in particular can be problematic, even if the wmf did get it working), so
depending on it isn't really a good
On 11/06/14 02:30, Tim Starling wrote:
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or
On 11/06/14 03:24, John wrote:
there is currently a patch in gerrit which would do exactly that if merged.
Why?
This sounds like a really bad idea, but maybe it isn't, and as a
sysadmin and developer I need to know what it even is so I can decide if
I should flip the fuck out. Or not.
-I
On 11/06/14 03:31, John wrote:
My suggestion, Flip the fuck out Its a really bad idea that wasnt thought
though, If users want SwiftMailer support it should be done in an
extension, and not in core
On Tue, Jun 10, 2014 at 11:30 PM, Isarra Yos zhoris...@gmail.com wrote:
Okay, so I'm completely
On 31/05/14 15:03, Merlijn van Deen wrote:
On 31 May 2014 16:08, Chad innocentkil...@gmail.com wrote:
270MB is gigantic for a git repo.
But it's not an issue /per se/. The issue is slow clones/slow pulls, not so
much the 270MB on your hard drive. The slow clones/pulls can be improved by
On 21/05/14 20:38, Stephan Gambke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.),
On 20/05/14 22:07, Daniel Friesen wrote:
On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote:
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for assets, using an autodiscovery mechanism to automagically make the
skin available after the
On 20/05/14 23:05, Daniel Friesen wrote:
On 2014-05-20, 3:48 PM, Isarra Yos wrote:
Out of curiosity, what are your reasons for advocating lowercase skin
names over the standard camelcase format used throughout the rest of
MediaWiki?
I included those in my bullet points.
* The skinname you
On 14/04/14 23:49, Erwin Dokter wrote:
On 15-04-2014 00:55, Isarra Yos wrote:
Deemed better? Better how? But that's what I'm saying - if the
configuration is optimised for dejavu sans, nimbus won't be better at
all even if it is a better-engineered font (doubtful, though, it being
an arial
On 15/04/14 01:54, Steven Walling wrote:
On Mon, Apr 14, 2014 at 3:55 PM, Isarra Yos zhoris...@gmail.com wrote:
Deemed better? Better how? But that's what I'm saying - if the
configuration is optimised for dejavu sans, nimbus won't be better at all
even if it is a better-engineered font
On 11/04/14 19:30, Erwin Dokter wrote:
First, I like to aplologize to anyone who I may have come over too
passionate at some times. Frustration is known to get the better of
me, even though I should control that. (I also quit smoking.)
Not sure where a new font stack should be discussed, so
On 11/04/14 18:42, Bartosz Dziewoński wrote:
I have merged the Gerrit change
(https://gerrit.wikimedia.org/r/#/c/124475/),
restoring the body font to sans-serif. The heading font is unchanged
for now.
I've read the entire wikitech-l thread (89 emails as of writing) and
pondered this
On 09/04/14 08:26, John Mark Vandenberg wrote:
I agree with everything Risker said. I go further and suggest the team
involved stops defending their goals and implementation. The former are not
the issue, and the latter was indefensible. I havent looked at how much
testing was done, or if there
Helvetica, I get Nimbus Sans L
* Android users ?? (Nobody responded.)
Linux often gets arial. Anyone with wine will probably have it
installed, too, and most will have wine even if they don't use it. It's
not necessarily a particularly good copy, either.
quoting Isarra Yos
Given that no objective
On 07/04/14 20:19, Jon Robson wrote:
After the deploy last Thursday various users on Village Pumps bug
reports and external sites (e.g. Twitter and Reddit) were informing us
that the new typography was unreadable. Sadly it was difficult to
distinguish whether this was simply a dislike of the new
On 07/04/14 21:03, Martijn Hoekstra wrote:
+1, but to me 'serif' rather than 'sans-serif' for the section headers is
nicer. YMMV and can certainly live with sans for section headers
Having different serif for the headers with sans-serif content can be a
bit dangerous, depending on the fonts in
On 08/04/14 00:02, Steven Walling wrote:
On Mon, Apr 7, 2014 at 4:08 PM, Erwin Dokter er...@darcoury.nl wrote:
I feel that I am not being taken seriously. Three times now I have
indicated what is wrong with this solution, namely that a single font stack
cannot possibly serve a global website.
On 12/03/14 15:47, Jon Robson wrote:
Okay to make sure stuff comes out of this thread...
So unless someone does this before me I am going to move CologneBlue out of
core and into SkinCologneBlue extension and Modern out of core into
SkinModern extension.
If someone could rerun the data
On 12/03/14 07:15, Antoine Musso wrote:
Le 11/03/2014 23:55, Isarra Yos a écrit :
On 11/03/14 22:45, Trevor Parscal wrote:
By making all skins extensions it would also force us to make a few new
APIs which are needed to no longer have skin extensions be second-class
citizens.
This should
On 11/03/14 17:26, Trevor Parscal wrote:
It might be easier to revamp the skin system if there were fewer skins to
port.
- Trevor
But that completely ignores the primary users of non-Vector skins -
third party users who have developed their own skins. Every time the
skinning systems
On 11/03/14 19:21, Jon Robson wrote:
It might be easier to revamp the skin system if there were fewer skins to
port.
Touché.
So.. so 2 questions
1) would anyone have any objections to moving it out of core and into
its own extension?
2) would anyone have any objections for turning it off on
On 11/03/14 20:16, James Forrester wrote:
On 11 March 2014 13:10, Isarra Yos zhoris...@gmail.com wrote:
On 11/03/14 17:26, Trevor Parscal wrote:
It might be easier to revamp the skin system if there were fewer skins to
port.
- Trevor
But that completely ignores the primary users of non
On 11/03/14 21:21, Jon Robson wrote:
If people forget they exist I would say that equates to no one cares
about them and no one maintains them.
If this is true, we are doing a disservice to our users by providing
these skins to our users.
Developers forget some users exist. They forget use
On 11/03/14 22:45, Trevor Parscal wrote:
By making all skins extensions it would also force us to make a few new
APIs which are needed to no longer have skin extensions be second-class
citizens.
This should happen.
- Trevor
Quite so. Think hitting on some of this could be a viable gsoc
On 08/03/14 09:15, Niklas Laxström wrote:
2014-03-08 0:39 GMT+02:00 George Herbert george.herb...@gmail.com:
This is not disrespecting development, which is extremely important by any
measure. But we're running a top-10 worldwide website, a key worldwide
information resource for humanity as a
On 07/03/14 10:16, Steven Walling wrote:
Just for more background/context here... As you can see in the latest
comments on bug 61416, I'm not the only one who objects to the
implementation as currently designed. Prior to the bug, Erik M. also
proposed an alternative solution which was ignored
On 07/03/14 17:06, Antoine Musso wrote:
Le 07/03/2014 16:48, Bartosz Dziewoński a écrit :
On Fri, 07 Mar 2014 16:27:53 +0100, Antoine Musso hashar+...@free.fr
wrote:
So a single -1 should prevent a change from being submitted until that
-1 is lifted by addressing the person concern(s) or
On 07/03/14 03:58, Tim Starling wrote:
I would never have merged it, because it had a -1 from Steven Walling,
apparently speaking on behalf of others on design-l. I think changes
should be made by consensus.
The changeset was the result of the discussion on the Design list. The
reason Steven
On 20/02/14 21:32, Bartosz Dziewoński wrote:
It's worth noting that WMF branches also include temporary hacks to
keep current JS/CSS and cached HTML output compatible (for at least 30
days), while release branches never contain them (and thus require
HTML caches to be purged during the upgrade
Don't suppose there'd be any way to do both things - an index to search
normally, and one to search full of everything if someone's searching
for hidden stuff.
-L
On 19/02/14 17:39, Nikolas Everett wrote:
On Wed, Feb 19, 2014 at 12:17 PM, Helder . helder.w...@gmail.com wrote:
On Wed, Feb
That's interesting - my take on AGF always was that it was a way to
avoid assumptions - another way of saying to give people the benefit of
the doubt without being such a cliché (even though it's probably even
more of one now).
But yeah, good points.
On 18/02/14 13:43, pi zero wrote:
I find
I basically agree with everything Marc said, but you bring up a very
good point about assuming good faith. That seems like something that
would probably go the furthest towards addressing the underlying
problem. Can I tape you two together?
-I
On 17/02/14 20:45, Monte Hurd wrote:
+1
When I
If you're pissed, that's when you use something like NVC, except taking
it even further, perhaps. Put other people on edge too, but then if they
do anything about it, wll...
I think this may be the standard approach on a lot of discussion boards
on enwp.
On 18/02/14 03:26, Adam Wight
How much bandwidth would this cost the users? If a mobile user is paying
by how much they download, this could well mean they're paying for
things loaded in the background - things that they may never even touch.
On 08/02/14 19:52, Jon Robson wrote:
Thanks for sharing! This could be really
On 25/01/14 13:02, rupert THURNER wrote:
for the password policy: display a strength indicator is great. anything
more? i would say just leave it to the user.
rupert.
This.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 16/12/13 12:14, Brena Monteiro wrote:
Like Quim said, right now we are preparing the Design Document[1] and all
collaboration is welcome.
Best regards,
[1] https://www.mediawiki.org/wiki/User:Monteirobrena/OPW/Design_Document
Brena Monteiro
+55 27 98109 0123
@monteirobrena
, not more.
Snt frm my iPhne
On Dec 16, 2013, at 10:44 AM, Isarra Yos zhoris...@gmail.com wrote:
On 16/12/13 12:14, Brena Monteiro wrote:
Like Quim said, right now we are preparing the Design Document[1] and all
collaboration is welcome.
Best regards,
[1] https://www.mediawiki.org/wiki
On 11/12/13 19:21, Chad wrote:
Sending wiki edits to Gerrit for review? Absolutely not.
I'm totally cool with the idea of code review for Gadgets so forth, just
not
using Gerrit. We considered it for Scribunto (and heck, I wrote half of a
proof
of concept) but shot it down because the idea
On 11/12/13 22:21, Ryan Lane wrote:
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
In recent months I've come across a few mails on this list that only
contained accusations of trolling. Those are very much not constructive and
only serve to antagonize. I know
On 11/12/13 23:28, Petr Bena wrote:
I think we need to use less rules and more common sense.
This.
When you get right down to it, what even is trolling? And should it
necessarily matter? Even if someone is trolling, that doesn't mean they
may not have a real point to it, though perhaps they
On 10/12/13 13:40, Petr Bena wrote:
I was recently suggested by someone (and requested by someone else) to
use patrolling on good edits in huggle, however after executing the
patrol api query I receive this error:
?xml version=1.0?api servedby=mw1130error
code=patroldisabled info=Patrolling is
On 07/11/13 16:28, Quim Gil wrote:
The issue is the extra step for newcomers vs the risk of many extra
steps for a few etablished contributors if someone decides to abuse the
feature, as it happened in the past. And my point is that I personally
don't believe that such barrier is diminishing the
On 04/11/13 15:31, Mark A. Hershberger wrote:
On 11/04/2013 10:10 AM, Max Semenik wrote:
Most of our mobile traffic is genrated by iOS and Android - both of
which support LocalStorage, so it will work for them too.
People using 2G/GPRS are not necessarily using a mobile device. I've
heard
On 28/10/13 02:32, Tim Starling wrote:
There is the separate issue that on my Linux laptop, Nimbus Sans L
looks worse than the font my browser will choose for sans-serif. That
is because I have customised Firefox to use the Ubuntu font for
sans-serif, which is very readable. I find all the Arial
On 11/10/13 23:37, Andre Klapper wrote:
Hi,
sorry for my late answer.
On Mon, 2013-09-30 at 08:47 -0700, James Forrester wrote:
This is brilliant, and makes Bugzilla hugely more usable; could it be
switched on for all users by default, or would that impair the server
operation too much?
I
Out of curiosity, when did it become a requirement that Foundation
management be involved throughout the process of all feature
development, and that the WMF take over maintaining anything deployed to
Wikimedia projects? Because that's just not feasible, and never has been.
1. If the
Wikia is dinky? ShoutWiki is antiquated? I don't necessarily disagree
with your overall point, but please don't generalise like this; an
innacurate statement like that just takes away from it.
On 01/10/13 21:34, Ori Livneh wrote:
On Tue, Oct 1, 2013 at 12:50 PM, Quim Gil q...@wikimedia.org
On 30/04/13 20:36, Max Semenik wrote:
Hi, as one of WMF developers who work on MobileFrontend[1], I'd love to
know how third parties use this extension. How does your caching
works? How are you detecting mobile devices? Do you have any problems
with running it? Finally, just tell us if you tried
On 03/04/13 19:37, Quim Gil wrote:
http://www.mediawiki.org/wiki/Requests_for_comment/Wikitech_contributors#First_iteration
is supposed to be completed in 3 months, and even there you have some
easier tasks that could be implemented pretty fast, namely forms
templates for
* User profiles.
On 03/04/13 20:48, Matthew Flaschen wrote:
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more
successful wiki. It is larger by all measures, and draws a wide pool
of active contributors.
I don't know that it's appropriate to put WMF-only
On 03/04/13 14:48, Yury Katkov wrote:
Hi everyone!
I think that there are two categories of developers now:
1) Wikimedia developers deal with Wikimedia tasks of running Wikipedia and
all other projects
2) Independent developers which use MediaWiki for their needs. I think that
not much of us
On 03/04/13 22:26, Ryan Lane wrote:
On Wed, Apr 3, 2013 at 5:19 PM, Isarra Yos zhoris...@gmail.com wrote:
On 03/04/13 20:48, Matthew Flaschen wrote:
On 04/03/2013 03:30 AM, Ori Livneh wrote:
That seems wrong. Of the two, MediaWiki.org is clearly the more
successful wiki. It is larger
On 02/04/13 06:43, Brian Wolff wrote:
On 2013-04-02 12:32 AM, Jeremy Baron jer...@tuxmachine.com wrote:
On Tue, Apr 2, 2013 at 2:51 AM, Matthew Walker mwal...@wikimedia.org
wrote:
You are definitely not the only one who finds these issues annoying. I
too
worry about the same.
+1
Another
Another example would be changing default options in core - recently I
tried to push for making the enhanced recentchanges the default, but one
of the blockers was that I'd need to let the Wikimedia communities know
as the change would be applied there as well.
Unfortunately I didn't have any
On 21/03/13 19:15, Quim Gil wrote:
On 03/21/2013 11:48 AM, Isarra Yos wrote:
Unfortunately I didn't have any idea when such a change could or would
be merged or deployed, so not only did I not have any timeframe to give
said the communities, I didn't even know when it would be appropriate
Non-lawyers arguing over how to interpret licenses, uses, and other
stuff with the minimised code doesn't prevent such screwing over either.
It is undoubtedly an open-source project; the question is the legal one
of where all things need to be attributed and cited, and at the end of
the day
Not rubbish - that would be quite useful. The only problem is it would
be a somewhat limited use case. Many users never go near their css/js,
so it would just be another checkbox for them to ignore, and those who
do use global css/js would just as likely have wider scope issues than
that -
Not rubbish - that would be quite useful. The only problem is it would
be a somewhat limited use case. Many users never go near their css/js,
so it would just be another checkbox for them to ignore, and those who
do use global css/js would just as likely have wider scope issues than
that -
The licensing information is on the page itself, of which the minified
js winds up a part. For every file or other object that makes up the
page to all contain the licensing information would be pretty unusual.
It's like taking a file out of a page and then complaining that it has
no
101 - 200 of 217 matches
Mail list logo
