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
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
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
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 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 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 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 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 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 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
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
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
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
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
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
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 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 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 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 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 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.
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 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
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 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 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 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 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 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 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
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 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
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 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 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
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
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
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?
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 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 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 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 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 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
I know the office hours are probably exactly for this kind of question,
but I have to ask just for the sake of general interest - are these
changes going to be pushed to core, or will they remain in extensions,
for instance simply as a permanent feature of enwp only?
On 28/11/2012 21:51,
On 06/12/2012 15:01, Sébastien Santoro wrote:
On Thu, Dec 6, 2012 at 10:52 PM, Tim Landscheidt t...@tim-landscheidt.de
wrote:
That is all. The slow unit tests are no more run on patchset submission.
We really need them.
The tests philosophy is there is an issue with this change.
The
On 17/01/13 22:38, Chris McMahon wrote:
To the best of my knowledge the only publicly accessible page for VE exists
at http://www.mediawiki.org/wiki/VisualEditor:Test, and I believe one might
have to have special rights to edit that page.
Visualeditor is available at least on enwp to users who
On 21/01/13 08:04, Chris Grant wrote:
Not sure about enwiki, but from my experience with hosting smaller wiki's
CAPTCHA's are pretty useless (reCAPTCHA, FancyCAPTCHA, some custom ones).
The spambots keep on flooding through.
I've found its much more effective to just use the AbuseFilter.
--
Yeah, having it activate when the relevant element loads instead of the
entire page would probably help a lot with that.
On 16/02/2013 14:20, Paul Selitskas wrote:
WikiEditor is initialized when the 'ready' event is fired in JavaScript:
/extensions/WikiEditor/modules/ext.wikiEditor.js:
$(
Talkpages are being redesigned to use a more object-based setup, which
should make tagging things a lot easier, but this still holds - those
objects will be taggable, but also there are years worth of old
discussions on many projects that may still wind up benefiting from a
section-based
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
On 05/03/13 23:45, Matthew Flaschen wrote:
On 03/05/2013 02:33 PM, Platonides wrote:
On 05/03/13 21:53, Matthew Flaschen wrote:
On 03/05/2013 12:29 PM, Luke Welling WMF wrote:
We should discuss them separately, but this core mediawiki JS is GPL2
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
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
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
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 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 31/08/2012 08:57, Brion Vibber wrote:
Heck yes. Generate some standard sizes at upload time and let the
browser scale if a funny size is demanded. Modern browsers scale
photos nicely, not like the nearest-neighbor ugliness from 2002.
As a graphist, I must say this does not seem like a
On 03/09/2012 05:33, Magnus Manske wrote:
Illustrating the problem of manual right/left aligned thumbnails and
elements by using slightly different CSS:
http://toolserver.org/~magnus/redefined/?page=San%20Francisco
Magnus
That looks like as much a problem with the general design there as
On 21/09/2012 11:46, Rob Moen wrote:
On Sep 20, 2012, at 3:48 PM, Krinkle wrote:
If they happened as a direct
consequence of a user action, maybe it should appear inside the interface where
it was performed?
Agreed, interaction related notifications should be localized in the interface
where
On 24/09/2012 13:35, Jon Robson wrote:
So I had a brainwave about this over the weekend.
The home page for the developer page should act like a personal appeal
only with __developers__ as the writers.
I think a personal touch is a great way to explain to a would be
developer to why they should
On 24/09/2012 15:41, Jon Robson wrote:
That is an intriguing concept that could indeed work quite well to get
people interested, but how many will remain interested after they encounter
gerrit?
That's a separate problem.. haha!
Derric - in reply to your concerns... just a few points
1) The
On 27/09/2012 07:56, Aran Dunkley wrote:
Hello, does anyone here know why the parser insists on adding p tags
to HTML results returned by parser functions?
I'm trying to upgrade the TreeAndMenu extension to work with MediaWiki
1.19 and I can't get the parser to stop adding p tags throughout the
If I said I wanted to learn everything, how entirely unhelpful would
that be? Not that I really do know enough at this point to be any more
specific...
Could a mentor help with dealing with the people, though? As an
en.wikipedian I have found developers to be somewhat harder to deal with
On 05/11/2012 16:02, Nabil Maynard wrote:
Personally, I like having a Postponed/Later resolution at least
available.
WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix
it due to time and resources necessary to fix it. We will not be
revisiting this bug unless it is
On 21/11/2012 08:41, Quim Gil wrote:
On 11/20/2012 05:19 PM, James Forrester wrote:
* Desktop: Current and immediately-previous versions of Chrome, Firefox,
MSIE and Safari
* Tablet: Current versions of iOS/Safari; Current and
immediately-previous
ones of Android
* Mobile: Current versions of
On 27/11/2012 09:55, Andre Klapper wrote:
On Tue, 2012-11-27 at 16:49 +, David Gerard wrote:
Has anyone suggested a separate urgency parameter?
I don't think adding another parameter in the user interface improves
anything. We have already Priority, Severity, Target milestone
and blocker
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 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
1 - 100 of 217 matches
Mail list logo
