Re: [Wikitech-l] .js errors in Metrolook skins

[florian.schmidt.wel...@t-online.de]

Hi Thomas,

i haven't installed your skin to see the error, because i think it's a 
relatively easy thing you can track down by yourself. You give us 5 lines of 
code where you think the error comes from (how have you tracked it down to 
these 5 lines?). What, if you click on the error message in the browser console 
to find out, _which_ line and which function/statement/variable throws the 
exception?

If you're using Google Chrome, i suggest you to read this webpage [1], 
especially the "Exceptions" part, to know, how to debug your JavaScript code by 
yourself :)

Next point: Your code is like a mess, sorry :) You don't follow our developer 
guidelines and coding conventions at all, here just some examples:
- Naming of global configuration variables
-> You use globals like "image1", "link2" and so on. I see two problems:
1. no wg Prefix, read [2], so no possibility to use the Config feature, e.g.
2. No meaningful namens: What does image1, image2 and so on do? What they 
control? It's like i would name you "person1", variables have feelings, so give 
them meaningful names :P Don't forget to add your skin prefix, read [3]

- Massive use of global key word
Look at this piece of code:
https://github.com/paladox/Metrolook/blob/master/MetrolookTemplate.php#L40-L68

That really looks bad :) If you have a list of globals, write it as a list with 
one global key word, e.g.:
global $image1, $image2, $link1, $link2;

It's a bit confusing to use globals and the new Config feature, which you 
register here [4] (i suggest that it's because you copied Vector), i would 
suggest to be consistent and use globals _or_ the Config feature (where it is 
possible), see [4.1]. And:
https://github.com/paladox/Metrolook/blob/master/MetrolookTemplate.php#L73
That's not the purpose of the Config feature to access foreign configuration 
values. It's possible at the moment, but, maybe, it will not anymore in next 
MediaWiki versions.

- Licensing:
I'm not a lawyer, but i haven't found a notice, that the skin is based on 
Vector (nor the authors of Vector), which may not allowed with the GPL license 
of Vector. But again: I'm not a lawyer :)

- ResourceLoader:
You mixed up your skin template with css styles, JS code, html and PHP. That's 
one way to build a skin, but it's not a really good one. I suggest, that you 
look at the examples from Vector (and other skins and extensions) and that you 
read the Documentation on mediawiki.org [5] to learn how to use the RL to 
deliver your styles and scripts. The RL gives you some advantages (all 
documented on mediawiki.org).

And some other resources:
- MediaWiki coding conventions: 
https://www.mediawiki.org/wiki/Manual:Coding_conventions (very important to 
improve your code readability)
- "How to start as a mediawiki hacker": 
https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker

Please feel free to click the links on all wikipages ;)

[1] https://developer.chrome.com/devtools/docs/javascript-debugging
[2] https://www.mediawiki.org/wiki/Manual:Wg_variable
[3] https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Variables
[4] https://github.com/paladox/Metrolook/blob/master/Metrolook.php#L46
[4.1] https://www.mediawiki.org/wiki/Manual:Configuration_for_developers
[5] https://www.mediawiki.org/wiki/ResourceLoader#Documentation

Freundliche Grüße / Kind regards
Florian Schmidt

-Original-Nachricht-
Betreff: Re: [Wikitech-l] .js errors in Metrolook skins
Datum: Thu, 12 Feb 2015 23:58:40 +0100
Von: Thomas Mulhall 
An: Wikimedia developers 

Bump. 

 On Tuesday, 10 February 2015, 14:02, Thomas Mulhall 
 wrote:
   

  Hi I am getting js script errors in Metrolook skin. The error is in 
$(document).click(function(e) {
 if (!$(e.target).closest('#'+openDiv).length) {
  toggleDiv(openDiv);
 }
});
and error says Object expected.
Source code is at 
https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook and 
https://github.com/paladox/Metrolook 
If I have to split js script out of the MetrolookTemplate.php could I have some 
help to do that please thanks.  

   
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] need review and co-mentor volunteers for GSoC Accuracy review proposal

[Brian Wolff]

On 2/12/15, James Salsman  wrote:
> I invite review of this preliminary proposal for a Google Summer of
> Code project:
>  http://www.mediawiki.org/wiki/Accuracy_review
>
> If you would like to co-mentor this project, please sign up. I've been
> a GSoC mentor every year since 2010, and successfully mentored two
> students in 2012 resulting in work which has become academically
> relevant, including in languages which I can not read, i.e.,
> http://talknicer.com/turkish-tablet.pdf .) I am most interested in
> co-mentors at the WMF or Wiki Education Foundation involved with
> engineering, design, or education.
>
> Synopsis:
>
> Create a Pywikibot to find articles in given categories, category
> trees, and lists. For each such article, add in-line templates to
> indicate the location of passages with (1) facts and statistics which
> are likely to have become out of date and have not been updated in a
> given number of years, and (2) phrases which are likely unclear. Use a
> customizable set of keywords and the DELPH-IN LOGIN parser
> [http://erg.delph-in.net/logon] to find such passages for review.
> Prepare a table of each word in article dumps indicating its age.
> Convert flagged passages to GIFT questions
> [http://microformats.org/wiki/gift] for review and present them to one
> or more subscribed reviewers. Update the source template with the
> reviewer(s)' answers to the GIFT question, but keep the original text
> as part of the template. When reviewers disagree, update the template
> to reflect that fact, and present the question to a third reviewer to
> break the tie.
>
> Possible stretch goals for Global Learning Xprize Meta-Team systems
> [http://www.wiki.xprize.org/Meta-team#Goals] integration TBD.
>
> Best regards,
> James Salsman
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Have you run this by Wikipedians? (I'm assuming enwikipedia would be
your target audience). I would recommend making sure that enwikipedia
is politically ok with this first, since it involves adding a bunch of
templates to articles, as it would suck for a gsoc student if their
work wasn't used due to politics happening at the end.

>Prepare a table of each word in article dumps indicating its age.

This in itself is a non-trivial problem (for a gsoc student anyways),
assuming you need it for the entire enwikipedia, and you need it up to
date as soon as people edit. Even getting the student sufficient
storage and CPU resources to actually compute that could potentially
be difficult (maybe?)

>Convert flagged passages to GIFT questions for review and present them to one 
>or more subscribed reviewers

Wouldn't you want to give the reviewers an actual form where they can
fill out the questions, not something in a markup language (Unless you
mean you want them to store it in that form internally,which seems
like a rather minor implementation detail)

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] need review and co-mentor volunteers for GSoC Accuracy review proposal

[James Salsman]

I invite review of this preliminary proposal for a Google Summer of
Code project:
 http://www.mediawiki.org/wiki/Accuracy_review

If you would like to co-mentor this project, please sign up. I've been
a GSoC mentor every year since 2010, and successfully mentored two
students in 2012 resulting in work which has become academically
relevant, including in languages which I can not read, i.e.,
http://talknicer.com/turkish-tablet.pdf .) I am most interested in
co-mentors at the WMF or Wiki Education Foundation involved with
engineering, design, or education.

Synopsis:

Create a Pywikibot to find articles in given categories, category
trees, and lists. For each such article, add in-line templates to
indicate the location of passages with (1) facts and statistics which
are likely to have become out of date and have not been updated in a
given number of years, and (2) phrases which are likely unclear. Use a
customizable set of keywords and the DELPH-IN LOGIN parser
[http://erg.delph-in.net/logon] to find such passages for review.
Prepare a table of each word in article dumps indicating its age.
Convert flagged passages to GIFT questions
[http://microformats.org/wiki/gift] for review and present them to one
or more subscribed reviewers. Update the source template with the
reviewer(s)' answers to the GIFT question, but keep the original text
as part of the template. When reviewers disagree, update the template
to reflect that fact, and present the question to a third reviewer to
break the tie.

Possible stretch goals for Global Learning Xprize Meta-Team systems
[http://www.wiki.xprize.org/Meta-team#Goals] integration TBD.

Best regards,
James Salsman

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Vendro api in MediaWiki

[Nick Wilson (Quiddity)]

Thomas, just FYI, it is not good etiquette to "Bump" a thread,
especially on the same day,
and especially doing multiple threads at once.
(Some might even consider it to be very annoying, and/or spam-ish).

Instead, it is better to wait for at least a week for a reply (because many
devs only read mailing lists in bursts of activity).

And instead of just saying "bump", perhaps you could try to rephrase your
original question, in a clearer or different way. (But still keep it short)
E.g. your question in this thread is confusing, due to the missing
punctuation, and because it doesn't include any examples or links for
context, and because you wrote "Vendro" in the subject but "vendor" in the
message. Please please, take the time to copy-edit, for clarity.


(semi-relatedly, please don't reply "oh ok" and other such short messages
in phabricator tasks.  E.g.
https://phabricator.wikimedia.org/T37338#1023615
https://phabricator.wikimedia.org/T37338#1023447
It clutters the history (and our email inboxes), and isn't necessary - We
can all safely assume (one hopes!) that people have read the replies.

Thanks, Hope that helps.


On Thu, Feb 12, 2015 at 2:57 PM, Thomas Mulhall 
wrote:

> Bump.
>
>  On Thursday, 12 February 2015, 19:50, Thomas Mulhall <
> thomasmulhall...@yahoo.com> wrote:
>
>
>   Hi does vendor have an api like the extension api which tells you name
> of the extension and version. Because I have ask for WikiApriary to support
> vendor in there tracking wiki site and they are asking for the api.
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Building an extension management CLI tool (What language should I write it in?)

[Daniel Friesen]

((Jump to the -- TL;DR -- if you just want to answer my question))

Hey guys, right now managing extensions is a complete mess for those of
us with a wiki running a dozens of extensions on a VPC.
Even if you use git to make things easier. You still need to batch
fetch/pull multiple git repos. And then some extensions don't work via
git, instead you install them using composer.
((And don't say use mediawiki/extensions.git, that should conflict with
composer extensions, doesn't help when an extension uses something like
version tags, and appears to have the same issues with bulk updating a
few extensions))

I convinced my boss to let me spend some time (when I have no client
projects to work on) building a tool to make managing extensions easier
for CLI users.

Some notes on the idea here:
https://www.mediawiki.org/w/index.php?title=User:Dantman/Code_Ideas&diff=1387600&oldid=1378044

Please note that this is NOT meant to be the new way we manage
extensions forever, this is a hack meant to be used as a workaround to
deal with current reality until the grand future when we're supposed to
have a complete extension management system built into core with its own
web interface.

-- TL;DR --

Now, my question.
Do you guys want me to build the local tool in PHP as a maintenance
script or in node.js?

Actually perhaps I should instead ask "Are you guys fine if I build this
in node.js?" because I have a feeling this will be hell to develop if I
have to write it in PHP.

PHP Pros:
- We could bundle this with MediaWiki core if people like it.
- You don't need to install Node.js (though it's not 'that' hard).

PHP Cons:
- Every time I've tried using PHP proc functions I've had to spend
endless time debugging. And this tool requires dozens of proc calls.
- The tool is going to be difficult to access until at least the next
MediaWiki version, since it won't be bundled.
-- It may end up useless for a bunch of people right now when it's
supposed to help.
-- It may also end up locked down so only users with more recent
installations of MediaWiki may use it (

Node.js Pros:
- Once you have node, getting the tool will be as trivial as `[sudo] npm
install -g mediawiki-...something...`.
- The tool will be available for and should work on any MediaWiki
version you can get a current extension to work on, not just future
releases.
- Executing git and composer from node to download things is trivial.
-- I not only expect it to be easy, I'm already doing it. The server
code is Node.js and is already happily chugging away fetching all our
gerrit based git repos, doing multiple in parallel.
- I could make parts of the tool interactive and much more user friendly.

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fix problem with CollapsibleVector

[Thomas Mulhall]

Bump. 

 On Monday, 9 February 2015, 19:34, Thomas Mulhall 
 wrote:
   

 Bump 

 On Monday, 9 February 2015, 19:34, Thomas Mulhall 
 wrote:
   

   Hi could I have some help to fix a problem that a user reported on the 
extension talk page. The talk page is at 
http://www.mediawiki.org/wiki/Extension_talk:CollapsibleVector and the title is 
flickering. I am not sure how to fix the problem I was wandering if someone on 
here knew how to fix the problem. the source code is at 
https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector



   
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] .js errors in Metrolook skins

[Thomas Mulhall]

Bump. 

 On Tuesday, 10 February 2015, 14:02, Thomas Mulhall 
 wrote:
   

  Hi I am getting js script errors in Metrolook skin. The error is in 
$(document).click(function(e) {
 if (!$(e.target).closest('#'+openDiv).length) {
  toggleDiv(openDiv);
 }
});
and error says Object expected.
Source code is at 
https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook and 
https://github.com/paladox/Metrolook 
If I have to split js script out of the MetrolookTemplate.php could I have some 
help to do that please thanks.  

   
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Vendro api in MediaWiki

[Thomas Mulhall]

Bump. 

 On Thursday, 12 February 2015, 19:50, Thomas Mulhall 
 wrote:
   

  Hi does vendor have an api like the extension api which tells you name of the 
extension and version. Because I have ask for WikiApriary to support vendor in 
there tracking wiki site and they are asking for the api.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

[Nuria Ruiz]

> In general I'm in favor of more ad-hoc project-specific teams rather than
completely siloing every service to the Services group, or every mobile UI
to the Mobile group.=
Agreed, as long as everyone deploying services communicates through
services team so there is no duplication of solutions.
We should have 1 routing layer, standard monitoring and standard caching as
it is been pointed out before. Specifics of services might be different but
it seems the core mission of service team to provide common infrastructure,
right?.
That means that the 1st service we develop will be more work for services
team than subsequent services. *Ideally* the mobile team should develop the
service without having to solve (for example) any caching problems that are
not mobile specific.





On Wed, Feb 4, 2015 at 3:04 PM, James Douglas 
wrote:

> > In general I'm in favor of more ad-hoc project-specific teams rather than
> completely siloing every service to the Services group, or every mobile UI
> to the Mobile group.
>
> I strongly agree.  Based on experience on both sides of this spectrum, I
> recommend (when feasible) favoring feature teams over functional teams.
>
> On Wed, Feb 4, 2015 at 3:00 PM, Brion Vibber 
> wrote:
>
> > I think the way we'd want to go is roughly to have a *partnership
> between*
> > the Services and Mobile teams produce and maintain the service.
> >
> > (Note that the state of the art is that Mobile Apps are using Mobile
> Web's
> > MobileFrontend extension as an intermediate API to aggregate & format
> page
> > data -- which basically means Max has done the server-side API work for
> > Mobile Apps so far.)
> >
> > I'd expect to see Max and/or someone else from the Mobile team
> > collaborating with the Services team to create what y'all need:
> > 1) something that does what Mobile Apps needs it to...
> > 2) and can be maintained like Services needs it to.
> >
> > In general I'm in favor of more ad-hoc project-specific teams rather than
> > completely siloing every service to the Services group, or every mobile
> UI
> > to the Mobile group.
> >
> > -- brion
> >
> > On Wed, Feb 4, 2015 at 2:29 PM, Corey Floyd 
> wrote:
> >
> > > On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke 
> > > wrote:
> > >
> > > > Regarding general-purpose APIs vs. mobile: I think mobile is in some
> > > ways a
> > > > special case as their content transformation needs are closely
> coupled
> > > with
> > > > the way the apps are presenting the content. Additionally, at least
> > until
> > > > SPDY is deployed there is a strong performance incentive to bundle
> > > > information in a single response tailored to the app's needs. One
> > > strategy
> > > > employed by Netflix is to introduce a second API layer
> > > > <
> > > >
> > >
> >
> http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html
> > > > >
> > > > on
> > > > top of the general content API to handle device-specific needs. I
> think
> > > > this is a sound strategy, as it contains the volatility in a separate
> > > layer
> > > > while ensuring that everything is ultimately consuming the
> > > general-purpose
> > > > API. If the need for app-specific massaging disappears over time, we
> > can
> > > > simply shut down the custom service / API end point without affecting
> > the
> > > > general API.
> > > >
> > >
> > >
> > > I can definitely understand that motivation for providing mobile
> specific
> > > service layer - so if the services team wants to implement the API in
> > this
> > > way and support that architecture, I am totally on board.
> > >
> > > My remaining hesitation here is that from the reading of this proposal,
> > the
> > > mobile team is the owner of implementing this service, not the services
> > > team (Maybe I am misreading?).
> > >
> > > This leads me to ask questions like:
> > > Why is the mobile apps team investigating which is the best server side
> > > technology? That seems outside of our domain knowledge.
> > > Who will be responsible for maintaining this code?
> > > Who will be testing it to make sure that is performant?
> > >
> > > I'm new, so maybe these answers are obvious to others, but to me they
> > seem
> > > fuzzy when responsibilities are divided between two teams.
> > >
> > > I would propose that this be a project that the Services Team owns. And
> > > that the Mobile Apps Team defines specs on what they need the new
> service
> > > to provide.
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

[Wikitech-l] Vendro api in MediaWiki

[Thomas Mulhall]

 Hi does vendor have an api like the extension api which tells you name of the 
extension and version. Because I have ask for WikiApriary to support vendor in 
there tracking wiki site and they are asking for the api.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New feature: tool edit

[Pine W]

I think bot edits are most closely aligned with fully automated editing.
Perhaps "semi-automated edit" would work.

Pine
On Feb 12, 2015 10:34 AM, "Marc A. Pelletier"  wrote:

> On 15-02-12 01:13 AM, Pine W wrote:
>
>> What would it take to implement a new "tool edit flag" userright
>>
>
> In the time-honored spirit of bikeshedding, I'd suggest that the right
> name for this is "automated edit" rather than "tool edit".
>
> -- Marc
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New feature: tool edit

[Marc A. Pelletier]

On 15-02-12 01:13 AM, Pine W wrote:

What would it take to implement a new "tool edit flag" userright


In the time-honored spirit of bikeshedding, I'd suggest that the right 
name for this is "automated edit" rather than "tool edit".


-- Marc


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Who moved my cheese?

[Andrew Garrett]

On Thu, Feb 12, 2015 at 6:08 PM, Chris Steipp  wrote:

> * please fail in a way that tells the user what went wrong
>

This is my most important point.

I don't mind changing the code I write to conform to new (improved!) ways
of doing things. I think those who are writing configuration objects and
extension managers and libraryizing and serviceizing and generally
improving our code and eliminating technical debt are doing the
(figurative) Lord's Work.

Just, make it so that if I do things the "Old Way", I find out in an
obvious way that there is a New Way, and you don't waste hours of my time
trying to find out what changed.

As much as possible, I think we should rely on useful error messages and
obvious signs in the code that something has changed, not required reading.
I don't want to have to do homework to do my job – if people move my cheese
then I'd like them to at least leave a note telling me where it's been
moved to.

The point of removing technical debt is that it improves engineer
productivity – if you make engineers spend hours reading mailing lists and
tracing bugs then those benefits dissipate.


— Andrew Garrett
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Who moved my cheese?

[Chris Steipp]

I don't think we need to announce every change that requires running
update.php-- that's pretty common, and (most importantly, imho) the
error messages you get when that happens make it pretty obvious what
you need to do.

But +1 for standardizing where breaking changes are announced. I hit
the issue yesterday with profiling. It's been updated, the change
wasn't announced on wikitech-l, and the wiki page about it is wrong.
So I'd also like to also suggest that if you make a breaking change:
* please make sure mediawiki.org is updated to reflect the change
* please fail in a way that tells the user what went wrong

I know I'm guilty of making breaking changes that don't comply with
this, so I'm preaching to myself too. But I think that would generally
help.

On Thu, Feb 12, 2015 at 6:18 AM, Amir E. Aharoni
 wrote:
> I do have a lot of respect towards the people who work on modularization
> and librarizatin and vagrant and all that, but yes - I generally agree.
> There's the API mailing list, and many emails on it are about breaking
> changes, but it has relatively low traffic in general, so it's OK to mix
> it. Wikitech-L has very high traffic, and as Andrew says, such
> announcements can get lost, if they are sent at all. So a separate
> MediaWiki-breaking-changes-L list sounds quite reasonable to me.
>
> And I offer some simple yardsticks for defining a "breaking change":
> * It's definitely a breaking change if your local site stops working after
> running `git pull`.
> * It's definitely a breaking change if it's in core or in an extension used
> by Wikimedia, and it requires running any of the following:
> ** update.php
> ** composer update (not every minor new version of an external library, but
> a MediaWiki feature that depends on that new version)
> * It's definitely a breaking change if it's in core or in an extension used
> by Wikimedia, and it requires changing Git configuration.
>
> Other suggestions are welcme.
>
> A recent example of such change is the series of changes in the way that
> skins' source is managed. It broke my installation several times and I had
> to figure out how to change LocalSettings myself time after time. The
> result was pretty awesome, because modularization is usually a good thing,
> but I don't remember that the changes were announced in a way that was
> convenient, at least to me.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> 2015-02-12 15:40 GMT+02:00 Andrew Garrett :
>
>> Hey folks,
>>
>> I'd to modestly propose that we talk about managing/announcing breaking
>> changes to core MediaWiki architecture.
>>
>> I want to have this chat because I spent an hour or two yesterday trying to
>> figure out why changing default configuration options for an extension in
>> MyExtension.php wasn't working. Apparently, now, you also have to change it
>> in extension.json for it to work on Vagrant.
>>
>> I understand that this was a change that was announced on wikitech-l, but I
>> don't think that I'm the only one who thinks that reading wikitech-l isn't
>> a good use of time, compared to, say, doing my job (irony upon ironies, I
>> know). If you want to change the way that things have worked for 11 years,
>> then making engineers understand what they need to do differently is your
>> responsibility, not mine.
>>
>> So, besides huffing and puffing, I have two small proposals:
>>
>> 1. We should have a low-volume list/RSS feed/twitter account/something
>> where we announce major breaking changes like this, that doesn't involve
>> reading 20 emails per day of other stuff that doesn't affect the way I do
>> my job.
>>
>> 2. If we make breaking changes, the change should be really obvious so that
>> I can't spend hours trying to find out what changed.
>>
>> For example, when we did the i18n JSON migration (everybody seems to love
>> JSON these days), and I went to change/add a message, I found that the
>> message file was a completely different format, and I was clued in straight
>> away to the fact that something was different.
>>
>> By contrast, in this case, the way I'd done things for years suddenly
>> stopped working. I've heard it justified in this particular case that this
>> is just a transition period; but it's not just a transition period for
>> code, it's a transition period for practices, and therefore it's the time
>> when it should be the LEAST confusing for engineers who don't care about
>> your refactoring, not the MOST confusing.
>>
>>
>> — Andrew Garrett
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l maili

[Wikitech-l] Abandoned Labs tools

[Mr. Donald J. Fortier II]

Please comment on 
https://meta.wikimedia.org/wiki/Requests_for_comment/Abandoned_Labs_tools that 
I created per https://phabricator.wikimedia.org/T87730 to create a process for 
usurping or otherwise being added as a maintainer to existing tools which 
appear to be abandoned.  As Coren points out,  the following three questions 
need some consideration:   
   - Under what criteria are tools considered "abandoned" and subject to being 
handed to someone else?
   - To whom are abandoned tools handed over?
   - What happens to credentials a tool may hold (for instance, bot accounts, 
OAUTH secrets, etc).
 I've also requested that a one-liner about this topic be added to the next 
tech news 
https://meta.wikimedia.org/w/index.php?title=User_talk:Guillaume_%28WMF%29&diff=11249286&oldid=10912536
 
 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Who moved my cheese?

[Pine W]

There is the https://lists.wikimedia.org/mailman/listinfo/wikitech-announce
email list which perhaps could be used for emailing the weekly tech
newsletters and major changes.

Pine
On Feb 12, 2015 7:25 AM, "C. Scott Ananian"  wrote:

> In addition to (even better than?) a breaking-changes list would be for
> every piece of software we distribute to have a very prominent ChangeLog
> (or RELEASE-NOTES) file, which is kept up to date.  When you git pull and
> see a change to ChangeLog, that should be a clue to check out whether you
> need to update.php/npm install/composer update/etc.
>
> Mediawiki core is pretty good about this, but almost too much so -- the
> RELEASE-NOTES gets so big it's hard to see the latest thing that broke.
> For most projects it's best if the very top of the ChangeLog has the most
> recent breaking changes.
>  --scott
>
> On Thu, Feb 12, 2015 at 9:18 AM, Amir E. Aharoni <
> amir.ahar...@mail.huji.ac.il> wrote:
>
> > I do have a lot of respect towards the people who work on modularization
> > and librarizatin and vagrant and all that, but yes - I generally agree.
> > There's the API mailing list, and many emails on it are about breaking
> > changes, but it has relatively low traffic in general, so it's OK to mix
> > it. Wikitech-L has very high traffic, and as Andrew says, such
> > announcements can get lost, if they are sent at all. So a separate
> > MediaWiki-breaking-changes-L list sounds quite reasonable to me.
> >
> > And I offer some simple yardsticks for defining a "breaking change":
> > * It's definitely a breaking change if your local site stops working
> after
> > running `git pull`.
> > * It's definitely a breaking change if it's in core or in an extension
> used
> > by Wikimedia, and it requires running any of the following:
> > ** update.php
> > ** composer update (not every minor new version of an external library,
> but
> > a MediaWiki feature that depends on that new version)
> > * It's definitely a breaking change if it's in core or in an extension
> used
> > by Wikimedia, and it requires changing Git configuration.
> >
> > Other suggestions are welcme.
> >
> > A recent example of such change is the series of changes in the way that
> > skins' source is managed. It broke my installation several times and I
> had
> > to figure out how to change LocalSettings myself time after time. The
> > result was pretty awesome, because modularization is usually a good
> thing,
> > but I don't remember that the changes were announced in a way that was
> > convenient, at least to me.
> >
> >
> > --
> > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> > http://aharoni.wordpress.com
> > ‪“We're living in pieces,
> > I want to live in peace.” – T. Moore‬
> >
> > 2015-02-12 15:40 GMT+02:00 Andrew Garrett :
> >
> > > Hey folks,
> > >
> > > I'd to modestly propose that we talk about managing/announcing breaking
> > > changes to core MediaWiki architecture.
> > >
> > > I want to have this chat because I spent an hour or two yesterday
> trying
> > to
> > > figure out why changing default configuration options for an extension
> in
> > > MyExtension.php wasn't working. Apparently, now, you also have to
> change
> > it
> > > in extension.json for it to work on Vagrant.
> > >
> > > I understand that this was a change that was announced on wikitech-l,
> > but I
> > > don't think that I'm the only one who thinks that reading wikitech-l
> > isn't
> > > a good use of time, compared to, say, doing my job (irony upon
> ironies, I
> > > know). If you want to change the way that things have worked for 11
> > years,
> > > then making engineers understand what they need to do differently is
> your
> > > responsibility, not mine.
> > >
> > > So, besides huffing and puffing, I have two small proposals:
> > >
> > > 1. We should have a low-volume list/RSS feed/twitter account/something
> > > where we announce major breaking changes like this, that doesn't
> involve
> > > reading 20 emails per day of other stuff that doesn't affect the way I
> do
> > > my job.
> > >
> > > 2. If we make breaking changes, the change should be really obvious so
> > that
> > > I can't spend hours trying to find out what changed.
> > >
> > > For example, when we did the i18n JSON migration (everybody seems to
> love
> > > JSON these days), and I went to change/add a message, I found that the
> > > message file was a completely different format, and I was clued in
> > straight
> > > away to the fact that something was different.
> > >
> > > By contrast, in this case, the way I'd done things for years suddenly
> > > stopped working. I've heard it justified in this particular case that
> > this
> > > is just a transition period; but it's not just a transition period for
> > > code, it's a transition period for practices, and therefore it's the
> time
> > > when it should be the LEAST confusing for engineers who don't care
> about
> > > your refactoring, not the MOST confusing.
> > >
> > >
> > > — Andrew Garrett
> > > 

Re: [Wikitech-l] Who moved my cheese?

[C. Scott Ananian]

In addition to (even better than?) a breaking-changes list would be for
every piece of software we distribute to have a very prominent ChangeLog
(or RELEASE-NOTES) file, which is kept up to date.  When you git pull and
see a change to ChangeLog, that should be a clue to check out whether you
need to update.php/npm install/composer update/etc.

Mediawiki core is pretty good about this, but almost too much so -- the
RELEASE-NOTES gets so big it's hard to see the latest thing that broke.
For most projects it's best if the very top of the ChangeLog has the most
recent breaking changes.
 --scott

On Thu, Feb 12, 2015 at 9:18 AM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> I do have a lot of respect towards the people who work on modularization
> and librarizatin and vagrant and all that, but yes - I generally agree.
> There's the API mailing list, and many emails on it are about breaking
> changes, but it has relatively low traffic in general, so it's OK to mix
> it. Wikitech-L has very high traffic, and as Andrew says, such
> announcements can get lost, if they are sent at all. So a separate
> MediaWiki-breaking-changes-L list sounds quite reasonable to me.
>
> And I offer some simple yardsticks for defining a "breaking change":
> * It's definitely a breaking change if your local site stops working after
> running `git pull`.
> * It's definitely a breaking change if it's in core or in an extension used
> by Wikimedia, and it requires running any of the following:
> ** update.php
> ** composer update (not every minor new version of an external library, but
> a MediaWiki feature that depends on that new version)
> * It's definitely a breaking change if it's in core or in an extension used
> by Wikimedia, and it requires changing Git configuration.
>
> Other suggestions are welcme.
>
> A recent example of such change is the series of changes in the way that
> skins' source is managed. It broke my installation several times and I had
> to figure out how to change LocalSettings myself time after time. The
> result was pretty awesome, because modularization is usually a good thing,
> but I don't remember that the changes were announced in a way that was
> convenient, at least to me.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> 2015-02-12 15:40 GMT+02:00 Andrew Garrett :
>
> > Hey folks,
> >
> > I'd to modestly propose that we talk about managing/announcing breaking
> > changes to core MediaWiki architecture.
> >
> > I want to have this chat because I spent an hour or two yesterday trying
> to
> > figure out why changing default configuration options for an extension in
> > MyExtension.php wasn't working. Apparently, now, you also have to change
> it
> > in extension.json for it to work on Vagrant.
> >
> > I understand that this was a change that was announced on wikitech-l,
> but I
> > don't think that I'm the only one who thinks that reading wikitech-l
> isn't
> > a good use of time, compared to, say, doing my job (irony upon ironies, I
> > know). If you want to change the way that things have worked for 11
> years,
> > then making engineers understand what they need to do differently is your
> > responsibility, not mine.
> >
> > So, besides huffing and puffing, I have two small proposals:
> >
> > 1. We should have a low-volume list/RSS feed/twitter account/something
> > where we announce major breaking changes like this, that doesn't involve
> > reading 20 emails per day of other stuff that doesn't affect the way I do
> > my job.
> >
> > 2. If we make breaking changes, the change should be really obvious so
> that
> > I can't spend hours trying to find out what changed.
> >
> > For example, when we did the i18n JSON migration (everybody seems to love
> > JSON these days), and I went to change/add a message, I found that the
> > message file was a completely different format, and I was clued in
> straight
> > away to the fact that something was different.
> >
> > By contrast, in this case, the way I'd done things for years suddenly
> > stopped working. I've heard it justified in this particular case that
> this
> > is just a transition period; but it's not just a transition period for
> > code, it's a transition period for practices, and therefore it's the time
> > when it should be the LEAST confusing for engineers who don't care about
> > your refactoring, not the MOST confusing.
> >
> >
> > — Andrew Garrett
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://l

Re: [Wikitech-l] Who moved my cheese?

[Petr Bena]

Regarding "everyone loves JSON these days":

I truly, deeply, hate it.

On Thu, Feb 12, 2015 at 2:40 PM, Andrew Garrett  wrote:
> Hey folks,
>
> I'd to modestly propose that we talk about managing/announcing breaking
> changes to core MediaWiki architecture.
>
> I want to have this chat because I spent an hour or two yesterday trying to
> figure out why changing default configuration options for an extension in
> MyExtension.php wasn't working. Apparently, now, you also have to change it
> in extension.json for it to work on Vagrant.
>
> I understand that this was a change that was announced on wikitech-l, but I
> don't think that I'm the only one who thinks that reading wikitech-l isn't
> a good use of time, compared to, say, doing my job (irony upon ironies, I
> know). If you want to change the way that things have worked for 11 years,
> then making engineers understand what they need to do differently is your
> responsibility, not mine.
>
> So, besides huffing and puffing, I have two small proposals:
>
> 1. We should have a low-volume list/RSS feed/twitter account/something
> where we announce major breaking changes like this, that doesn't involve
> reading 20 emails per day of other stuff that doesn't affect the way I do
> my job.
>
> 2. If we make breaking changes, the change should be really obvious so that
> I can't spend hours trying to find out what changed.
>
> For example, when we did the i18n JSON migration (everybody seems to love
> JSON these days), and I went to change/add a message, I found that the
> message file was a completely different format, and I was clued in straight
> away to the fact that something was different.
>
> By contrast, in this case, the way I'd done things for years suddenly
> stopped working. I've heard it justified in this particular case that this
> is just a transition period; but it's not just a transition period for
> code, it's a transition period for practices, and therefore it's the time
> when it should be the LEAST confusing for engineers who don't care about
> your refactoring, not the MOST confusing.
>
>
> — Andrew Garrett
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Who moved my cheese?

[Amir E. Aharoni]

I do have a lot of respect towards the people who work on modularization
and librarizatin and vagrant and all that, but yes - I generally agree.
There's the API mailing list, and many emails on it are about breaking
changes, but it has relatively low traffic in general, so it's OK to mix
it. Wikitech-L has very high traffic, and as Andrew says, such
announcements can get lost, if they are sent at all. So a separate
MediaWiki-breaking-changes-L list sounds quite reasonable to me.

And I offer some simple yardsticks for defining a "breaking change":
* It's definitely a breaking change if your local site stops working after
running `git pull`.
* It's definitely a breaking change if it's in core or in an extension used
by Wikimedia, and it requires running any of the following:
** update.php
** composer update (not every minor new version of an external library, but
a MediaWiki feature that depends on that new version)
* It's definitely a breaking change if it's in core or in an extension used
by Wikimedia, and it requires changing Git configuration.

Other suggestions are welcme.

A recent example of such change is the series of changes in the way that
skins' source is managed. It broke my installation several times and I had
to figure out how to change LocalSettings myself time after time. The
result was pretty awesome, because modularization is usually a good thing,
but I don't remember that the changes were announced in a way that was
convenient, at least to me.


--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬

2015-02-12 15:40 GMT+02:00 Andrew Garrett :

> Hey folks,
>
> I'd to modestly propose that we talk about managing/announcing breaking
> changes to core MediaWiki architecture.
>
> I want to have this chat because I spent an hour or two yesterday trying to
> figure out why changing default configuration options for an extension in
> MyExtension.php wasn't working. Apparently, now, you also have to change it
> in extension.json for it to work on Vagrant.
>
> I understand that this was a change that was announced on wikitech-l, but I
> don't think that I'm the only one who thinks that reading wikitech-l isn't
> a good use of time, compared to, say, doing my job (irony upon ironies, I
> know). If you want to change the way that things have worked for 11 years,
> then making engineers understand what they need to do differently is your
> responsibility, not mine.
>
> So, besides huffing and puffing, I have two small proposals:
>
> 1. We should have a low-volume list/RSS feed/twitter account/something
> where we announce major breaking changes like this, that doesn't involve
> reading 20 emails per day of other stuff that doesn't affect the way I do
> my job.
>
> 2. If we make breaking changes, the change should be really obvious so that
> I can't spend hours trying to find out what changed.
>
> For example, when we did the i18n JSON migration (everybody seems to love
> JSON these days), and I went to change/add a message, I found that the
> message file was a completely different format, and I was clued in straight
> away to the fact that something was different.
>
> By contrast, in this case, the way I'd done things for years suddenly
> stopped working. I've heard it justified in this particular case that this
> is just a transition period; but it's not just a transition period for
> code, it's a transition period for practices, and therefore it's the time
> when it should be the LEAST confusing for engineers who don't care about
> your refactoring, not the MOST confusing.
>
>
> — Andrew Garrett
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Bryan Tong Minh]

On Wed, Feb 11, 2015 at 12:22 AM, David Gerard  wrote:

> On 10 February 2015 at 23:19, Bryan Tong Minh 
> wrote:
>
> > In fact I would prefer to go to a less restrictive license, but that is
> > probably not worth the fight.
>
>
> And is also infeasible. For a web service. GPL is effectively weak
> copyleft already; I think that's quite weak enough. (As I noted, there
> is no actual evidence that permissive licenses secure more
> contributions than copyleft, and some evidence the other way; despite
> fans of permissive licenses repeating the claims ad nauseam over the
> last fifteen years, they're notably short on examples.)
>
> I am not particularly convinced that for many MediaWiki contributors the
choice of license was a factor when starting to contribute to MediaWiki. In
any case, as you state, the GPL as applied to MediaWiki is already very
weakly copyleft, leaving us only the disadvantage of incompatibility with
non-GPL projects, with the advantages of copyleft non-existent for the
MediaWiki case.


Bryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Who moved my cheese?

[Andrew Garrett]

Hey folks,

I'd to modestly propose that we talk about managing/announcing breaking
changes to core MediaWiki architecture.

I want to have this chat because I spent an hour or two yesterday trying to
figure out why changing default configuration options for an extension in
MyExtension.php wasn't working. Apparently, now, you also have to change it
in extension.json for it to work on Vagrant.

I understand that this was a change that was announced on wikitech-l, but I
don't think that I'm the only one who thinks that reading wikitech-l isn't
a good use of time, compared to, say, doing my job (irony upon ironies, I
know). If you want to change the way that things have worked for 11 years,
then making engineers understand what they need to do differently is your
responsibility, not mine.

So, besides huffing and puffing, I have two small proposals:

1. We should have a low-volume list/RSS feed/twitter account/something
where we announce major breaking changes like this, that doesn't involve
reading 20 emails per day of other stuff that doesn't affect the way I do
my job.

2. If we make breaking changes, the change should be really obvious so that
I can't spend hours trying to find out what changed.

For example, when we did the i18n JSON migration (everybody seems to love
JSON these days), and I went to change/add a message, I found that the
message file was a completely different format, and I was clued in straight
away to the fact that something was different.

By contrast, in this case, the way I'd done things for years suddenly
stopped working. I've heard it justified in this particular case that this
is just a transition period; but it's not just a transition period for
code, it's a transition period for practices, and therefore it's the time
when it should be the LEAST confusing for engineers who don't care about
your refactoring, not the MOST confusing.


— Andrew Garrett
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Cross-wiki template

[Petr Bena]

OK Thanks

On Thu, Feb 12, 2015 at 1:43 PM, Quim Gil  wrote:
> On Thu, Feb 12, 2015 at 1:32 PM, Petr Bena  wrote:
>>
>> Is it possible to use template from english wikipedia on a different
>> wiki (meta in this case)? Something like {{w:Template}}.
>>
>
> Not possible in Wikimedia today.
>
> See also
>
> We need a common repository for Scribunto modules and templates
> https://phabricator.wikimedia.org/T52329
>
> This missing feature and the equivalent for gadgets (
> https://phabricator.wikimedia.org/T31272) are in my very humble opinion a
> source of a big waste of volunteer time and a big loss of quality across
> hundreds of Wikimedia projects. Any help pushing these features closer to
> the prioritization queues is well invested. I wish I would have been more
> successful lobbying...
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Cross-wiki template

[Quim Gil]

On Thu, Feb 12, 2015 at 1:32 PM, Petr Bena  wrote:
>
> Is it possible to use template from english wikipedia on a different
> wiki (meta in this case)? Something like {{w:Template}}.
>

Not possible in Wikimedia today.

See also

We need a common repository for Scribunto modules and templates
https://phabricator.wikimedia.org/T52329

This missing feature and the equivalent for gadgets (
https://phabricator.wikimedia.org/T31272) are in my very humble opinion a
source of a big waste of volunteer time and a big loss of quality across
hundreds of Wikimedia projects. Any help pushing these features closer to
the prioritization queues is well invested. I wish I would have been more
successful lobbying...
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Cross-wiki template

[Petr Bena]

Could you please tell me just if it's possible on wikimedia sites now? (Yes/No)

If yes, please tell me how.

On Thu, Feb 12, 2015 at 1:39 PM, Ricordisamoa
 wrote:
> The mechanism you described is controlled by $wgEnableScaryTranscluding
> .
> See https://phabricator.wikimedia.org/T52329 for a Wikimedia implementation
> instead.
>
> Il 12/02/2015 13:32, Petr Bena ha scritto:
>
>> Hi,
>>
>> Is it possible to use template from english wikipedia on a different
>> wiki (meta in this case)? Something like {{w:Template}}.
>>
>> I couldn't find this anywhere. I don't want to export it, I want to be
>> able to change it on 1 wiki so that change gets everywhere else as
>> well.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Cross-wiki template

[Ricordisamoa]

The mechanism you described is controlled by $wgEnableScaryTranscluding 
.
See https://phabricator.wikimedia.org/T52329 for a Wikimedia 
implementation instead.


Il 12/02/2015 13:32, Petr Bena ha scritto:

Hi,

Is it possible to use template from english wikipedia on a different
wiki (meta in this case)? Something like {{w:Template}}.

I couldn't find this anywhere. I don't want to export it, I want to be
able to change it on 1 wiki so that change gets everywhere else as
well.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Cross-wiki template

[Petr Bena]

Hi,

Is it possible to use template from english wikipedia on a different
wiki (meta in this case)? Something like {{w:Template}}.

I couldn't find this anywhere. I don't want to export it, I want to be
able to change it on 1 wiki so that change gets everywhere else as
well.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New feature: tool edit

[Petr Bena]

In my opinion this is pretty easy to implement so to answer "what
would it take": few hours of coding.

@Gerard: I would like to make this change to mediawiki core, so it
would work everywhere. Question now is:

* Do we want to implement tool edit?
* Do we want to use thing made by "This that and other" and Anomie instead?
* Do we want to use both tool edit and thing made by "This that and
other" and Anomie - I am personally for this option because I consider
both things to be very different

On Thu, Feb 12, 2015 at 8:20 AM, Gerard Meijssen
 wrote:
> Hoi,
> What does this have to do with English Wikipedia ? It is useful
> everywhere.. Why limit the scope ?
> Thanks,
>  GerardM
>
> On 11 February 2015 at 10:33, Petr Bena  wrote:
>
>> Yes, the question is however, if this passed "consensus" on english
>> wikipedia and I made a patch for mediawiki, assuming code would be
>> correct would it be merged to core of mediawiki or is there any other
>> requirement? Does it actually even need to pass consensus on
>> wikipedia? I think this would be useful for other wikis as well. We
>> already have bot flag and most of smaller wikis have no bots.
>>
>> On Wed, Feb 11, 2015 at 10:10 AM, Pine W  wrote:
>> > Definitely worth discussing. For ENWP, I suggest bringing this up on
>> VP:T.
>> >
>> > Thanks,
>> > Pine
>> > On Feb 11, 2015 12:45 AM, "Petr Bena"  wrote:
>> >
>> >> Hi,
>> >>
>> >> I think I proposed this once but I forgot the outcome.
>> >>
>> >> I would like to implement a new feature called "tool edit" it would be
>> >> pretty much the same as "bot edit" but with following differences:
>> >>
>> >> -- Every registered user would be able to flag edit as tool edit (bot
>> >> needs special user group)
>> >> -- The flag wouldn't be intended for use by robots, but regular users
>> >> who used some automated tool in order to make the edit
>> >> -- Users could optionally mark any edit as tool edit through API only
>> >>
>> >> The rationale is pretty clear: there is a number of tools, like AWB
>> >> and many others that produce incredible amounts of edits every day.
>> >> They are spamming recent changes page -
>> >> https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered
>> >> out and most of regular users are not interested in them. This would
>> >> make it possible to filter them out and it would also make it easier
>> >> to figure out how many "real edits" some user has made, compared to
>> >> automated edits made by tools.
>> >>
>> >> Is it worth implementing? I think yes, but not so sure.
>> >>
>> >> Thanks
>> >>
>> >> ___
>> >> Wikitech-l mailing list
>> >> Wikitech-l@lists.wikimedia.org
>> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l