[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator

[David Gerard]

Can I just note that however you word it, closing volunteers' good
faith bugs because nobody is available from the organisation right now
is an excellent way to get them never to file a bug again.


- d.

On Mon, 27 Feb 2023 at 12:02, Jaime Crespo  wrote:
>
> Hi,
>
>
> On Fri, Feb 24, 2023 at 4:32 PM Brian Wolff  wrote:
>>
>> If i could change the priority field i would probably change it to be only:
>> * unbreak now
>> * work on next (or "urgent")
>> * normal
>> * no intention to fix (aka lowest)
>
>
> I support this, but we should be careful about the wording. The problem with 
> lowest is that is has negative connotations that I would like to avoid- that 
> is why I proposed to name the above levels:
> * unbreak now
> * very high ("urgent" works too)
> * high (equivalent to work on next)
> (* normal) this would be optional, but in case we want to keep 5 categories
> * low (no intention to fix, old lowest)
>
> While this seems to be an inflation of the name usage, the original issue, 
> and the one I still have sometimes, is to say something is "very low", which 
> in my experience doesn't sit well for the casual reader, even if it has a 
> relatively well established meaning, and leads to people complaining and 
> getting an explanation, etc.
> --
> Jaime Crespo
> 
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] Upgrading mailman (the software behind mailing lists)

[David Gerard]

In fairness, pipermail archives were always a bit shaky - on the
occasions when an email's had to be removed from the archive
previously, it's messed up the URLs of all the other emails in that
month's archive.

But let's say it would be *nice* not to mess up the public archive
URLs if feasible :-)


- d.


On Sun, 9 Aug 2020 at 21:19, Amir Sarabadani  wrote:
>
> hmm, Links of archived discussions in private mailing lists are not as
> important as the ones in public lists, we definitely should migrate public
> mailing lists first and after that we can migrate any private mailing list
> that is okay with their links being broken (and then we remove those old
> archives to make it unaccessible to public). It probably means we need to
> keep mailman2 around for a while.
>
> On Sun, Aug 9, 2020 at 9:38 PM AntiCompositeNumber <
> anticompositenum...@gmail.com> wrote:
>
> > I would agree that it would be a good solution, except for the next
> > bullet in the same document:
> > "The above mechanism won’t work for private archives since the
> > archives are gated with password and without a Mailman 2 list, there
> > is no password. You can however import them to Mailman 3."
> >
> > Since keeping private lists private is also a requirement, that pretty
> > much means rolling our own auth system on top of Mailman 3 or creating
> > a bunch of HTTP redirect rules.
> >
> > On Sun, Aug 9, 2020 at 3:31 PM Amir Sarabadani 
> > wrote:
> > >
> > > According to the upgrade guide (
> > > https://docs.mailman3.org/en/latest/migration.html#other-considerations
> > ):
> > > "If you need your URLs for Mailman 2 archives to work, you can keep the
> > > HTML files generated for the archives around and your web server
> > > configuration for the archives intact (possibly with a notice to viewers
> > > that it is now a read-only archive, see this list
> > > <https://mail.python.org/pipermail/security-sig/> for example)."
> > >
> > > Here's an example: https://mail.python.org/pipermail/security-sig/
> > (with a
> > > notice).
> > >
> > > It means, the old archives will stay the same (and accessible/searchable
> > > with the new interface as well) but new mails won't get added there to
> > the
> > > old archives. I think that's a good compromise.
> > >
> > >
> > > On Sun, Aug 9, 2020 at 9:19 PM David Gerard  wrote:
> > >
> > > > yes - those links are thrown around as if they're archival. How will
> > > > the change affect links to past messages? Will someone need to
> > > > construct a redirect farm?
> > > >
> > > >
> > > > - d.
> > > >
> > > > On Sun, 9 Aug 2020 at 19:54, AntiCompositeNumber
> > > >  wrote:
> > > > >
> > > > > Glad to hear this is moving forward!
> > > > >
> > > > > Keeping archive links working, for both public and private lists,
> > > > > should be a requirement. There's a lot of institutional knowledge
> > > > > stored in the mailing list archives, and it's very important to keep
> > > > > that around.
> > > > >
> > > > > ACN
> > > > >
> > > > > On Sun, Aug 9, 2020 at 1:05 PM Zoran Dori 
> > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > > this looks great. Especially because of "mobile friendly" function.
> > > > > >
> > > > > > Best regards,
> > > > > > Zoran Dori
> > > > > > Volunteer on Wikimedia Foundation's projects
> > > > > > E: zorandori4...@gmail.com
> > > > > > W: kizule.tk
> > > > > > I: iamkizule <https://instagram.com/iamkizule>
> > > > > > ___
> > > > > > 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
> > >
> > >
> > >
> > > --
> > > Amir (he/him)
> > > ___
> > > 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
>
>
>
> --
> Amir (he/him)
> ___
> 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] Upgrading mailman (the software behind mailing lists)

[David Gerard]

yes - those links are thrown around as if they're archival. How will
the change affect links to past messages? Will someone need to
construct a redirect farm?


- d.

On Sun, 9 Aug 2020 at 19:54, AntiCompositeNumber
 wrote:
>
> Glad to hear this is moving forward!
>
> Keeping archive links working, for both public and private lists,
> should be a requirement. There's a lot of institutional knowledge
> stored in the mailing list archives, and it's very important to keep
> that around.
>
> ACN
>
> On Sun, Aug 9, 2020 at 1:05 PM Zoran Dori  wrote:
> >
> > Hello,
> > this looks great. Especially because of "mobile friendly" function.
> >
> > Best regards,
> > Zoran Dori
> > Volunteer on Wikimedia Foundation's projects
> > E: zorandori4...@gmail.com
> > W: kizule.tk
> > I: iamkizule 
> > ___
> > 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

Re: [Wikitech-l] What ways are there to include user-edited JavaScript in a wiki page? (threat model: crypto miners)

[David Gerard]

This is particularly important for non-Wikimedia instances of
MediaWiki, by the way.

(e.g. on RationalWiki there's a cultural thing of "everyone is a
sysop!" but the interface/JS editing rights are restricted to a much
smaller "tech" group who are trusted not to be silly)


- d.



On 19 March 2018 at 08:51, Derk-Jan Hartman
<d.j.hartman+wmf...@gmail.com> wrote:
> On a side note. Have we looked recently at decoupling the site wide
> JS/CSS rights from the edit interface right ? It has always seemed a
> bit weird to me that we had both these things in MediaWiki namespace,
> but the more we are closing down raw HTML in MediaWiki namespace, the
> weirder it becomes. Even if we would assign those rights to mostly the
> same groups, it would give some more healthy options in the long term.
> We've made a similar split in the user namespace (for much more
> practical reasons of course). But I think that shouldn't stop us from
> doing the same for global stuff.. We could even consider finding some
> way to detect raw html messages and have them subject to the same
> right..
>
> We have https://phabricator.wikimedia.org/T120886 but i'm not sure if
> anyone gave it any serious consideration in the past 2,5 years..
>
> DJ
>
>
> On Sat, Mar 17, 2018 at 6:57 PM, Alex Monk <kren...@gmail.com> wrote:
>> You'd have to stop stewards from loading site-wide JS, gadgets, as well as
>> removing their ability to have their user JS from pulling in JS from other
>> sites/users/etc. somehow.
>>
>> Trying to restrict it would probably lead to a backlash from communities
>> that would make superprotect look like a joke. I suspect that if such a
>> feature were proposed today, it would never be given to local users, but
>> reserved for globally trusted people like developers. Local sysops are not
>> necessarily (or maybe even usually) technically skilled, and communities do
>> not appear to realise the amount of power that editinterface actually gives
>> you, and that code written with it may frequently be executed by people
>> with rights that the community would consider superior, like
>> steward/oversight/checkuser/bureaucrat.
>>
>> I would not tell them not to worry about it.
>>
>> On Fri, 16 Mar 2018, 17:33 Leon Ziemba, <musikani...@wikimedia.org> wrote:
>>
>>> Sorry to slightly sidetrack this discussion, but someone recently asked me
>>> if it were possible to modify a steward's user JS so that it granted them
>>> advanced rights like steward/checkuser/oversight. This of course is
>>> possible, but very rare since you need to be a sysop to edit these JS
>>> pages. The point this person was making to me however was that on smaller
>>> wikis it can be easy to become a sysop, and it's probable that by nature
>>> stewards will show up there occasionally, and that their own personal JS
>>> may not be closely watched. I told them not to worry about it, but if we
>>> really wanted to do something, we could make a steward's JS only be mutable
>>> by other stewards (or something).
>>>
>>> Maybe something else to think about?
>>>
>>> ~Leon
>>>
>>> On Thu, Mar 15, 2018 at 5:46 PM, Eran Rosenthal <eranro...@gmail.com>
>>> wrote:
>>>
>>> > Lego already did a script to verify no external resources are loaded:
>>> > https://phabricator.wikimedia.org/T71519
>>> > I think there is a Jenkins job running it on regular basis
>>> >
>>> > On Thu, Mar 15, 2018 at 6:30 AM, MZMcBride <z...@mzmcbride.com> wrote:
>>> >
>>> > > David Gerard wrote:
>>> > > >What ways are there to include user-edited JavaScript in a wiki page?
>>> > > >
>>> > > >[...]
>>> > > >
>>> > > >You can't see it now, but it was someone including a JavaScript
>>> > > >cryptocurrency miner in common.js!
>>> > > >
>>> > > >Obviously this is not going to be a common thing, and common.js is
>>> > > >closely watched. (The above edit was reverted in 7 minutes, and the
>>> > > >user banned.)
>>> > > >
>>> > > >But what are the ways to get user-edited JavaScript running on a
>>> > > >MediaWiki, outside one's own personal usage? And what permissions are
>>> > > >needed? I ask with threats like this in mind.
>>> > >
>>> > > There's an old post of mine that documents some of the ways to inject
>>> > > site-wide JavaScript:
>>> > >

[Wikitech-l] What ways are there to include user-edited JavaScript in a wiki page? (threat model: crypto miners)

[David Gerard]

What ways are there to include user-edited JavaScript in a wiki page?

I ask because someone put this revision in (which is now deleted):

https://fa.wikipedia.org/w/index.php?title=%D9%85%D8%AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Common.js=next=22367460=en

You can't see it now, but it was someone including a JavaScript
cryptocurrency miner in common.js!

Obviously this is not going to be a common thing, and common.js is
closely watched. (The above edit was reverted in 7 minutes, and the
user banned.)

But what are the ways to get user-edited JavaScript running on a
MediaWiki, outside one's own personal usage? And what permissions are
needed? I ask with threats like this in mind.


- d.

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

Re: [Wikitech-l] [Wikimedia-l] What's making you happy this week? (Week of 4 March 2018)

[David Gerard]

On 4 March 2018 at 02:41, Pine W  wrote:

> What's making you happy this week?


Trimmed my en:wp watchlist to pages I was actually interested in and
cared about. Made a few more meaningful edits I was more interested in
this way :-)

really, if you edit with "add page to my watchlist" ticked, you'll
accumulate all sorts of pages you don't care about and that will make
your watchlist feel like work. So trim it down to take away that "oh
no" feeling!


- d.

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

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[David Gerard]

There's a pile of minor open source browsers too ... maybe redirect to a
page with a list.


- d.

On 31 August 2017 at 22:48, Neil Patel Quinn  wrote:

> Personally (because I have no expertise in thing kind of thing in my WMF
> capacity), I'd very much support this. It *would *be showing a bias towards
> Mozilla and Firefox, but I think it's entirely reasonable for us to be
> biased towards non-profit, open technology. A web with Firefox as a strong
> player is considerably more hospitable to us than one without.
>
> I agree this should be discussed in a wider forum like on Meta, but I look
> forward to supporting it there too :)
>
> On 31 August 2017 at 14:20, Fæ  wrote:
>
> > On 31 August 2017 at 21:37, bawolff  wrote:
> > > On Thu, Aug 31, 2017 at 8:14 PM, Legoktm 
> > wrote:
> > >> Hello,
> > >>
> > >> This was something that came up during "The Big Open" at Wikimania,
> when
> > >> Katherine Maher talked with Ryan Merkley (CEO of Creative Commons) and
> > >> Mark Surman (ED of Mozilla Foundation). One of the themes mentioned
> was
> > >> that our projects need to work together and support each other.
> > >>
> > >> In that vein, I'm interested in what people think about promoting
> > >> Firefox to users who are using legacy browsers that we don't support
> at
> > >> Grade A (or some other criteria). As part of the "drop IE8 on XP"
> > >> project[1] we're already promoting Firefox as the alternative option.
> I
> > >> was imagining it could be a small and unobtrusive bubble
> > >> notification[2], similar to those that Google pushes Chrome on people
> > with.
> > >>
> > >> If users use modern browsers, they're going to have better security
> > >> support, and most likely a better experience browsing Wikimedia sites
> > >> too. We'd be improving the web by reducing legacy browsers, and
> allowing
> > >> us to move forward with newer technology sooner (ideally).
> > >>
> > >> And we'd be supporting a project that is ideologically aligned with
> us:
> > >> Mozilla.
> > >>
> > >> Thoughts, opinions?
> > >>
> > >> [1] https://phabricator.wikimedia.org/T147199
> > >> [2] https://www.mediawiki.org/wiki/Bubble_notifications
> > >>
> > >> Thanks,
> > >> -- Legoktm
> > >>
> > >> ___
> > >> Wikitech-l mailing list
> > >> Wikitech-l@lists.wikimedia.org
> > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > > I'm concerned this would be seen as an inapropriate bias.
> > >
> > > Suggesting Firefox for IE8 on XP makes sense because it is basically
> > > the only option for that platform that is reasonably secure and not
> > > super obscure. Promoting firefox is general for legacy browsers seems
> > > like a slippery slope to me.
> > >
> > > Additionally, I think this is more a political than a technical
> > > decision, and one that would require consultation with the general
> > > Wikimedia community (e.g. Meta RFC).
> > >
> > > --
> > > Brian
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > +1 on appearing to be a slippery slope and benefiting from wider,
> > political, discussion.
> >
> > I've promoted Wikimedia and projects as being deliberately agnostic.
> > Strategically, locking Wikimedia into fixed relationships with other
> > organizations with their own drives and timelines, is going to
> > increase risks downstream.
> >
> > Fae
> > --
> > fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Neil Patel Quinn ,
> product analyst
> Wikimedia Foundation
> ___
> 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] Bitcoin donations

[David Gerard]

https://wikimediafoundation.org/wiki/Ways_to_Give

Thank you very much!


- d.

On 22 August 2017 at 23:58, Aran  wrote:
> If you guys had a bitcoin option in your donation form you'd get more
> donations (like from me!). I don't have any balance in paypal, but
> sending some bitcoin would be easy.
>
>
> ___
> 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] Turkey ban

[David Gerard]

On 2 May 2017 at 18:18, Ryan Kaldari  wrote:

> I think that's the first time I've heard Wikipedia described as bewitching. 
> I'll take it as a compliment.
> FWIW, I have a hard time parsing this as bad news. Someone hiring 20,000 
> professional writers to create a freely accessible (though not distributable) 
> encyclopedia is probably a net positive for humanity. I'm sure it will be 
> heavily biased on political issues and heavily censored, but I doubt that 
> will completely negate the value of the work. As an encyclopedia buff, I hope 
> I can be forgiven for being secretly a little bit excited to hear about this 
> effort. Cuba also has a state-sponsored Wikipedia competitor, EcuRed. Some of 
> the articles are dripping with propaganda, but it's coverage of Cuban history 
> and culture is actually much better than Wikipedia's (including Spanish 
> Wikipedia). If this gives China an excuse to permanently block Wikipedia, I 
> suppose it will be a net negative, but I guess we'll have to wait and see.
> You are now free to tar and feather me!


I think you've hit the key point - we need this to be released under a
proper free content license :-D

(probably increasingly off topic for the dev list ... maybe see if
they have useful changes to contribute back to MW)


- d.

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

Re: [Wikitech-l] [MediaWiki-announce] Security release 1.27.3 and 1.28.2

[David Gerard]

Does this apply only specifically to the old thing called
SyntaxHighlight_GeSHi , or also to the current thing called
SyntaxHighlight that my MW 1.27.2 shows as SyntaxHighlight 2.0?

On 30 April 2017 at 21:30, Chad Horohoe  wrote:
> Hello!
>
> I would like to announce the immediate availability of security releases
> 1.27.3
> and 1.28.2. Due to a mistake in packaging, the releases 1.27.2 and 1.28.1
> did
> not contain the fix for SyntaxHighlight_GeSHi. This new release does contain
> that fix.
>
> The task in question: https://phabricator.wikimedia.org/T158689
>
> If you are not running this extension, you do not necessarily need to
> upgrade.
>
> Thanks, and I apologize for any confusion in the matter.
>
> Full release notes:
> https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_27/RELEASE-NOTES-1.27
> https://www.mediawiki.org/wiki/Release_notes/1.27
>
> https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES-1.28
> https://www.mediawiki.org/wiki/Release_notes/1.28
>
> **
> 1.27.3
> **
> Download:
> https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz
>
> Core only, no extensions:
> https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.sig
>
> GPG signatures:
> https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz.sig
> https://releases.wikimedia.org/mediawiki/1.27/mediawiki-core-1.27.3.tar.gz.sig
>
> Public keys:
> https://www.mediawiki.org/keys/keys.html
>
> **
> 1.28.2
> **
> Download:
> https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz
>
> Core only, no extensions:
> https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.sig
>
> GPG signatures:
> https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.2.tar.gz.sig
> https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.2.tar.gz.sig
>
> Public keys:
> https://www.mediawiki.org/keys/keys.html
> ___
> MediaWiki announcements mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
> ___
> 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] [Wikipedia-l] Data centre switchover to Eqiad

[David Gerard]

Would a sitenotice for logged-in users, or at least a watchlist
notice, be a good idea?


- d.



On 30 April 2017 at 19:08, zppix e  wrote:
> Hello,  as you may or may not already know there will be a datacentre
> switch back to Eqiad, WMF's main data centre, on May 3rd at approximately
> 14:00 UTC. For approximately 20-30 minutes you will NOT be able to save
> edits to any WMF project. If you have any questions feel free to reply back
> to this email, or ask on IRC on freenode channel #wikimedia-tech. If there
> any major issues that occur during this time please report them to
> #wikimedia-tech on freenode!
>
> Thanks,
> Zppix
> Volunteer Developer for WMF
> www.enwp.org/User:Zppix
> ___
> Wikipedia-l mailing list
> wikipedi...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikipedia-l

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

Re: [Wikitech-l] Introduction

[David Gerard]

On 20 March 2017 at 01:03, MZMcBride  wrote:

> In the footer of every Wikimedia wiki, there should be a "Developers" link
> that leads to .
> You can see this link at 
> or  or
> . Suggestions for more
> places to put this link or better text to make it more obvious are always
> welcome, of course. :-)


+1 !!


- d.

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

Re: [Wikitech-l] Debian and Ubuntu packages for MediaWiki now available

[David Gerard]

Don't forget to update the wiki:

https://www.mediawiki.org/wiki/Ubuntu
https://www.mediawiki.org/wiki/Debian


- d.


On 22 September 2016 at 07:44, Legoktm  wrote:
> Hi,
>
> I'm very excited to announce that Debian and Ubuntu packages for
> MediaWiki are now available. These packages will follow the MediaWiki
> LTS schedule and currently contain 1.27.1. If you've always wanted to
> "sudo apt install mediawiki", then this is for you :)
>
> For Debian users, you can get the mediawiki package for Jessie from the
> official Debian repositories using jessie-backports, and it will be
> included in the upcoming Stretch release.
>
> Ubuntu users will need to enable a PPA for Xenial or Trusty to set up
> the package.
>
> Instructions, links, and help can all be found at
> . Please let me
> know if you have any questions or feedback.
>
> Finally, thanks to Luke Faraone, Faidon Liambotis, Moritz Mühlenhoff,
> Max Semenik, Chad Horohoe, Antoine Musso, and all of the beta testers of
> the package for making this a reality.
>
> -- Legoktm
>
> ___
> 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] Loosing the history of our projects to bitrot. Was: Acquiring list of templates including external links

[David Gerard]

On 1 August 2016 at 17:37, Marc-Andre  wrote:

> We need to find a long-term view to a solution.  I don't mean just keeping
> old versions of the software around - that would be of limited help.  It's
> be an interesting nightmare to try to run early versions of phase3 nowadays,
> and probably require managing to make a very very old distro work and
> finding the right versions of an ancient apache and PHP.  Even *building*
> those might end up being a challenge... when is the last time you saw a
> working egcs install? I shudder how nigh-impossible the task might be 100
> years from now.


oh god yes. I'm having this now, trying to revive an old Slash
installation. I'm not sure I could even reconstruct a box to run it
without compiling half of CPAN circa 2002 from source.

Suggestion: set up a copy of WMF's setup on a VM (or two or three),
save that VM and bundle it off to the Internet Archive as a dated
archive resource. Do this regularly.


- d.

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

Re: [Wikitech-l] Crediting the work of our community members

[David Gerard]

Other projects don't do this, do they? Mozilla and LibreOffice just
list *everyone* in alphabetical order. (I'm still in the Mozilla
credits list for my work on the Mozilla 1.0 FAQ in 2002:
https://www.mozilla.org/credits/ )

On 30 May 2016 at 17:40, Jon Robson  wrote:
> "I came across a patch from a user who was keen to move himself from
> "Patch contributors" to "Developers" in the MediaWiki  CREDITS file
> [1]. It had been sitting there for over a year. He doesn't seem to
> have been active since. I don't know what to do with it. It made me
> think.
>
> Do we have it documented anywhere how we use this credits file and why
> we feel the need to distinguish between Developers and Patch
> Contributors? It seems like a recipe for disaster in my opinion as it
> can only lead to hurt feelings due to contributors feeling unfairly
> treated. https://www.mediawiki.org/wiki/Special:Version/Credits leads
> with 'We would like to recognize the following persons for their
> contribution to MediaWiki." - if someone is not in that list are they
> not as important?
>
> If we keep these files we should probably explain the rules to what
> adding names looks like within these files and what the process to
> adding your name is (can I add myself? Is there a process like getting
> +2?)
>
> To take another extreme, we might consider abandoning such a file in
> favour of something automatically generated. Things like
> https://github.com/wikimedia/mediawiki/graphs/contributors do a far
> better job at allowing people to see who contributed to a tool and
> making people feel like their work is rewarded.
>
> On a slightly related note, can we abandon the practice of putting
> names inside files themselves? I see this practice in JavaScript and
> PHP files throughout core (grep for @author). As Team Geek [2] (great
> read btw) says "unlike other collaborative pieces of creative work...
> software keeps changing even after it's "done". So while listing
> contributors credits at the end of a movie is a safe and static thing,
> attempting to add and remove names from a source file is a
> never-ending exercise in insanity". For similar reasons this practice
> gives an impression of ownership of a file/code review
> responsibilities (which are not always true) and risks hurt feelings.
>
> [1] https://github.com/wikimedia/mediawiki/blob/master/CREDITS
> [2] 
> http://www.amazon.com/gp/search?index=books=qs=9781449302443
>
> ___
> 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] historical trivia: who first picked UTC as Wikimedia time, when and why?

[David Gerard]

Question about obscure historical detail: Who picked UTC as Wikimedia
time? When was this, and what was the thought process?

(the answer is almost certainly "Brion or Jimbo, early 2001, it's the
obvious choice", but I'm just curious as to details.)


- d.

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

Re: [Wikitech-l] REL1_27 branches up

[David Gerard]

On 5 May 2016 at 02:52, Chad  wrote:

> The release branches (REL1_27) have been created for MW core, vendor,
> all extensions and all skins. MediaWiki core is now on 1.28.0-alpha.


When's the first public beta and RC? (I expected to see this on the
wiki, but it just has the final release date.)


- d.

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

Re: [Wikitech-l] Mostly about anglophile devs, and a small complaint about VisualEditor

[David Gerard]

On 13 March 2016 at 20:43, Bartosz Dziewoński  wrote:

> 1. Type '{{' to open template insert dialog


... this is something I never knew existed. Thank you!


> By the way, there's a list of all available keyboard shortcuts built into
> VisualEditor – it's under the '?' button on the toolbar, or under the Ctrl+?
> shortcut :)


BTW, my favourite VE test article, [[:en:OpenOffice.org]], now takes
14 seconds to open for editing in VE. Down from 90+ in July 2013. Well
done all :-)


- d.

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

Re: [Wikitech-l] [MediaWiki-l] InstantCommons - Images disappearing again

[David Gerard]

On 4 February 2016 at 17:14, Brad Jorsch (Anomie)  wrote:

> No, it was a change in the underlying image handling code that broke API
> prop=imageinfo in 1.27.0-wmf.12. Tracked as
> https://phabricator.wikimedia.org/T125804, and now resolved.


yep, working for us now. Thanks!


- d.

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

Re: [Wikitech-l] [MediaWiki-l] InstantCommons - Images disappearing again

[David Gerard]

I came here to post about the same problem. It appears to have broken
this morning. Did the API change again?

On 4 February 2016 at 07:33, Dr. Michael Bonert
 wrote:
> In September 2014, I described an intermittent recurrent problem associated
> with the InstantCommons images.
>
> I hadn't seen the problem seen since April or May of 2015.
>
> It is now back -- after I upgraded to MediaWiki 1.26.2.
> Unlike in the past, it hasn't resolved with a server re-boot.
>
> I did have record traffic earlier in the week... but the problem --like in
> the past-- doesn't seem to be traffic related.
>
> I cannot find a relation to memory. I'm not running out of memory.
> The underlying LAMP (Debian Linux Apache MySQL PHP) stack hasn't changed.
>
> Product Versions
> Operating System: Debian (stable)
> MediaWiki   1.26.2 (f465524)
> PHP 5.6.13-0+deb8u1 (apache2handler)
> MySQL   5.5.44-0+deb8u1
>
> The details of what is installed is here:
> http://librepathology.org/wiki/index.php/Special:Version
>
> I do have git installed -- and am using it to upgrade.
>
> Like in the past-- the image that is local to the site, i.e.
> non-InstantCommons,
> (
> http://librepathology.org/wiki/index.php/File:Atypical_ductal_hyperplasia_-_very_high_mag.jpg
> )
> is still there-- and displays properly. At the same time, all the images
> from the InstantCommons are gone.
>
>
> A list of previous posts I did can be found here:
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043340.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043345.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043348.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043349.html
>
> Help on this would be much appreciated...
>
> I have a testing site (pathologyprotocols.org) that is running the exact
> same set-up (behind a login).
> It is also failing suddenly in the same way; the InstantCommons images are
> gone.
>
> I wonder whether...
> - It is the InstantCommons server
> - There is "talk" between the InstantCommons server and a MediaWiki install
> (with the InstantCommons activated).
> I know this as images that are removed from the InstantCommons... are
> then removed on then
> MediaWiki install with InstantCommons activated.
>
> I think the communication is governed by 'descriptionCacheExpiry' and
> 'apiThumbCacheExpiry'
>   https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons
>   ? I wonder whether setting those to infinity would solve anything.
> - I suspect the thumb cache is purged... and then there is a bug preventing
> the image from being
> confirmed as being the same as on the InstantCommons... or there a
> processing bottle neck as the thumbnails have to be re-created.
>
> Thanks in Advance,
> Michael
>
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

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

Re: [Wikitech-l] Forking, branching, merging, and drafts on Wikipedia

[David Gerard]

On 7 November 2015 at 00:29, Brian Wolff  wrote:

> I feel like different people want different things, and what is really
> needed is a user-centric discussion of use-cases to drive a feature
> wishlist, not any sort of discussion about implementation.


Yes. I see the rationaie in that Phabricator ticket, but it reads like
personal ideology without reference to the Wikimedia projects. What is
the use case?


- d.

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

Re: [Wikitech-l] Code of Conduct: Intro, Principles, and Unacceptable behavior sections

[David Gerard]

The first and last paras are particularly worth quoting:

> Earlier this year I pulled out of a conference because the organiser and I 
> disagreed on code of conducts. Specifically I thought there should be one, 
> and he did not. He did eventually add one, but refused to define unacceptable 
> behaviour. Myself and another woman pulled out.

...

> I don’t feel safe because there is a code of conduct. But I tell you one 
> thing that makes me feel unsafe – men who will endlessly, vociferously argue 
> against them. Maybe a code of conduct isn’t meaningful. But at this point, 
> refusing to listen, refusing to have one. Well, that is.


- d.



On 5 September 2015 at 23:07, Oliver Keyes  wrote:
> On the general subject of codes of conduct and what they bring (or
> don't bring) in terms of user safety and a sense of inclusion, I
> recently encountered
> http://www.catehuston.com/blog/2015/09/02/code-of-conducts-and-worthless-manfeelings/
> on Twitter - it's an interesting read and brings up a couple of points
> definitely worth thinking about, namely that the intent behind a CoC
> is not to be the be-all and end-all of user safety but instead to set
> a very minimum bound of what is acceptable.
>
> On 5 September 2015 at 17:39, Oliver Keyes  wrote:
>> Why don't you comment on any of the three links provided in the email
>> you're replying to? That seems like an obvious venue for concerns you
>> might have.
>>
>> On 5 September 2015 at 17:32, rupert THURNER  
>> wrote:
>>> On Fri, Sep 4, 2015 at 10:37 PM, Matthew Flaschen 
>>> wrote:
>>>
 There is consensus at

 https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft#Next_steps
 that the best way to finalize the CoC draft is to focus on a few
 sections at once (while still allowing people to comment on other
 ones).  This allows progress without requiring people to monitor all
 sections at once and lets us separate the questions of “what are our
 goals here?” and “how should this work?”.  After these sections are
 finalized, I recommend minimizing or avoiding later substantive
 changes to them.

 The first sections being finalized are the intro (text before the
 Principles section), Principles, and Unacceptable behavior.  These
 have been discussed on the talk page for the last two weeks, and
 appear to have stabilized.

 However, there may still be points that need to be refined. Please
 participate in building consensus on final versions of these sections:

 *
 https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft

 *
 https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft

 If you are not comfortable contributing to this discussion under your
 name or a pseudonym, you can email your feedback or suggestions to
 conduct-discuss...@wikimedia.org .  Quim Gil, Frances Hocutt, and
 Kalliope Tsouroupidou will be monitoring this address and will
 anonymously bring the points raised into the discussion at your
 request.


>>> lol, consensus among whom, to what? i am against it (i'd love to send the
>>> reasons in another mail though), do i count, and it is still consensus?
>>> probably not, because i did maybe two unimportant commits for kiwix. i
>>> would prefer if you would be so kind to define one measurable criteria for
>>> the question "do we need a code of conduct", no matter if entry or success
>>> criteria. e.g
>>>
>>> * 50 volunteers from different part of the world saying that we need it
>>> * 20% of committers want it
>>> * after one year 20% more volunteer commits are done
>>>
>>> other critieria like "people attending conferences", or "mails written"
>>> would be a bad idea, as the goal is to have more contributions, not more
>>> conference tourists or mailing list tourists. what you think, matt, or quim
>>> ?
>>>
>>> best,
>>> rupert
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> Oliver Keyes
>> Count Logula
>> Wikimedia Foundation
>
>
>
> --
> Oliver Keyes
> Count Logula
> Wikimedia Foundation
>
> ___
> 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] Code of Conduct: Intro, Principles, and Unacceptable behavior sections

[David Gerard]

On 6 September 2015 at 00:11, MZMcBride  wrote:


> become so enmeshed with the ultra-liberal feminist movement. I think there


It would probably be fascinating to have this technical term defined
with any specificity.


> of this content, but I can see a lot potential allies to the code of
> conduct cause being put off by the militant feminist language and
> overeager citations of feminist theory.


The hypothetical people in question would look to any excuse in practice.


- d.

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

Re: [Wikitech-l] "Try the free Wikipedia app" banners

[David Gerard]

On 4 September 2015 at 20:12, Brandon Harris  wrote:

> So it seems to me that the apps are not required to fulfill the 
> mission.  They feel like distractions, and - quite possibly - negatives to 
> the mission (in that we can't convert Readers into Editors through the app).


It's worth stressing here that our app is really good for reading. I
have kept a gaggle of 7-8yo children amused while they were playing
"guess the animal" by calling up the animal in question on Wikipedia
on my S4 Mini, complete with that picture in the header. It was better
than trying to do the same on the website has been on the same phone
in the past. So let's not forget to give the app at least some love
:-)


- d.

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

Re: [Wikitech-l] Collaboration team reprioritization

[David Gerard]

On 4 September 2015 at 01:38, Ricordisamoa  wrote:
> Il 04/09/2015 01:24, Brandon Harris ha scritto:
>>> On Sep 3, 2015, at 4:06 PM, Ricordisamoa
>>> wrote:

>>> I appreciate the acknowledgement of failure.

>> I don't think that's what was said at all.  You may wish to
>> re-read all of this.

> Putting "active development" on hold when the software is little used in
> production and even some features a MVP should have had are missing, really
> sounds like a failure to me, although Danny has been very good at not making
> it sound like it.
> "To better address the needs of our core contributors", "we shift the team's
> focus to these other priorities", "communities that are excited about Flow
> discussions will be able to use it"



It read to me and many others like a fairly standard set of euphemisms
for when a project is killed but nobody wants to say "killed". Perhaps
we're all reading it wrong.

So, non-euphemistically: could someone please detail what, precisely,
is and is not the level of resource commitment to Flow? (And how it
compares to e.g. the level of resource commitment to LQT.)


- d.

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

Re: [Wikitech-l] Collaboration team reprioritization

[David Gerard]

On 2 September 2015 at 14:51, Risker  wrote:

> I want to thank the Collaboration team for taking this brave step - and
> yes, it's a brave step. The natural trajectory of large projects that don't
> quite seem to meet their promise is to keep going and going until everyone
> is burnt out, and it is courageous to say "this isn't going where we wanted
> it to" and break that cycle.  Most of the people who are currently involved
> in Flow and the Collaboration team were not there when it started, and they
> joined a project that had very mixed levels of support that had very
> challenging and broad objectives.  We as a community can learn a lot from
> their experience, and we really should make an effort to examine this
> project and use this experience to re-examine and improve the process of
> developing new software.



+1 - it's far better to kill it now than later.


- d.

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

Re: [Wikitech-l] Collaboration team reprioritization

[David Gerard]

On 2 September 2015 at 07:27, Dan Garry  wrote:
> On 1 September 2015 at 23:21, Federico Leva (Nemo) 
> wrote:

>> Thanks. So now we'll have two unmaintained extensions, LQT and Flow.

> To quote Danny's email directly, "Flow will be maintained and supported".
> Your supposition that the extension will be unmaintained is not correct.


As a third-party MediaWiki tarball user, I'm slightly annoyed because
RationalWIki took on LQT originally because WMF made it sound like it
was definitely the future yep no worries. As the current sysadmin I
desperately would love to set LQT on fire and put it in a bin and was
hoping Flow would be the supported option. Bah, how annoying ...

Did the stuff to port LQT threads/pages to Flow ever make it to
production quality?

OTOH, the problems outlined in this message are pretty much exactly
what experienced Wikipedia users said when Flow was started - you need
to be able to cut'n'paste slabs of wikitext (or parsoid HTML5 or
whatever VE actually copies to the clipboard) from the article to the
talk page, which means something VEish on talk too.

Talk pages are indeed an utter nightmare for usability. If I had a
plausible answer I'd be posting it.


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 23 August 2015 at 03:52, Risker risker...@gmail.com wrote:

 Perhaps more importantlywho were the local contacts at Hackathon 2015?
 I can't even dig that one up in the event documentation.
 A policy that exists but has no clear or visible support isn't worth the
 bytes it's written with.


+1

Don't forget this bit - enforcement is the difference between a policy
that does anything, and someone writing another million words of
well-meaning rules on a wiki somewhere.


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

I saw this today, I wonder if it's relevant to the thread:

http://www.perpendicularangel.com/2015/08/no-i-dont-trust-your-conference-without-a-code-of-conduct/

Of course we're talking about stuff beyond conferences, but it still
applies I'd think.


- d.

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

Re: [Wikitech-l] RFC: Replace Tidy with HTML 5 parse/reserialize

[David Gerard]

On 18 August 2015 at 04:15, MZMcBride z...@mzmcbride.com wrote:
 Brian Wolff wrote:

I dont know about that. Viz editor is targeting ordinary tasks. Its the
complex things that mess stuff up.

 In most contexts, solving the ordinary/common cases is a pretty big win.


Or when it turns a complex task into a simple one, e.g. table editing
(one click to remove a column).


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 14 August 2015 at 22:45, Matthew Flaschen mflasc...@wikimedia.org wrote:
 On 08/12/2015 06:41 PM, David Gerard wrote:
 On 12 August 2015 at 23:00, Matthew Flaschen mflasc...@wikimedia.org
 wrote:

 Enforcement is still to-be-determined.

 This does need to be sorted out ahead of time.

 See my proposal at
 https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft#First_line_of_enforcement
 .  There are some details to be refined, but I like having a single initial
 point of contact.



+1 - this looks a good start. Having *something* that can deal with
the cases you can hardly believe and yet not fall apart at the
social-mechanism gaming that wikicranks are so good at is an excellent
start.


- d.

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

Re: [Wikitech-l] Code of conduct

[David Gerard]

On 13 August 2015 at 22:30, rupert THURNER rupert.thur...@gmail.com wrote:

 Oliver,  I must be a little blind but I do not see examples of unfriendly
 behaviour in this thread.


I linked to http://kovalc.in/2015/08/12/harassers.html - perhaps that
doesn't count as unfriendly behaviour, or perhaps isn't in this
thread. It was four messages before your post in GMail, which i see
you are using; it's not clear to me how you missed it, but evidently
you did.


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 12 August 2015 at 23:00, Matthew Flaschen mflasc...@wikimedia.org wrote:

 Enforcement is still to-be-determined.


This does need to be sorted out ahead of time. Here's today's horrible example:

http://kovalc.in/2015/08/12/harassers.html


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 11 August 2015 at 00:10, MZMcBride z...@mzmcbride.com wrote:

 I'm curious which comparable organizations you're referring to.


Pretty much any open source project with an organisation. You've
already been referred to e.g. the Geek Feminism wiki on this point, so
if you haven't read up there already then it comes across as
sealioning to ask yet another person the same question.


 Is yet another page really needed?


it's been pointed out by multiple people in this thread already that
we're after a change in behaviour rather than more text, so you
bringing this up again this late comes across as I didn't hear that.


- d.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[David Gerard]

On 10 August 2015 at 14:18, MZMcBride z...@mzmcbride.com wrote:

 A proposed code of conduct like this is quite expensive to implement and
 enforce/maintain. I personally don't get the sense from reading your
 replies that you acknowledge the high cost.


In practice, EVERYONE ELSE WHO'S ADOPTED ONE hasn't found this.

In 2015, any tech organisation *without* a good, solid code of conduct
of this sort is seriously backward and questionable. It's something
you have to seriously justify not having, and so far there haven't
been serious justifications offered as to why Wikimedia is a special
snowflake in this regard.


- d.

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

Re: [Wikitech-l] Min php version

[David Gerard]

On 19 July 2015 at 19:41, Stas Malyshev smalys...@wikimedia.org wrote:

 The users should really seriously consider upgrading. 5.3 is EOL for a
 year now (which means, not even security fixes for a year) and 5.4 is
 going EOL in 2 months. If any of these sites are public-facing (and due
 to the nature of wikis, many of them, to some measure, are), running
 out-of-support software may not be that good an idea.


If this is all their host provides, however, this will in practice
lead only to never-updated MediaWiki running on never-updated PHP.


- d.

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

Re: [Wikitech-l] Min php version

[David Gerard]

On 20 July 2015 at 17:03, Greg Grossmeier g...@wikimedia.org wrote:
 quote name=David Gerard date=2015-07-20 time=12:04:55 +0100

 If this is all their host provides, however, this will in practice
 lead only to never-updated MediaWiki running on never-updated PHP.

 Not much anyone other than the host or the user can do about that.
 Certainly nothing we (MW devs and/or WMF) can.


What I'm answering is the proposal that removing support for PHP 5.3
will motivate the user to upgrade their PHP, when that isn't the case.

I recall this has been the conclusion reached on this list previously
- that this will cause problems for MW out in the world, and gain it
an unwarranted reputation for insecurity as un-upgradeable
installations get pwned. Thus, if newer MW still supports older PHP,
this results in less pwned MW. The balance is up to you, of course.


- d.

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

Re: [Wikitech-l] Yandex?

[David Gerard]

On 2 July 2015 at 20:55, Legoktm legoktm.wikipe...@gmail.com wrote:

 I am also interested in the answer to Nemo's question about whether this
 is the first piece of proprietary software ever entering use in the
 Wikimedia projects land?


[not actually relevant, but since you ask ...]

First would have been Java, back when that was non-free - with Lucene
running on it as a search engine. Then someone ported Lucene to C# so
we used that version on Mono (an all-free stack in copyright terms at
least), then Sun promised to free Java so we adopted Java before it
was actually free but while the process was underway. I recall Sun
also donated some Solaris 10 SPARC boxes which were used for various
non-core purposes. This is all off the top of my head and I welcome
historical correction.


- d.

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

Re: [Wikitech-l] Parsoid announcement: Main roundtrip quality target achieved

[David Gerard]

I didn't have anything in mind, evidently I was just vague on what the
stuff in there is and does :-)

On 26 June 2015 at 16:52, Subramanya Sastry ssas...@wikimedia.org wrote:
 On 06/25/2015 06:29 PM, David Gerard wrote:

 On 25 June 2015 at 23:22, Subramanya Sastry ssas...@wikimedia.org wrote:

 On behalf of the parsing team, here is an update about Parsoid, the
 bidirectional wikitext - HTML parser that supports  Visual Editor,
 Flow,
 and Content Translation.

 xcellent. How close are we to binning the PHP parser? (I realise
 that's a way off, but grant me my dreams.)


 The PHP parser used in production has 3 components: the preprocessor, the
 core parser, Tidy. Parsoid relies on the PHP preprocessor (access via the
 mediawiki API), so that part of the PHP parser will continue to be in
 operation.

 As noted in my update, we are working towards read views served by Parsoid
 HTML which requires several ducks to be lined up in a row. When that happens
 everywhere, the core PHP parser and Tidy will no longer be used.

 However, I imagine your question is not so much about the PHP parser ... but
 more about wikitext and templating. Since I don't want to go off on a
 tangent here based on an assumption, maybe you can say more what you had in
 mind when you asked about binning the PHP parser.

 Subbu.


 ___
 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] Parsoid announcement: Main roundtrip quality target achieved

[David Gerard]

On 25 June 2015 at 23:22, Subramanya Sastry ssas...@wikimedia.org wrote:

 On behalf of the parsing team, here is an update about Parsoid, the
 bidirectional wikitext - HTML parser that supports  Visual Editor, Flow,
 and Content Translation.

xcellent. How close are we to binning the PHP parser? (I realise
that's a way off, but grant me my dreams.)


- d.

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

Re: [Wikitech-l] GRAPH extension is now live everywhere!

[David Gerard]

Is there a facility to use this in VE?

On 6 May 2015 at 12:25, Jon Robson jdlrob...@gmail.com wrote:
 I think this is great but I'm still super super concerned about the support
 for Embedded directly with graph. I'm concerned as if used this way we
 risk making wikitext even more like code and more difficult for others to
 edit. Also having it inside the page makes it really difficult to
 extract/encourage remixing of the data...

 On Wed, May 6, 2015 at 4:32 AM, Brian Wolff bawo...@gmail.com wrote:

 On 5/5/15, Yuri Astrakhan yastrak...@wikimedia.org wrote:
  Starting today, editors can use *graph* tag to include complex graphs
 and
  maps inside articles.
 
  *Demo:* https://www.mediawiki.org/wiki/Extension:Graph/Demo
  *Vega's demo:*
 http://trifacta.github.io/vega/editor/?spec=scatter_matrix
  *Extension info:* https://www.mediawiki.org/wiki/Extension:Graph
  *Vega's docs:* https://github.com/trifacta/vega/wiki
  *Bug reports:* https://phabricator.wikimedia.org/ - project tag #graph
 
  Graph tag support template parameter expansion. There is also a Graphoid
  service to convert graphs into images. Currently, Graphoid is used in
 case
  the browser does not support modern JavaScript, but I plan to use it for
  all anonymous users - downloading large JS code needed to render graphs
 is
  significantly slower than showing an image.
 
  Potential future growth (developers needed!):
  * Documentation and better tutorials
  * Visualize as you type - show changes in graph while editing its code
  * Visual Editor's plugin
  * Animation https://github.com/trifacta/vega/wiki/Interaction-Scenarios
 
 
  Project history: Exactly one year ago, Dan Andreescu (milimetric) and Jon
  Robson demoed Vega visualization grammar 
 https://trifacta.github.io/vega/
  usage in MediaWiki. The project stayed dormant for almost half a year,
  until Zero team decided it was a good solution to do on-wiki graphs. The
  project was rewritten, and gained many new features, such as template
  parameters. Yet, doing graphs just for Zero portal seemed silly. Wider
  audience meant that we now had to support older browsers, thus Graphoid
  service was born.
 
  This project could not have happened without the help from Dan Andreescu,
  Brion Vibber, Timo Tijhof, Chris Steipp, Max Semenik,  Marko Obrovac,
  Alexandros Kosiaris, Jon Robson, Gabriel Wicke, and others who have
 helped
  me develop,  test, instrument, and deploy Graph extension and Graphoid
  service. I also would like to thank the Vega team for making this amazing
  library.
 
  --Yurik
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l


 Hmm cool.

 One of the interesting things, is you can use the API as a data
 source. For example, here is a pie graph of how images on commons
 needing categories are divided up

 https://commons.wikimedia.org/w/index.php?title=Commons:Sandboxoldid=159978060
 (One could even make that more general and have a template, which
 given a cat name, would give a pie graph of how the subcategories are
 divided in terms of number).

 --bawolff

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




 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon
 ___
 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] VisualEditor support for table copy-and-paste from Word

[David Gerard]

On 15 April 2015 at 09:38, Trevor Parscal tpars...@wikimedia.org wrote:

 I'm glad to hear VE had your back. This actually reminds me, there's a
 feature we never really advertised in VisualEditor where a CSV file can be
 dragged into the editor and a table is created from its contents.


We need a blog post about what VE is like these days. I suspect too
many people who tried it at release think it still intrinsically
sucks, and need to give it a spin again now, two years later.


 Give it a try. And thank Ed Sanders for all things tables and Copy/Paste.

In particular, listing all the cool stuff you can do with tables. You
can take out a column with a click instead of tediously going through
each line and trying not to make a mistake!! The VE is the *only* sane
way to edit tables.

Seriously, it warrants the hype these days.

And, three cheers for Ed. Hip hooray! Hip hooray! Hip hooray!


- d.

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

Re: [Wikitech-l] Maps

[David Gerard]

Looks like just a collaboration :-)

https://www.mediawiki.org/wiki/OpenStreetMap
https://meta.wikimedia.org/wiki/OpenStreetMap
https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

Obviously we should be doing our own tile rendering and serving, for example.


On 18 March 2015 at 09:09, Petr Bena benap...@gmail.com wrote:
 One foundation to rule them all? :P

 On Wed, Mar 18, 2015 at 10:06 AM, Max Semenik maxsem.w...@gmail.com wrote:
 Hi, just a quick note: as part of general search and discovery work, me and
 Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
 starting in April. Because the initial part of this work will include
 researching options which will influence precise goals and this is yet to
 be done, we still can't commit to a precise timeline, but as a ballpark
 estimate I personally want to aim for serving PNG tiles at a reasonable,
 though not necessarily dynamic maps on every WP page scale by the end of
 Q4. Vector/multilingual maps would be the next stage. We will be mostly
 using Phabricator for planning,
 https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
 the outline of things to be done.

 Your comments and suggestions would be highly appreciated, please share
 your thoughts, ideas of projects that might use these maps, or just
 merciless critique! :D

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 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

Re: [Wikitech-l] Tor proxy with blinded tokens

[David Gerard]

On 17 March 2015 at 02:55, Gergo Tisza gti...@wikimedia.org wrote:
 On Mon, Mar 16, 2015 at 5:08 PM, Daniel Friesen dan...@nadir-seen-fire.com
 wrote:

 Bitcoin is not untraceable.
 An adversary capable enough to eavesdrop on dissidents' communication
 making them need Tor should be capable of tracing the publicly available
 bitcoin transaction logs back from the payment to the proxy owner to the
 originating non-anonymous financial transaction used to purchase the
 bitcoins.

 I'll admit not knowing much about bitcoin security, but isn't that what
 mixers are for?


Pretty much nothing about Bitcoin works as advertised in the hype,
except irreversibility of transactions (which works all too well).
Everything will apparently be fixed later.


- d.

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

Re: [Wikitech-l] Global user pages deployed to all wikis

[David Gerard]

Nice one!

Will anyone be porting all the Babel templates? That's a seriously
useful thing that should go there, and they aren't on Meta yet.

On 19 February 2015 at 01:06, Legoktm legoktm.wikipe...@gmail.com wrote:
 Hello!

 Global user pages have now been deployed to all public wikis for users with
 CentralAuth accounts. Documentation on the feature is available at
 mediawiki.org[1], and if you notice any bugs please file them in
 Phabricator[2].

 Thanks to all the people who helped with the creation and deployment
 (incomplete, and in no particular order): Jack Phoenix  ShoutWiki, Isarra,
 MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped
 with testing it while it was in beta.

 [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage
 [2]
 https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ-j536clyie42uptgjkft7


 ___
 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

[David Gerard]

On 10 February 2015 at 23:19, Bryan Tong Minh bryan.tongm...@gmail.com 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.)


- d.

___
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

[David Gerard]

On 9 February 2015 at 08:28, Max Semenik maxsem.w...@gmail.com wrote:

 OpenOffice's woes are unrelated to its license, it was already dead by
 forking when Oracle transferred it to Apache, facilitating a change from
 GPL+proprietary CLA to the Apache license.



Indeed, but they touted the mythical attractiveness of a permissive
license over the bondage of copyleft. And it didn't work that way at
all in practice.

Again: data, rather than anecdote or surmise? As far as I can tell,
the claim that permissive attracts more contributions than copyleft is
entirely a myth.


- d.

___
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

[David Gerard]

On 9 February 2015 at 04:51, Rob Lanphier ro...@wikimedia.org wrote:

 Also, one cost of copyleft licenses is that they are much, much more
 complicated than permissive licenses.  Even though many people feel
 comfortable with the compliance requirements of most OSI-approved
 licenses, the permissive licenses can usually stand alone without an
 FAQ, whereas an FAQ is required for just about all of the copyleft
 licenses.  That simplicity reduces a very real barrier to adoption.



Is this statement from anecdote or data? Otherwise you need to explain
how LibreOffice (copyleft) has fifteen or so companies contributing,
whereas Apache OpenOffice (permissive) has one and even they've given
up actually paying people to work on it. The idea that permissive
works better for getting contributions seems to me completely
unevidenced.


- d.

___
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

[David Gerard]

On 8 February 2015 at 11:12, Max Semenik maxsem.w...@gmail.com wrote:
 On Sun, Feb 8, 2015 at 2:13 AM, Tyler Romeo tylerro...@gmail.com wrote:

 (Also, we actually can’t switch to the MIT license without express
 permissions from every developer who ever contributed to core anyway.)

 Same applies to AGPL.


I believe AGPL counts as an FSF-approved or later on GPL 2+.


- d.

___
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

[David Gerard]

On 7 February 2015 at 22:20, Tyler Romeo tylerro...@gmail.com wrote:

 **However**, I’d like to take this opportunity and jump a step further. What 
 would everybody think of switching to the AGPLv3 instead? The advantage that 
 this provides, for those who don’t know, is a single additional restriction: 
 when the software is used over the network, source code must still be 
 provided. In other words, the requirements all remain the same (providing a 
 copy of the source code, ensuring all modifications are also GPLed, etc.). 
 The only difference is that the requirements take effect over the Internet 
 rather than only when the software is distributed in object code form.


This would primarily affect third-party MediaWiki sites. Would a link
to http://mediawiki.org/download be sufficient for AGPL compliance?
(In the DFSG threat model of protecting a well-meaning reuser from a
vindictive author.) Or, per the letter of the license, would we be
required to keep a tarball on-site of what we're using?

Also, how does GPLv3 or AGPL affect the license of extensions?


- d.

___
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

[David Gerard]

On 7 February 2015 at 23:39, wctaiwan wctaiwan+li...@gmail.com wrote:

 IANAL, but if there is some flexibility here, I would argue that extensions
 should *not* be considered derivatives. Legally, because extensions do not
 contain MediaWiki code (beyond using the programming API provided by core
 classes);


Ah, good! Yeah, programming to a provided and documented API should be
fine. (With WordPress, themes and plugins are very much programs
running in the same process, etc.)


 in practice, because we have many extensions licensed under
 licenses that are incompatible with GPL,[1] and I don't think we should
 require people to choose a GPL-compatible licence should they want to write
 MediaWiki extensions.
 [1] http://www.mediawiki.org/wiki/Category:MIT_licensed_extensions



- d.

___
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

[David Gerard]

Cool :-)

What about extensions? Would they count as derivatives of MediaWiki
for license purposes? (I suspect they would, given Automattic regards
WordPress themes and plugins as derivatives and requires them to be
GPL.)

This would mean that, if MediaWiki went AGPL, in-house extensions
would need to be made available on the site. This would lead to people
running out-of-date MediaWiki so as not to reveal their s3kr1t sauce -
which is a terrible reason, but you know it'll happen.

I have no personal objection to AGPL and quite like the idea, but the
extensions issue springs to my mind 'cos I'm adminning a site with a
few extensions which are you can use this locally (i.e. non-free)
that I doubt I could get permission to release, and that I doubt I
could personally rewrite from scratch.

At this point I suspect we need a lawyer who knows free software
licenses weighing in. Luis, are you able to give an informal opinion
at this point in the thread? (cc'd)


- d.



On 7 February 2015 at 23:02, Tyler Romeo tylerro...@gmail.com wrote:
 Assuming they are using unmodified MediaWiki, yes a link to mediawiki.org
 would probably suffice. I am going to look more into it, but what we have
 right now (link in the footer and extension information on Special:Version)
 should fulfill compliance automatically for third parties.

 --
 Tyler Romeo
 On Feb 7, 2015 6:00 PM, David Gerard dger...@gmail.com wrote:

 On 7 February 2015 at 22:20, Tyler Romeo tylerro...@gmail.com wrote:

  **However**, I’d like to take this opportunity and jump a step further.
 What would everybody think of switching to the AGPLv3 instead? The
 advantage that this provides, for those who don’t know, is a single
 additional restriction: when the software is used over the network, source
 code must still be provided. In other words, the requirements all remain
 the same (providing a copy of the source code, ensuring all modifications
 are also GPLed, etc.). The only difference is that the requirements take
 effect over the Internet rather than only when the software is distributed
 in object code form.


 This would primarily affect third-party MediaWiki sites. Would a link
 to http://mediawiki.org/download be sufficient for AGPL compliance?
 (In the DFSG threat model of protecting a well-meaning reuser from a
 vindictive author.) Or, per the letter of the license, would we be
 required to keep a tarball on-site of what we're using?

 Also, how does GPLv3 or AGPL affect the license of extensions?


 - d.

 ___
 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

Re: [Wikitech-l] SOA in .NET, or Microsoft is going open source MIT style

[David Gerard]

Functionally. If you make a loud public declaration WE SHALL NOT SUE
then you sue, judges *tend* to look upon it very unfavourably. YMMV of
course.

On 4 February 2015 at 13:42, Nikolas Everett never...@wikimedia.org wrote:
 On Wed, Feb 4, 2015 at 5:09 AM, Yuri Astrakhan yastrak...@wikimedia.org
 wrote:

 flame war ahead

 For those not adicted to slashdot, see here
 
 http://news.slashdot.org/story/15/02/04/0332238/microsoft-open-sources-coreclr-the-net-execution-engine
 
 .

 Licenced under MIT
 https://github.com/dotnet/coreclr/blob/master/LICENSE.TXT, plus an
 additional patents promise
 https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT.


 I'm not sure how relevant it is, but are promises legally binding?
 ___
 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] Thoughts: stateless services with open servers?

[David Gerard]

On 28 January 2015 at 08:13, Daniel Friesen dan...@nadir-seen-fire.com wrote:

 We could also try convincing the semi-decent shared hosts like Dreamhost
 and Linode to run a service of their own for their customers.



Yes, reaching out to a shared hosting company or two is definitely
something to do at this stage!

Do WordPress talk to hosting companies? They may be able to offer
ideas on what hosting companies want as well.


- d.

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

Re: [Wikitech-l] I haven't looked lately...

[David Gerard]

On 19 January 2015 at 01:46, Jay Ashworth j...@baylink.com wrote:

 Aha!  Sorry; I was behind on Parsoid, was the problem.  Yeah, if there's
 a way to edit in MWtext, both for humans and programs, then that serves the
 use cases I would be concerned about.  Thanks for the prompt clarification,
 Daniel.


There's also fourteen years of legacy page versions which I think
absolutely nobody is going to convert.


- d.

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

Re: [Wikitech-l] The future of shared hosting

[David Gerard]

On 16 January 2015 at 07:38, Chad innocentkil...@gmail.com wrote:

 These days I'm not convinced it's our job to support every possible
 scale of wiki install. There's several simpler and smaller wiki solutions
 for people who can't do more than FTP a few files to a folder.


In this case the problem is leaving users and their wiki content
unsupported. Because they won't move while it works, even as it
becomes a Swiss cheese of security holes. Because their content is
important to them.

This is the part of the mission that involves everyone else producing
the sum of human knowledge. They used our software, if we're
abandoning them then don't pretend there's a viable alternative for
them. You know there isn't.


- d.

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

Re: [Wikitech-l] The future of shared hosting

[David Gerard]

On 16 January 2015 at 16:09, Antoine Musso hashar+...@free.fr wrote:

 So what we might end up with:
 - Wikimedia using the SOA MediaWiki with split components maintained by
 staff and the Wikimedia volunteers devs.  Code which is of no use for
 the cluster is dropped which would surely ease maintainability.  We can
 then reduce MediaWiki to a very thin middleware and eventually rewrite
 whatever few code is left.
 - The old MediaWiki PHP based is forked and given to the community to
 maintain.  WMF is no more involved in it and the PHP-only project live
 it's on life.  That project could be made to remove a lot of the rather
 complicated code that suits mostly Wikimedia, making MediaWiki simpler
 and easier to adjust for small installations.
 So, is it time to fork both intent?  I think so.



This is not a great idea because it makes WMF wikis unforkable in
practical terms. The data is worthless without being able to run an
instance of the software. This will functionally proprietise all WMF
wikis, whatever the licence statement.


- d.

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

Re: [Wikitech-l] The future of shared hosting

[David Gerard]

On 16 January 2015 at 17:10, Greg Grossmeier g...@wikimedia.org wrote:
 quote name=David Gerard date=2015-01-16 time=16:27:22 +

 This is not a great idea because it makes WMF wikis unforkable in
 practical terms. The data is worthless without being able to run an
 instance of the software. This will functionally proprietise all WMF
 wikis, whatever the licence statement.

 Unforkable as a binary is not true.


That's why I said functionally.


 Not easy to fork without
 implementing all of the pieces carefully is more accurate. But it's
 still possible, especially since all of the config/puppet code that is
 used to do it is open and Freely licensed.


A licence that was the GPL with the additional requirement of
attaching 1kg of gold to each copy would be technically free as well,
but present difficulties in practice.

What I'm saying is that technically is insufficient.


 It ain't easy hosting a site this large with this amount of traffic
 (thanks Ops!) so it's not surprising that forking it wouldn't be easy
 either.


However, at present low-traffic copies are pretty easy.


- d.

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

Re: [Wikitech-l] Fwd: Unsolicited digital currency donations

[David Gerard]

Yes.

1. penny-shavings for commits sets up terrible motivations.
2. these people are claiming money in developers' names without permission.
3. there's no evidence the whole thing isn't the scam it looks like.

On 9 January 2015 at 08:18, Tyler Romeo tylerro...@gmail.com wrote:
 Link for those interested:
 http://prime4commit.com/projects/208

 I really dislike these kinds of sites. It’d be one thing if it was just 
 donations, but developers can claim their tips and basically get paid for 
 each commit, and it rubs me the wrong way gameifying our volunteer community 
 like that. Then again, it’s just my opinion.

 --
 Tyler Romeo
 0x405D34A7C86B42DF

 On January 9, 2015 at 03:10:35, Federico Leva (Nemo) (nemow...@gmail.com) 
 wrote:

 Website garnering registrations by donating few cents of dollar for
 each merged commit. They started a while ago but looks like it's
 expanding. Just FYI in case you've not received one yet.

 Nemo

  Messaggio inoltrato 
 Oggetto: You received a tip for your commit
 Data: Fri, 09 Jan 2015 07:36:52 +


 Hello, Federico Leva!

 You were tipped 0.11 XPM for your commit on Project wikimedia/mediawiki.
 Please, log in and tell us your primecoin address to get it.

 Your current balance is 0.11 XPM. If you don't enter a primecoin address
 your tips will be returned to the project in 30 days.

 Sign In

 Thanks for contributing to Open Source!


 ___
 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

Re: [Wikitech-l] Stance on Social Media

[David Gerard]

I'd say: hit social media! Make MediaWiki and Wikimedia look like a
*happening place*.

Everyone [*] who runs PHP is looking seriously at HHVM right now, and
that's entirely because WMF moved to it.

The Phabricator migration made it to lwn.net, which is low-traffic but
high-quality.

Basically, cool stuff happens around here and it needs to be blogged
and tweeted and facebooked and HNed and Reddited assiduously. This
will lure more brilliant people in to work on the cool stuff that
makes the world a better place.


- d.

[*] ymmv

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

Re: [Wikitech-l] Andre's Bugzilla-Phabricator migration analysis

[David Gerard]

On 19 December 2014 at 10:45, Quim Gil q...@wikimedia.org wrote:

 Andre won't tell you, but he wrote this:
 http://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/
 The best in-depth analysis of a Bugzilla to Phabricator migration available
 in the Internet. Not that there is much competition... I'm sure it will be
 useful to someone, especially in conjunction with Chase's migration script
 and the detailed logs and tasks archived.



This also made LWN: http://lwn.net/Articles/626866/


- d.

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

Re: [Wikitech-l] MediaWiki core tests now require HHVM compliance

[David Gerard]

Is Zend PHP still tested also?

On 18 December 2014 at 17:11, Antoine Musso hashar+...@free.fr wrote:
 Hello,

 Jenkins runs the MediaWiki core unit tests under HHVM and the job will
 now prevent changes to be merged if it fails.

 Huge thanks to everyone that helped fix tests and HHVM code base!

 --
 Antoine hashar Musso


 ___
 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] All non-api traffic is now served by HHVM

[David Gerard]

On 3 December 2014 at 17:03, Giuseppe Lavagetto
glavage...@wikimedia.org wrote:

 it's been quite a journey since we started working on HHVM, and last
 week (November 25th) HHVM was finally introduced to all users who didn't
 opt-in to the beta feature.


Excellent! Excellent! Does that make us the second-largest HHVM site?

What sort of bugs needed squashing? (Is there a list, or a suitable
Phabricator query?)


 This new PHP runtime has already halved our backend latency and page
 save times, and it has also reduced significantly the load on our
 cluster (as I write this email, the average cpu load on the application
 servers is around 16%, while it was easily above 50% in the pre-HHVM era).


How is the 1.23 tarball under HHVM? Would backports of fixes be
accepted for the LTS?


- d.

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

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[David Gerard]

On 3 December 2014 at 23:08, Ryan Kaldari rkald...@wikimedia.org wrote:

 Surely we can come up with a creative idea that is:
 * Easy for humans to solve
 * Can't be solved by out-of-the-box captcha breakers
 * Isn't trivial for programmers to solve


* isn't an abomination for accessibility


- d.

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

Re: [Wikitech-l] Feature request.

[David Gerard]

On 16 November 2014 22:36, Pine W wiki.p...@gmail.com wrote:

 James: would it be possible to automatically save the text of a page to a
 user's sandbox when they encounter an edit conflict? This would overwrite
 the content of the sandbox, but that could be reverted using the normal
 history page for the sandbox.


+1 to something that achieves this effect. (Dataloss = major high-priority bug.)


- d.

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

Re: [Wikitech-l] Feature request.

[David Gerard]

On 16 November 2014 22:58, Zack Weinberg za...@cmu.edu wrote:
 On Sun, Nov 16, 2014 at 5:53 PM, Alex Monk kren...@gmail.com wrote:

 It sounds like the data loss here was purely due to user error, David.

 Don't blame the victim.


+1. This is precisely the dataloss that needs to be averted.


 Maybe we could allow saving things to a given subpage of their user page

 Users/{name}/backup/{pagetitle}/{serial number} ?  That gets rid of
 the wipes out what was there already problem.


Something like that.


- d.

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

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[David Gerard]

On 9 November 2014 09:27, aude aude.w...@gmail.com wrote:
 On Sun, Nov 9, 2014 at 8:51 AM, Pine W wiki.p...@gmail.com wrote:

 I'm curious, Risker: if you don't mind my asking, what about being required
 to supply a throwaway email address would have discouraged you from opening
 a Wikimedia account?

 I understand that it can be a bit scary to have to provide this information
 (what about a throwaway?), but yet is a tradeoff.


I realise it'd be a pile of extra work, and I'm not sure how to
present it clearly - but what about a choice between solving the
captcha or supplying a working email address?


- d.

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

Re: [Wikitech-l] JSON and Scribunto

[David Gerard]

On 4 November 2014 20:45, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote:

 * People may store data in JSON blobs that must be parsed where a module
 using mw.loadData would be more appropriate.
 * People may write templates that attempt to bypass the normal MediaWiki
 parameter handling mechanism in favor of passing a JSON blob, which would
 likely lead to page wikitext that is harder for end users to understand.



If people want a function they will write something that will do it.
Remember how ParserFunctions got an if statement? It was after
excessively creative users had cobbled together one from whatever
absolutely hideous hacks they could.

So if you know there's a demand for this, I strongly suggest thinking
hard and supplying a good implementation, else it is certain the users
will come up with a hideous one.


- d.

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

Re: [Wikitech-l] MediaWiki Technical Debt

[David Gerard]

On 23 October 2014 16:16, Jeroen De Dauw jeroended...@gmail.com wrote:

 I've looked at the code and it's quality of most of these projects at some
 point in the last two years, and have to say this graph is much in line
 with my impressions. And with what the knowledgeable people at PHP
 conferences and meetups convey. Want an example of bad code? Wordpress!
 Want one of good code? Symfony or Doctrine! Sadly enough MediaWiki seems to
 be entirely absent as a topic or even something to rant about at such
 meetups and conferences.



Wonder how Magento would do. They might have to go to log scale on the Y axis.


- d.

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

Re: [Wikitech-l] SSL 3.0 disabled on Wikimedia sites

[David Gerard]

On 17 October 2014 19:04, Mark Bergsma m...@wikimedia.org wrote:

 If you see or hear about anyone having issues connecting to our sites
 over HTTPS or logging in, please direct them at the link above, and
 urge them to upgrade their software. Unfortunately due to the nature
 of HTTPS we're not able to provide a fallback when users get an error
 message due to this. We're still looking into the possibility to
 provide affected users with an informative error message upon login
 however, before they get redirected from HTTP to HTTPS.


I believe that's it for IE6, for one. (I think the user can enable
TLS, but anyone stuck on IE6 is likely so locked down they can't do
that.)


- d.

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

Re: [Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.19, 1.22.11 and 1.23.4

[David Gerard]

Adding the space to includes/XmlTypeCheck.php before applying the
patch worked. Thank you!

On 26 September 2014 19:23, Grunny mwgru...@gmail.com wrote:
 It's because there's a leading space before the tab in front of the comment
 here:
 https://git.wikimedia.org/blob/mediawiki%2Fcore.git/REL1_19/includes%2FXmlTypeCheck.php#L22

 That leading space exists in the patch for 1.19.19, so applies fine when
 you're applying it to a fresh copy of the 1.19.18 branch. But, as it was
 introduced in the 1.19.10 release (
 https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/926b9e6) and the
 patch for the 1.19.10 release didn't include the space, if you used the
 patches for all releases since, it won't be there and the new 1.19.19 patch
 will fail to apply the first changes to that file without fixing that space
 first.

 Cheers,
 grunny
 ___
 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] Removal of Scribunto's Allow saving code with errors option

[David Gerard]

So how much broken Lua is out there in the wild on WMF wikis?

On 29 September 2014 01:17, Jackmcbarn jackmcb...@gmail.com wrote:
 Scribunto has an option to allow code to be saved even if it contains
 syntax errors that prevent it from ever working. The original reason for
 this feature was to make it more convenient to save incomplete code.
 However, in practice, this has never been used for its intended purpose,
 and users who don't know any Lua are breaking otherwise-functional modules
 with it. Because of this, and because it's easy enough to save incomplete
 code by simply wrapping it all in a multiline comment, I plan to remove the
 option unless objections are raised.

 Jackmcbarn
 ___
 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] MediaWiki Security and Maintenance Releases: 1.19.19, 1.22.11 and 1.23.4

[David Gerard]

On 24 September 2014 23:28, Markus Glaser gla...@hallowelt.biz wrote:

 Patch to previous version (1.19.18):
 https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.19.patch.gz



So I downloaded and applied this. gunzipped it, got this:

-rw-r--r--  1 root root  13663 Sep 24 21:35 mediawiki-1.19.19.patch

Applied it, and got this (on two different wikis):

# patch -p1 --dry-run  mediawiki-1.19.19.patch
patching file includes/DefaultSettings.php
patching file includes/Sanitizer.php
patching file includes/upload/UploadBase.php
patching file includes/XmlTypeCheck.php
Hunk #1 FAILED at 20.
1 out of 4 hunks FAILED -- saving rejects to file includes/XmlTypeCheck.php.rej
patching file RELEASE-NOTES-1.19
patching file tests/phpunit/includes/upload/UploadTest.php

The wikis are 1.19.18; I forget what I installed them as, but I've
been applying the differential patches as they came out. This is the
first one I've had the slightest hiccup with.

So is it just me?


- d.

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

[Wikitech-l] Fwd: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[David Gerard]

I asked this on wikimedia-l in the recent discussion with no answer. I
was wondering what the status of this feature was ...


- d.


-- Forwarded message --
From: David Gerard dger...@gmail.com
Date: 1 September 2014 18:00
Subject: Re: [Wikimedia-l] Next steps regarding WMF-community
disputes about deployments
To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org


On 1 September 2014 17:57, Martijn Hoekstra martijnhoeks...@gmail.com wrote:

 The same, by the way, goes for VE, which should have had bail and give me
 what you have now as wikitext from the onset, and Flow which needs a bail
 and convert this thread to ye olde talkpage thread (which I fear will be
 batted away as reactionary crank talk, and by the time flow will be done
 unneeded anyway)


By the way:

Is Flow going to support the use case of cut'n'pasting a piece from
the article page to the talk page, as a lump of wikitext or as a piece
of rich text from VE?

'Cos if it doesn't, I predict that will be the sticking point with the
people who actually communicate on talk pages.


- d.

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

Re: [Wikitech-l] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3

[David Gerard]

So 1.19 is officially finished?

On 27 August 2014 01:02, Markus Glaser gla...@hallowelt.biz wrote:
 Hello everyone,

 this is a notice that on 27th August between 20:00-22:00 UTC we will release 
 maintenance updates for current and legacy branches of the MediaWiki 
 software. Downloads and patches will be available at that time.

 Best,
 Markus
 Wiki Release Team

 ___
 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] User rating for beta features (was Re: Help in modifying Template:Extension to support user ratings)

[David Gerard]

As a MediaWiki tarball user, I'd *love* something to rate extensions -
even to show if anyone actually uses it and cares.

On 20 August 2014 19:14, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote:
 I fully agree with Dan on that. I'd be much more interested in +/- votes on 
 feedback statements. I think that might be a direction worth exploring. A low 
 barrier like that might help bring a more complete picture of sentiment on 
 problems and ideas.

 DJ

 On 20 aug. 2014, at 19:08, Dan Garry dga...@wikimedia.org wrote:

 On 20 August 2014 09:16, Quim Gil q...@wikimedia.org wrote:

 I'm not sure how related is this, but Article Feedback allowed user rating
 + comment, and it was deployed in Wikimedia servers. Editors didn't find it
 that useful for regular articles (too much extra work processing too little
 value feedback on top of Talk pages), but maybe this could (with small or
 not so small adaptation, I don't know) in the very specific context of a
 beta feature page.


 Speaking as someone who's been the product owner of a beta feature, I know
 I'd find a star rating for a beta feature totally useless. Star ratings
 don't tell you anything about *why* a user likes or dislikes a feature, so
 I have no information to go off.

 In terms of getting feedback from comments, you're right that that's
 useful. But I can get that right now by going to the discussion page of the
 beta feature. Bear in mind that the Hovercards talk page on mediawiki.org
 was, for a while, the most active Flow page *across the entire cluster.*

 So, I'm left a little unclear what the proposed improvement actually is.

 Dan

 --
 Dan Garry
 Associate Product Manager, Mobile Apps
 Wikimedia Foundation
 ___
 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] Not that this is reminiscent of anything anyone here works on

[David Gerard]

http://threepanelsoul.com/2014/06/02/code-maintenance/


- d.

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

Re: [Wikitech-l] extra docs in beta gadgets tab (was: superprotect; was: 'everyone who tries to speak for 'community' is censored and trying to blame it for own lack of interest')

[David Gerard]

On 16 August 2014 12:36, svetlana svetl...@fastmail.com.au wrote:

 specifically i'd like to see links to documentation on gadget  extension 
 writing
 right inside of 'gadgets' and 'beta' tabs
 somewhere in big fat banner at the bottom of each of these tabs
 'want to add your gadget/beta feature? _learn more_  _get involved_, or 
 _request an idea_'
 please give that a kick -- where? how?


+1 - point out that this stuff doesn't arrive by magic from on high,
show the machinery.


- d.

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

Re: [Wikitech-l] Bikeshedding a good name for the api.php API

[David Gerard]

Call it Bob. Bob is always a good name.


- d.

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

Re: [Wikitech-l] Bikeshedding a good name for the api.php API

[David Gerard]

 but if you are a mobile developer using the REST API
every day, you need some other term to specify api.php.

Is api.php unsuitable for some reason?


- d

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

Re: [Wikitech-l] Linux distros or Solaris for MediaWiki

[David Gerard]

Where does it say it's unsupported? Some older page, talking about the
distro version? I routinely use MW from tarball on Ubuntu and it's
fine. https://www.mediawiki.org/wiki/Debian/Ubuntu

I'd personally recommend you install the prerequisites then use the
MediaWiki tarball, but the distro 1.19 in recent versions of Ubuntu should be
good (if a bit old).

I have done MW on Solaris and it was an exercise in pain, unless you
use something that resolves dependencies for you. That is to say, a
Linux.


- d.



On 20 July 2014 20:55, Pine W wiki.p...@gmail.com wrote:
 I have experience with Ubuntu but MediaWiki says that Ubuntu is
 unsupported. Which Linux distro would people recommend, and which distro of
 Linux does WMF use for MediaWiki? I am thinking about installing Debian but
 am open to any suggestions that have a friendly UX.

 Solaris is an option also.

 Pine
 ___
 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] Winter, v. 0.6

[David Gerard]

When all the bits on the sides are actually functional *and* it works
in IE, presumably :-)

On 14 July 2014 17:40, Jon Robson jdlrob...@gmail.com wrote:
 Beautiful! When can we expect to be able to enable this as a beta
 feature and try it out on Wikipedia.org?


 On Mon, Jul 14, 2014 at 5:55 AM, Risker risker...@gmail.com wrote:
 Thanks Brandon for letting us know about this.  Since it will be many hours
 before I have a chance to make comments elsewhere, I'm going to let you
 know that, using a Win7 platform and IE9, the screen is illegible.  All
 writing is in a faint shade of grey (or blue where applicable); text
 overlaps images and infoboxes; and there's massive whitespace to the right
 of the screen.  Because of the very faint text, I can't be certain what's
 supposed to be above the title; however, what is there looks to all be
 crowded over to the right of the screen above the large amount of
 whitespace.

 I'll try to grab a screenshot and send it in.

 Risker/Anne

 On 14 July 2014 01:03, Brandon Harris bhar...@wikimedia.org wrote:


 I have uploaded a new version of the Winter framework/prototype,
 v. 0.6.

 http://unicorn.wmflabs.org/winter/

 This version has significant changes over 0.5.  The entire
 undercarriage has been refactored into a framework to allow for anyone to
 do rapid prototyping within their own copy.  The source code has been
 installed into gerrit, in the form of two depots, one of which is for
 specialized modules that change the way the prototype behaves
 (snowflakes).

 Links to the source depots are available at:


 https://www.mediawiki.org/wiki/Winter#The_Winter_Framework

 This release adds in several major changes:

 * Right rail functionality, designed to surface content
 * Search functionality
 * Watchlist functionality (for testing)
 * A revisit to the design of the edit interface.

 A full changelog for version 0.6 can be found here:


 https://www.mediawiki.org/wiki/Winter#Version_0.6.2C_July_13.2C_2014

 As usual, feedback is welcomed here:

 https://www.mediawiki.org/wiki/Talk:Winter

 ---
 Brandon Harris, Senior Designer, Wikimedia Foundation

 Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate


 ___
 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



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

 ___
 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] Winter, v. 0.6

[David Gerard]

I *love* how typing into the search bar gives you related articles.
How are you doing that?


- d.

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

Re: [Wikitech-l] Winter, v. 0.6

[David Gerard]

Actually one annoyance I just found: I can't right-click on the talk
page link. Is there any good reason to make this a Javascript thing
rather than an ordinary link?

On 14 July 2014 23:55, David Gerard dger...@gmail.com wrote:
 I *love* how typing into the search bar gives you related articles.
 How are you doing that?


 - d.

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

Re: [Wikitech-l] Winter, v. 0.6

[David Gerard]

On 15 July 2014 22:09, Brandon Harris bhar...@wikimedia.org wrote:

 /scramble, scramble, scramble.



The curse of doing something people like!


- d.

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

Re: [Wikitech-l] MediaWiki Bug Bounty Program

[David Gerard]

As a third-party user: I completely concur. NDAs for security bug
access are pretty much standard, aren't they?


- d.



On 26 June 2014 15:08, Tyler Romeo tylerro...@gmail.com wrote:

 I’ll be frank. I care a lot more about the security of MediaWiki as a 
 software product,
 as well as the security of its customers (both WMF and third-party) than I do 
 about
 some made-up notion of “open access” to security bugs.
 I think it makes complete sense to have people with access to security bugs 
 sign an
 agreement saying they will not release said bugs to the public until they 
 have been
 fixed, released, and announced properly.

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

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[David Gerard]

On 10 June 2014 15:34, Quim Gil q...@wikimedia.org wrote:

 * User talk pages. Do we need multithread tree discussions in our user talk
 pages? No, we don't.


And yet this is a popular use for LQT on LQT-using wikis, so will need
to be covered by Flow.


 * Regular talk pages. In most cases a section gets 2-5 replies at most. The
 benefit of a simple entry point for newcomers and junior editors clearly
 surpasses the potential inconvenience for some vets, especially if our
 priority is to be welcoming and open to diversity of people and opinions.


This is the sort of phrasing that may raise the hackles of experienced
editors; talk like this got a lot of people's backs up during the
enforced VE trial.

I fear you will have to actually convince people to get them to accept this.

I do know objections for this use case have been raised already, e.g.
being able to post a proposed slab of wikitext into a talk page. You
need to allow for that one.


 * Forums open to new / junior editors like
 https://www.mediawiki.org/wiki/Project:Support_desk . If you notice the
 number of replies per thread, you will see that almost always they keep
 themselves under 10 posts, so I don't envision major problems if we move
 those to Flow as well.


That might work. What do the people volunteering on them think?
(That's pretty much the question to answer for all proposed use
cases.)


 * Hardcore forums for insiders. I wonder if there is any using LQT
 nowadays, the ones that come to mind are based on pure Wikitext, and in
 fact they are not even in a *Talk namespace. Therefore, even if Flow would
 be powering 100% of the talk pages in Wikimedia wikis, it would be still a
 decision of these forums to decide whether they want to stay with Wikitext
 or use Flow.


What examples are you thinking of?


- d.

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

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[David Gerard]

The key thing about Usenet and email is that the first-class entity
was the individual message - on web forums, the first-class entity is
the thread. On Usenet or email, a thread is something strung
together on the fly from the surviving References: headers of whatever
messages have made it as far as you. (This is why Gmane is a bit weird
to use as a forum, even on a mailing list with no messages getting
lost.)

Trees work in places like Reddit or LessWrong, and to some degree on
Slashdot - though the latter lacks the ability to collapse a fruitless
tree in the interface.

Some ramblings on Usenet vs web forums:
http://reddragdiva.dreamwidth.org/566555.html

On 9 June 2014 07:42, Federico Leva (Nemo) nemow...@gmail.com wrote:
 I see traditional email and newsgroup clients missing a bit from Krinkle's
 list. Subthreading works perfectly fine in Thunderbird (but even in Outlook
 Express!). Indenting is the one characteristic found in all wiki
 conversations: subthreading can't be discarded based on gut feelings.
 In my experience shepherding thousands of it.wiki conversations (mostly on
 their own subpages), the biggest issue are offtopic and personal tangents,
 hence the most important technical feature in wikitext is that I'm able to
 easily tell apart, link and move subthreads.

 Nemo


 ___
 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] LiquidThreads - how do we kill it?

[David Gerard]

On 9 June 2014 10:30, Martijn Hoekstra martijnhoeks...@gmail.com wrote:

 [1] i.e. a tree structure is far less powerful than what we have now to
 approximate the domain, a dag with dividable nodes probably comes closer,
 and is already fiendishly complicated to pull off on a UI level. And then I
 haven't even gone in to the current practices of taking a comment back by
 striking it, which means that nodes aren't only arbitrarily and multiply
 dividable, but also mutable over time in a linear(?) history? 'sblood man,
 discussions are complicated.


I wonder how much everyone would hate us if we just replaced talk
pages with Apache Wave ...


- d.

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

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[David Gerard]

On 6 June 2014 19:17, Brian Wolff bawo...@gmail.com wrote:

 Personally I have yet to see a discussion system that surpasses (or
 really even comes close) to standard talk page :::comment here. 
 syntax. Honestly it would make me happy if we just used that in
 general.
 The exception being pages with large influxes of newbies, like
 Project:Support_desk. In those pages LQT really does make a difference
 to ensure things are well organized.


YMMV. Wikipedia is pretty much enculturated, but RationalWiki gets
n00bs *all the time* who object to something on a page. You know what
the most frequent reply involves? Please learn to sign your
comments.

Talk pages really aren't a great communication mechanism for non-geeks.

(RW also suffers under a LQT installation that I desperately want to
kill and would be most pleased to replace with Flow. I'm going to take
us from 1.19 to 1.23 when that's out and stable. Possibly with the VE
faff. Will Flow be able to be bolted onto an existing 1.23?)


- d.

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

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[David Gerard]

On 6 June 2014 20:12, Martijn Hoekstra martijnhoeks...@gmail.com wrote:
 On Fri, Jun 6, 2014 at 11:27 AM, David Gerard dger...@gmail.com wrote:

 YMMV. Wikipedia is pretty much enculturated, but RationalWiki gets
 n00bs *all the time* who object to something on a page. You know what
 the most frequent reply involves? Please learn to sign your
 comments.

 If auto signatures are the best thing LQT/Flow brings, I have a bad feeling
 about it.


That would be a distortion of my point :-) I have mostly found LQT
annoying as a user, but I can see the attraction of a discussion where
the threading is clearly visible, and I'm presuming extensive user
testing will be done - typical mind fallacy is a serious hazard, and
not one Wikimedia can afford.[1] This is why software changes on WMF
wikis are ultimately up to WMF, not the wiki communities.

(Of course, debacles like the introduction of VE show why caution is
still sensible. And I say that as a huge fan and advocate of VE.)


- d.


[1] http://wiki.lesswrong.com/wiki/Typical_mind_fallacy What works for
you or me cannot be presumed to work for the world. Geeks are
regularly *shocked* at what ordinary people make of things.

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

Re: [Wikitech-l] Hardening WP/WM against traffic analysis (take two)

[David Gerard]

On 5 June 2014 17:45, Zack Weinberg za...@cmu.edu wrote:

 I'd like to restart the conversation about hardening Wikipedia (or
 possibly Wikimedia in general) against traffic analysis.


Or, indeed, MediaWiki tarball version itself.



- d.

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

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[David Gerard]

On 5 June 2014 21:38, Jon Robson jdlrob...@gmail.com wrote:

 So from what I can see Flow pretty much does everything LiquidThreads
 does. Usually better (permalinks with LiquidThreads are one thing that
 completely bugs me - they don't always take me to the correct place)
 As I understand it there is a migration script that turns LiquidThread
 pages to Flow boards.


Speaking as admin of a wiki stuck with LQT: OH YES PLEASE.

(Assuming Flow won't end up all-but-abandoned as well.)


- d.

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

Re: [Wikitech-l] That you to anonymous users

[David Gerard]

If only I was a developer of any sort ;-)


On 21 May 2014 21:56, Fabrice Florin fflo...@wikimedia.org wrote:

 Hi David,

 I am delighted that you are interested in extending the Thanks feature we
 released last year, so it can be used to thank more users.

 I am no longer working on this project, but am not aware of any changes
 that would make it easier to thank anonymous users: IP addresses are still
 as unreliable now as they were a year ago.

 But I have Cc:d Danny Horn, the new product manager for core features like
 Flow and Notifications, so he can chime in from his viewpoint.

 Personally, I would love to see the Thanks feature be used even more than
 it is today, as it seems like such a civilized way to show appreciation to
 each other :)

 Cheers,


 Fabrice


 On May 20, 2014, at 7:56 AM, David Gerard dger...@gmail.com wrote:

 On 20 May 2014 15:35, Strainu strain...@gmail.com wrote:

 I've recently noticed the Thank you feature is only available for
 signed-in users, while anons cannot receive thank yous. The
 anonymous users are often the ones that would need encouraging the
 most, so it would make sense to me to have this feature available to
 them too.
 Are there significant technical problems against such a change?




 I asked for this on the editor engagement list too. Fabrice said: [1]

 Sadly, we couldn't make this feature available for anonymous users,
 as you have to be registered to receive notifications right now. This
 is because IP addresses cannot be trusted to deliver notifications to
 the users they were intended to. I don't expect we'll change that
 anytime soon. We should all encourage anonymous user to register if
 they want to enjoy the same benefits as other members.

 Fabrice, is this still the case? Are there ways around this?

 * I suppose session cookies for anons just to possibly thank them is a
 bit excessive.
 * Could limit thanks to a short time after the edit (limiting either
 sending or receiving).

 Any other ways we could implement this with minimal false-positives on
 thanking people? If that's considered a problem :-)


 - d.

 [1] http://lists.wikimedia.org/pipermail/ee/2013-July/000525.html


   ___

 Fabrice Florin
 Product Manager
 Wikimedia Foundation

 http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)




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

Re: [Wikitech-l] That you to anonymous users

[David Gerard]

On 20 May 2014 15:35, Strainu strain...@gmail.com wrote:

 I've recently noticed the Thank you feature is only available for
 signed-in users, while anons cannot receive thank yous. The
 anonymous users are often the ones that would need encouraging the
 most, so it would make sense to me to have this feature available to
 them too.
 Are there significant technical problems against such a change?



I asked for this on the editor engagement list too. Fabrice said: [1]

Sadly, we couldn't make this feature available for anonymous users,
as you have to be registered to receive notifications right now. This
is because IP addresses cannot be trusted to deliver notifications to
the users they were intended to. I don't expect we'll change that
anytime soon. We should all encourage anonymous user to register if
they want to enjoy the same benefits as other members.

Fabrice, is this still the case? Are there ways around this?

* I suppose session cookies for anons just to possibly thank them is a
bit excessive.
* Could limit thanks to a short time after the edit (limiting either
sending or receiving).

Any other ways we could implement this with minimal false-positives on
thanking people? If that's considered a problem :-)


- d.

[1] http://lists.wikimedia.org/pipermail/ee/2013-July/000525.html

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

[Wikitech-l] VE in 1.23? (was: Mozilla's Wiki Working Group meeting Tues 1600 UTC)

[David Gerard]

On 5 May 2014 22:59, Sumana Harihareswara suma...@wikimedia.org wrote:

 Mozilla has a new Wiki Working Group[0] to develop and drive a roadmap
 of improvements to http://wiki.mozilla.org;. They're currently on
 MediaWiki 1.19, and I predict they will want to get onto 1.23 once that
 is released (since it's going to be the long-term support
 release[1][2]), and that they're going to want VisualEditor and Flow as
 soon as possible. However, they have a custom theme to port over.


Instant thread derail! So ... how is 1.23 and Visual Editor?

* Has anyone sat down and written out how to add VE magic to a 1.23
tarball install?
* VE is big and complicated. I'm not clear on what it needs. Parsoid
as a daemon or something?
* Are our esteemed packagers at Debian and Fedora in the loop?

I ask out of interest for my intranet stuff, where I would *love* a VE
to wave at users who basically can't work computers and are presently
just doing stuff as Google Docs.


- d.

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

Re: [Wikitech-l] VE in 1.23? (was: Mozilla's Wiki Working Group meeting Tues 1600 UTC)

[David Gerard]

On 5 May 2014 23:08, James Forrester jforres...@wikimedia.org wrote:
 On 5 May 2014 15:05, David Gerard dger...@gmail.com wrote:

 So ... how is 1.23 and Visual Editor?
 * Has anyone sat down and written out how to add VE magic to a 1.23
 tarball install?
 I do not believe so, no.


If someone could do that, I hereby promise to beta-test their instructions!

(Personally, I think VE is pretty much ready for all users except
English Wikipedia.)


- d.

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

Re: [Wikitech-l] Proposed body font stack for Latin

[David Gerard]

On 15 April 2014 05:48, Isarra Yos zhoris...@gmail.com wrote:

 So what is the explanation, then? What was so wrong with the defaults? Do
 you have any links?


I must ask again:

Where are the user test results?

Are there any?

I've asked several times and had no response.


- d.

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

Re: [Wikitech-l] Another Wikipedia design concept

[David Gerard]

Could you or your friend please post
https://en.wikipedia.org/wiki/Wikipedia:Unsolicited_redesigns to the
thread? Designers generally do better with a spec ;-)

On 15 April 2014 15:29, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote:
 A friend of mine just spotted this:

 http://dribbble.com/shots/1508672-Wikipedia-concept

 For inspiration and discussion :)

 ___
 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] Proposed body font stack for Latin

[David Gerard]

On 15 April 2014 17:24, Brian Wolff bawo...@gmail.com wrote:

 Really a 0? What would comic sans get?


High scores for readability! It's also well-known to be very business-friendly.


- d.

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