Re: [Wikitech-l] Remote hackathon (May 9 - 11, 2020)

[Petr Bena]

Looking forward to remote beer tasting! Send a list before so I can
prepare. Also someone let Siebrand know about this :D

On Tue, Apr 21, 2020 at 3:50 PM RhinosF1 -  wrote:
>
> Added, let the fun begin!
>
> On Tue, 21 Apr 2020 at 14:44, Andre Klapper  wrote:
>
> > Heja,
> >
> > On Mon, 2020-04-20 at 21:03 +0200, Maarten Dammers wrote:
> > > The first weekend of May the Wikimedia Hackathon 2020 in Tirana was
> > > supposed to happen. As an alternative, we're organizing a remote
> > > hackathon. Please have a look at
> > > https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2020/Remote_Hackathon
> > > and sign up if you're interested in participating.
> > >
> > > All of the sessions, projects, and initiatives are run by the
> > > participants themselves and not overseen by a core organizing team.  All
> > > ideas including technical projects and sessions, non-technical projects
> > > and sessions, and social events/socal time are very welcome.
> >
> > It should probably also be added that as a movement, we don't have yet
> > the experience to run remote events and we're all learning. :)
> > This initiative is not a fully planned hackathon, but hopefully a nice
> > opportunity to spend some social and hack time together.
> >
> > I'd also like to explicitly point out that if you plan to work on
> > technical projects which will require deploying changes at some point,
> > please be mindful and make sure to read and follow
> > https://wikitech.wikimedia.org/wiki/Deployments/Covid-19 - let's not
> > create more work for fellow developers and keep (some) things stable.
> >
> > Hope to see you there, even if you only join for a few hours!
> >
> > Happy hacking!
> >
> > andre
> >
> > --
> > Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> > https://blogs.gnome.org/aklapper/
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> --
> Thanks,
> Samuel
> ___
> 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 is "revision slot" and why is it necessary to specify it now?

[Petr Bena]

That is interesting.

I guess that's indeed the correct way, and now I noticed (or maybe I
am reading it wrong) that mediawiki.org doesn't seem to support them?
Or at least I don't see the word rvslot anywhere in the output of that
very query. If that's the case does it mean that rvslots is optional
feature? Or is that this part of result which indicates they are being
supported?

...

"limit": 500,
"deprecatedvalues": [
"parsetree"
]
},
{
"index": 2,
>>>>"name": "slots",  <<<<
"type": [
"main"
],

...

On Mon, Apr 6, 2020 at 3:54 PM Brad Jorsch (Anomie)
 wrote:
>
> On Sun, Apr 5, 2020 at 5:24 PM Daniel Kinzler  wrote:
>>
>> Am 05.04.20 um 23:18 schrieb Petr Bena:
>> > But still, I am curious what is the recommended approach for someone
>> > who wants to develop their application "properly" in a way that it's
>> > backward compatible? First query the MediaWiki version via API, and
>> > based on that decide how to call APIs? I can't think of any other way.
>>
>> Yes, that's indeed the only way if the client is to be entirely generic. 
>> Though
>> deprecated API behavior tends to stay supported for quite a while,  much 
>> longer
>> than deprecated PHP methods. So checking the MediaWiki version first would 
>> only
>> be needed if you wanted your code to work with a wide range of MediaWiki 
>> versions.
>
>
> Rather than checking the MediaWiki version, I'd generally recommend checking 
> against the action=paraminfo endpoint for the module in question for 
> something like this. If e.g. 
> https://www.mediawiki.org/w/api.php?action=paraminfo&modules=query+revisions 
> reports that rvslots is available then use it, otherwise use back-compat code.
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation

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

Re: [Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Petr Bena]

Aha thanks for the update. To give you some context, I would like to
fix https://phabricator.wikimedia.org/T249460 the main problem as I
see now, is that this looks like a seriously breaking change to me
(but maybe I am overlooking something). If I change the API call to
work with rvslots, I doubt it's going to work at all with MediaWiki <
1.32, on other hand, future versions of MW may stop working with older
parameters.

I don't see an easy way out here for applications that want to work
flawlessly with as many MW versions as possible. In case of Huggle,
it's not really so big deal, it's mostly used with Wikimedia wikis and
I believe we are consistently on newest version on all production
wikis. Huggle can be used on 3rd party MediaWiki installations too,
where this could be a serious issue, but I doubt there are too many
users who actually use it outside of Wikimedia world (and if there
are, they can just stick with older Huggle if they don't want to
upgrade their wiki installation).

But still, I am curious what is the recommended approach for someone
who wants to develop their application "properly" in a way that it's
backward compatible? First query the MediaWiki version via API, and
based on that decide how to call APIs? I can't think of any other way.

On Sun, Apr 5, 2020 at 11:10 PM Daniel Kinzler  wrote:
>
> Thanks for bringing this up.
>
> I have made some updates to the documentation in mediawiki.org to make clear
> that MCR is not work in progress. While support is not complete in all parts 
> of
> MediaWiki, the storage layer has been implemented and the database has been
> migrated to the new system.
>
> Am 05.04.20 um 22:17 schrieb Petr Bena:
> > Hello,
> >
> > https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
> > multiple times, but fails to explain what it is?
> >
> > I noticed that some queries that were running fine in the past now
> > have warning: "Because "rvslots" was not specified, a legacy format
> > has been used for the output. This format is deprecated, and in the
> > future the new format will always be used."
> >
> > Which is interesting, but not very descriptive. What are revision
> > slots? Why are they needed? What is difference between "legacy format"
> > and "new format"? If rvslots are so important, why they aren't part of
> > some of the examples?
> >
> > So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
> > seems like some new "work-in-progress" feature, that isn't very useful
> > yet, as there is only 1 slot in existence.
> >
> > Is it necessary to pay attention to this? Can I simply silence this
> > warning by providing parameter rvslots=*? Or should I pay it some
> > deeper attention?
> >
> > Thanks
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> --
> Daniel Kinzler
> Principal Software Engineer, Core Platform
> Wikimedia Foundation

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

[Wikitech-l] What is "revision slot" and why is it necessary to specify it now?

[Petr Bena]

Hello,

https://www.mediawiki.org/wiki/API:Revisions mentions "revision slots"
multiple times, but fails to explain what it is?

I noticed that some queries that were running fine in the past now
have warning: "Because "rvslots" was not specified, a legacy format
has been used for the output. This format is deprecated, and in the
future the new format will always be used."

Which is interesting, but not very descriptive. What are revision
slots? Why are they needed? What is difference between "legacy format"
and "new format"? If rvslots are so important, why they aren't part of
some of the examples?

So far I googled this: https://www.mediawiki.org/wiki/Manual:Slot it
seems like some new "work-in-progress" feature, that isn't very useful
yet, as there is only 1 slot in existence.

Is it necessary to pay attention to this? Can I simply silence this
warning by providing parameter rvslots=*? Or should I pay it some
deeper attention?

Thanks

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

Re: [Wikitech-l] Change to Wikitech logins: Username now case-sensitive

[Petr Bena]

NVM, I just figured out that MW and Gerrit was creating duplicated
accounts due to this

On Tue, Apr 16, 2019 at 3:16 PM Petr Bena  wrote:
>
> Hello,
>
> What was the reason for this change? What does it improve or fix?
>
> On Tue, Apr 16, 2019 at 3:00 PM Andrew Otto  wrote:
> >
> > Great!  Is this just for Wikitech itself or all ldap/wikitech
> > authentication?
> >
> > On Mon, Apr 15, 2019 at 7:56 PM Bryan Davis  wrote:
> >
> > > A change was deployed to the Wikitech config 2019-04-15T23:16 UTC
> > > which prevents users from logging into the wiki with a username that
> > > differs in case from the 'cn' value for their developer account.
> > >
> > > This change is not expected to cause problems for most users, but
> > > there may be some people who have historically entered a username with
> > > mismatched case (for example "bryandavis" instead of "BryanDavis") and
> > > relied on MediaWiki and the LdapAuthentication plugin figuring things
> > > out. This will no longer happen automatically. These users will need
> > > to update their password managers (or brains if they are not using a
> > > password manager) to supply the username with correct casing.
> > >
> > > The "wrongpassword" error message on Wikitech has been updated with a
> > > local override to help people discover this problem. See
> > > <https://phabricator.wikimedia.org/T165795> for more details.
> > >
> > > Bryan, on behalf of the Cloud Services team
> > > --
> > > Bryan Davis  Wikimedia Foundation
> > > [[m:User:BDavis_(WMF)]] Manager, Technical EngagementBoise, ID USA
> > > irc: bd808v:415.839.6885 x6855
> > >
> > > ___
> > > 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] Change to Wikitech logins: Username now case-sensitive

[Petr Bena]

Hello,

What was the reason for this change? What does it improve or fix?

On Tue, Apr 16, 2019 at 3:00 PM Andrew Otto  wrote:
>
> Great!  Is this just for Wikitech itself or all ldap/wikitech
> authentication?
>
> On Mon, Apr 15, 2019 at 7:56 PM Bryan Davis  wrote:
>
> > A change was deployed to the Wikitech config 2019-04-15T23:16 UTC
> > which prevents users from logging into the wiki with a username that
> > differs in case from the 'cn' value for their developer account.
> >
> > This change is not expected to cause problems for most users, but
> > there may be some people who have historically entered a username with
> > mismatched case (for example "bryandavis" instead of "BryanDavis") and
> > relied on MediaWiki and the LdapAuthentication plugin figuring things
> > out. This will no longer happen automatically. These users will need
> > to update their password managers (or brains if they are not using a
> > password manager) to supply the username with correct casing.
> >
> > The "wrongpassword" error message on Wikitech has been updated with a
> > local override to help people discover this problem. See
> >  for more details.
> >
> > Bryan, on behalf of the Cloud Services team
> > --
> > Bryan Davis  Wikimedia Foundation
> > [[m:User:BDavis_(WMF)]] Manager, Technical EngagementBoise, ID USA
> > irc: bd808v:415.839.6885 x6855
> >
> > ___
> > 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] My Phabricator account has been disabled

[Petr Bena]

Wiktionary, such a nice website, I wonder who operates it...

I think "language police" is a winner. So again: I hope our community
won't turn into a bunch of language cops and put focus back on
technical awesome things instead.

Now back to work, there is still big backlog of tasks last time I checked.

On Wed, Aug 15, 2018 at 7:45 PM, Bence Damokos  wrote:
> Pedants?
> Prescriptivists? Etc... https://en.m.wiktionary.org/wiki/grammar_Nazi
>
>
> On Wed, 15 Aug 2018, 18:10 Petr Bena,  wrote:
>
>> Out of curiousity, how would you say "grammar nazi" or "language nazi"
>> with absence of word "nazi" so that it still has same effect and
>> doesn't sound dull?
>>
>>
>>
> ___
> 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] My Phabricator account has been disabled

[Petr Bena]

Hi Joe,

Of course I am not talking Amir, he's a nice guy. I think "language
bully" probably works here. Thanks for tip ;)

On Wed, Aug 15, 2018 at 6:25 PM, Joe Matazzoni  wrote:
> Petr asks:
>> Out of curiousity, how would you say "grammar nazi" or "language nazi"
> with absence of word "nazi”
>
> Interesting question (in the abstract—meaning as long as we’re not talking 
> about Amir).
>
> There is no standard phrase that comes to mind. Tyrant and despot are too 
> classy, authoritarian too long, stickler not pejorative enough…I’d go with 
> bully.
> _
>
> Joe Matazzoni
> Product Manager, Collaboration
> Wikimedia Foundation, San Francisco
> mobile 202.744.7910
> jmatazz...@wikimedia.org
>
> "Imagine a world in which every single human being can freely share in the 
> sum of all knowledge."
>
>
>
>
>> On Aug 15, 2018, at 9:10 AM, Petr Bena  wrote:
>>
>> Out of curiousity, how would you say "grammar nazi" or "language nazi"
>> with absence of word "nazi" so that it still has same effect and
>> doesn't sound dull?
>>
>> On Wed, Aug 15, 2018 at 8:31 AM, Bináris  wrote:
>>> 2018-08-13 18:35 GMT+02:00 Petr Bena :
>>>
>>>> Is that
>>>> what we turned into? From highly skilled developers and some of best
>>>> experts in the field to a bunch of language nazis?
>>>>
>>>
>>> Folks, please never use the word "nazi" for people in any context except
>>> definitely stating they are nazis in the origonal meaning of the word.
>>> Neither with prefixes or suffixes or in compositions.
>>> I know you didn't want to say anything bad with that and many people use
>>> this phrase, but to call somebody *any kind of a *nazi or comparing any
>>> behaviour to nazis is much more abusive then to use the f word for a lot of
>>> people in whose personal or local history nazis appear and play a role.
>>>
>>> This is not addressed to you, Petr. This is just an example, that people
>>> deal with one thing and don't even notice the other one, and don't realize
>>> the importance of this or that.
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] My Phabricator account has been disabled

[Petr Bena]

But that not only does sound very dull, but it doesn't even sound like
you don't like or disagree with such behaviour

See the difference between these two sentences, which are trying to
say same thing using your definition of "grammar nazi":

* My posts are constantly checked by people who believe that my
grammar and spelling should be proper everywhere possible, who keep
notifying me when I make mistakes.
* I am being terrorized by grammar nazis.

In first sentence, half of people would just not read it because it's
too long and dull and other half wouldn't care or understand the
point.

The second sentence, on other hand... Proper speech is often boring
and ignored, which leads to desperation, which leads to insults and
swear words. It's not ideal, but that's how world seems to work.



On Wed, Aug 15, 2018 at 6:14 PM, Siebrand Mazeland  wrote:
>
>> Op 15 aug. 2018 om 18:10 heeft Petr Bena  het volgende 
>> geschreven:
>>
>> Out of curiousity, how would you say "grammar nazi" or "language nazi"
>> with absence of word "nazi" so that it still has same effect and
>> doesn't sound dull?
>
> A person who believes proper grammar (and spelling) should be used by 
> everyone whenever possible.
>
> --
> Siebrand
>
>
> ___
> 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] My Phabricator account has been disabled

[Petr Bena]

Out of curiousity, how would you say "grammar nazi" or "language nazi"
with absence of word "nazi" so that it still has same effect and
doesn't sound dull?

On Wed, Aug 15, 2018 at 8:31 AM, Bináris  wrote:
> 2018-08-13 18:35 GMT+02:00 Petr Bena :
>
>>  Is that
>> what we turned into? From highly skilled developers and some of best
>> experts in the field to a bunch of language nazis?
>>
>
> Folks, please never use the word "nazi" for people in any context except
> definitely stating they are nazis in the origonal meaning of the word.
> Neither with prefixes or suffixes or in compositions.
> I know you didn't want to say anything bad with that and many people use
> this phrase, but to call somebody *any kind of a *nazi or comparing any
> behaviour to nazis is much more abusive then to use the f word for a lot of
> people in whose personal or local history nazis appear and play a role.
>
> This is not addressed to you, Petr. This is just an example, that people
> deal with one thing and don't even notice the other one, and don't realize
> the importance of this or that.
> ___
> 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] My Phabricator account has been disabled

[Petr Bena]

I am OK if people who are attacking others are somehow informed that
this is not acceptable and taught how to properly behave, and if they
continue that, maybe some "preventive" actions could be taken, but is
that what really happened?

The comment by MZMcBride was censored, so almost nobody can really see
what it was and from almost all mails mentioning the content here it
appears he said "what the fuck" or WTF. I can't really think of any
language construct where this is so offensive it merits instant ban +
removal of content.

I don't think we need /any/ language policy in a bug tracker. If
someone says "this bug sucks old donkey's " it may sounds a bit
silly, but there isn't really any harm done. If you say "Jimbo, you
are a f retard, and all your code stinks" then that's a problem,
but I have serious doubts that's what happened. And the problem is not
a language, but personal attack itself.

If someone is causing problems LET THEM KNOW and talk to them. Banning
someone instantly is worst possible thing you can do. You may think
our community is large enough already so that we can set up this kind
of strict and annoying policies and rules, but I guarantee you, it's
not. We have so many open bugs in phabricator that every user could
take hundreds of them... We don't need to drive active developers away
by giving them bans that are hardly justified.

P.S. if someone saying "WTF" is really giving you creeps, I seriously
recommend you to try to develop a bit thicker skin, even if we build
an "Utopia" as someone mentioned here, it's gonna be practical for
interactions in real world, which is not always friendly and nice. And
randomly banning people just for saying WTF, with some cryptic
explanation, seems more 1984 style Dystopia to me...

On Tue, Aug 14, 2018 at 4:08 PM, David Barratt  wrote:
>>
>> Again, this isn't enwiki, but there would be a large mob gathering at the
>> administrators' doorstep on enwiki for a block without that context and
>> backstory.
>>
>
> That seems like really toxic behavior.
>
> On Tue, Aug 14, 2018 at 6:27 AM George Herbert 
> wrote:
>
>> I keep seeing "abusers" and I still haven't seen the evidence of the
>> alleged long term abuse pattern.
>>
>> Again, this isn't enwiki, but there would be a large mob gathering at the
>> administrators' doorstep on enwiki for a block without that context and
>> backstory.  That's not exactly the standard here, but ... would someone
>> just answer the question?  What happened leading up to this to justify the
>> block?  If it's that well known, you can document it.
>>
>> On Tue, Aug 14, 2018 at 12:18 AM, Adam Wight  wrote:
>>
>> > Hi Petr,
>> >
>> > Nobody is language policing, this is about preventing abusive behavior
>> and
>> > creating an inviting environment where volunteers and staff don't have to
>> > waste time with emotional processing of traumatic interactions.
>> >
>> > I think we're after the same thing, that we want to keep our community
>> > friendly and productive, so it's just a matter of agreeing on the means
>> to
>> > accomplish this.  I see the Code of Conduct Committee standing up to the
>> > nonsense and you see them as being hostile, so our perspectives diverge
>> at
>> > that point.  I also see lots of people on this list standing up for what
>> > they think is right, and I'd love if that energy could be organized
>> better
>> > so that we're not sniping at each other, but instead refining our shared
>> > statements of social values and finding a way to encourage the good while
>> > more effectively addressing the worst in us.
>> >
>> > This isn't coherent enough to share yet, but I'll try anyway—I've been
>> > thinking about how our high proportion of anarchic- and
>> > libertarian-oriented individuals helped shape a culture which doesn't
>> > handle "negative laws" [1] well.  For example, the Code of Conduct is
>> > mostly focused on "unacceptable behaviors", but perhaps we could rewrite
>> it
>> > in the positive sense, as a set of shared responsibilities to support
>> each
>> > other and the less powerful person in any conflict.  We have a duty to
>> > speak up, a duty to keep abusers from their target, we own this social
>> > space and have to maintain it together.  If you see where I'm headed?
>> > Rewriting the CoC in a positive rights framework is a daunting project,
>> but
>> > it might be fu

Re: [Wikitech-l] My Phabricator account has been disabled

[Petr Bena]

I am a bit late to the party, but do we seriously spend days
discussing someone being banned from a bug tracker just for saying
"WTF", having their original comment completely censored, so that the
community can't even make a decision how bad it really was? Is that
what we turned into? From highly skilled developers and some of best
experts in the field to a bunch of language nazis?

We have tens of thousands of open tasks to work on and instead of
doing something useful we are wasting our time here. Really? Oh, come
on...

We are open source developers. If you make Phabricator too hostile to
use it by setting up some absolutely useless and annoying rules,
people will just move to some other bug tracker, or decide to spend
their free time on a different open source project. Most of us are
volunteers, we don't get money for this.

P.S. if all the effort we put into this gigantic thread was put into
solving the original bug instead (yes it's a bug, not a feature) it
would be already resolved. Instead we are mocking someone who was so
desperate with the situation to use some swear words.

On Mon, Aug 13, 2018 at 12:06 AM, Yaron Koren  wrote:
>  Nuria Ruiz  wrote:
>> The CoC will prioritize the safety of the minority over the comfort of the
>> majority.
>
> This is an odd thing to say, in this context. I don't believe anyone's
> safety is endangered by hearing the phrase in question, so it seems like
> just an issue of comfort on both sides. And who are the minority and
> majority here?
>
>> The way the bug was closed might be incorrect (I personally as an engineer
>> agree that closing it shows little understanding of how technical teams do
>> track bugs in phab, some improvements are in order here for sure) but the
>> harsh interaction is just one out of many that have been out of line for
>> while.
>
> This seems like the current argument - that it's not really about the use
> of a phrase, it's about an alleged pattern of behavior by MZMcBride. What
> this pattern is I don't know - the one example that was brought up was a
> blog post he wrote six years ago, which caused someone else to say
> something mean in the comments. (!) As others have pointed out, there's a
> lack of transparency here.
>
> -Yaron
> ___
> 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] Making two factor auth less annoying

[Petr Bena]

Oh and I totally forgot to include link to phab task:
https://phabricator.wikimedia.org/T201784

On Sun, Aug 12, 2018 at 6:47 PM, Petr Bena  wrote:
> Hello,
>
> I would like to do some major changes to two factor auth. I am cross
> posting this on phabricator and the mailing list to give it some more
> attention and to start some proper discussion before anyone starts
> working on this:
>
> Right now there are only two options for two factor authentication:
>
> * Don't use two-factor authentication (insecure)
> * Use two factor authentication (annoying as hell)
>
> With two factor authentication it doesn't seem to be possible to make
> session persistent and it really is extremely annoying to look for
> your mobile phone, open the app and fill in the code everytime you
> want to do some simple wiki action. I am very lazy and even found
> myself to rather decide not to do a minor change (be it fix of typo
> correction etc. in article on English Wikipedia etc) rather than going
> through the hassle of using the google authenticator.
>
> I think it would be really cool to have an option (or maybe even more
> of them?) that would help to specify when two factor auth is really
> desired, so that for example users could decide that for simple
> actions like wiki editing normal login would be sufficient, but for
> changes like:
>
> * Change of password
> * Change of (some) preferences
> * Admin actions (block, delete etc.)
>
> P.S. Unfortunately I no longer have so much free time to track every
> single thread in this mailing list, so maybe this is a duplicate of
> some older idea by someone else, if that's the case, please merge the
> phab task with whatever the other identical proposal is.
>
> Thank you

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

[Wikitech-l] Making two factor auth less annoying

[Petr Bena]

Hello,

I would like to do some major changes to two factor auth. I am cross
posting this on phabricator and the mailing list to give it some more
attention and to start some proper discussion before anyone starts
working on this:

Right now there are only two options for two factor authentication:

* Don't use two-factor authentication (insecure)
* Use two factor authentication (annoying as hell)

With two factor authentication it doesn't seem to be possible to make
session persistent and it really is extremely annoying to look for
your mobile phone, open the app and fill in the code everytime you
want to do some simple wiki action. I am very lazy and even found
myself to rather decide not to do a minor change (be it fix of typo
correction etc. in article on English Wikipedia etc) rather than going
through the hassle of using the google authenticator.

I think it would be really cool to have an option (or maybe even more
of them?) that would help to specify when two factor auth is really
desired, so that for example users could decide that for simple
actions like wiki editing normal login would be sufficient, but for
changes like:

* Change of password
* Change of (some) preferences
* Admin actions (block, delete etc.)

P.S. Unfortunately I no longer have so much free time to track every
single thread in this mailing list, so maybe this is a duplicate of
some older idea by someone else, if that's the case, please merge the
phab task with whatever the other identical proposal is.

Thank you

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

Re: [Wikitech-l] [Cloud] Help us build Toolhub

[Petr Bena]

Hello,

Interesting, but I think that more data should be collected about the
tools, especially the technologies and programming languages used, so
that another similar portal could be built with these data for
programmers / volunteers looking for a technical project to work on.

IDK what is current status of our own alternative for
https://whatcanidoformozilla.org/ but it would be really nice to have
some similar portal for new programmers that are simply looking for a
project to work on based on technology or programming language they
like. If this toolhub contained this information as well, we could
reuse the data for such portal as well.

On Thu, Jun 14, 2018 at 4:51 AM, James Hare  wrote:
> Hello everyone, sorry for cross-posting.
>
> What does your participation on the Wikimedia projects look like? Do you
> edit articles? Upload files? Patrol vandalism? Translate articles? Translate
> interface messages? Do you organize people, online or offline? Do you train
> new editors, or new trainers? Do you write code?
>
> There are many different ways to contribute to Wikimedia – more than you
> would expect just from reading Wikipedia articles. With many kinds of
> contributions there are many tools you can use, most of which have been
> developed by our volunteer community. But do you know how to find these
> tools?
>
> Since January the Wikimedia Cloud Services team at the Wikimedia Foundation
> has been meeting with contributors, organizers, and tool developers to learn
> more about the role tools play in our communities' work. We have also been
> researching existing methods for organizing lists of tools – at least 14 of
> them, including popular tool catalogs like Hay's Tool Directory.[0] With
> this research, we hope to figure out how best to put the right tools in
> front of the right people.
>
> For this, we need your help. We have a page on Meta summarizing our current
> work,[1] as well as a proposed data model for describing tools.[2] Consider
> what work you currently do, whether you contribute content, code, organizing
> support, what have you – and ask: if there was a tool you needed to complete
> a certain task, would you know where to look? How would you look for it?
> Please look over [1] and [2] and let us know what you think. Feedback is
> welcome in any language. If you would like to get in touch privately, you
> are also welcome to email me at jh...@wikimedia.org.
>
>
> Best regards,
> James Hare
>
> [0] https://tools.wmflabs.org/hay/directory/
> [1] https://meta.wikimedia.org/wiki/Toolhub
> [2] https://meta.wikimedia.org/wiki/Toolhub/Data_model
>
> 
> James Hare
> Associate Product Manager
> Wikimedia Foundation
> https://wikimediafoundation.org
>
> ___
> Wikimedia Cloud Services mailing list
> cl...@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud

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

Re: [Wikitech-l] Please comment on the draft consultation for splitting the admin role

[Petr Bena]

Speaking of security, I believe that all sysops and people allowed to
edit JS / CSS anywhere on mediawiki sites should be required to use
2FA.

On Mon, Jun 11, 2018 at 4:53 PM, Gergo Tisza  wrote:
> On Mon, Jun 11, 2018 at 3:28 PM Petr Bena  wrote:
>
>> Is there any historical evidence that sysops being able to edit JS /
>> CSS caused some serious issues? Your point that "most of
>> administrators don't understand JS / CSS" is kind of moot. They are
>> usually trustworth and intelligent people. They don't mess up with
>> something they don't understand and therefore it makes little sense to
>> restrict them from being able to do that.
>>
>
> The primary concern here is someone taking over the account by password
> guessing, social engineering, phishing, exploiting some unfixed MediaWiki
> vulnerability etc. The secondary concern is admins becoming malicious or
> doing something stupid as a way of ragequitting, which is rare but does
> happen (for example, not so long ago, someone thought it would be a good
> idea to make money by installing a cryptocoin miner on Wikipedia). Admins
> making a mistake and breaking the site also happens occasionally, but
> that's not a security problem so it's a pretty minor issue in comparison.
>
> I understand your points, but do we really need it? Is it going to
>> improve anything?
>
>
> It reduces the attack surface. Less people with access means less
> vulnerable passwords, less people whose system has been infected with the
> latest computer virus etc.
> Also there are things we might require JS editors to do which might be
> inconvenient to some people (e.g. making two-factor authentication
> required) so it's good to reduce the number of people who have to be
> exposed to that.
> ___
> 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] Please comment on the draft consultation for splitting the admin role

[Petr Bena]

OK in that case I think this should be done.

On Mon, Jun 11, 2018 at 3:40 PM, Thiemo Kreuz  wrote:
>> Is there any historical evidence that sysops being able to edit JS / CSS 
>> caused some serious issues?
>
> Oh yes, this happens more often than I feel it needs to. I remember a
> situation when I posted a fix for a script in the MediaWiki:…
> namespace as an {{edit request}}, and a well-meaning administrator
> tried to "improve" my line of code and forgot a comma, breaking all
> JavaScript for all logged-in as well as not logged-in Wikipedia
> editors and readers for some painful minutes.
>
> I believe such can be avoided with more clear roles that are visible
> for everybody. A separate "tech admin" role would also allow
> volunteers to apply for exactly that, and not be asked why they don't
> do enough "administrator actions" with their privileges.
>
> Sure, this is anecdotal evidence. Please forgive me, but I currently
> don't have the time to find the pages documenting these situation.
>
> Best
> Thiemo
>
> ___
> 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] Please comment on the draft consultation for splitting the admin role

[Petr Bena]

Is there any historical evidence that sysops being able to edit JS /
CSS caused some serious issues? Your point that "most of
administrators don't understand JS / CSS" is kind of moot. They are
usually trustworth and intelligent people. They don't mess up with
something they don't understand and therefore it makes little sense to
restrict them from being able to do that.

I remember that many years ago there was an attempt to split sysop
group on English Wikipedia to multiple smaller roles and it horribly
failed.

I understand your points, but do we really need it? Is it going to
improve anything?

On Mon, Jun 11, 2018 at 1:58 PM, Gergő Tisza  wrote:
> Hi all,
>
> per the discussion on Phabricator, I'd like to split the administrator
> ("sysop") user group into two parts - one which can edit sitewide CSS/JS,
> and one which can not. You can find the details and detailed rationale in
> the task:
> https://phabricator.wikimedia.org/T190015
>
> To inform the editor communities, and to make sure we can accommodate their
> needs, I plan to run a community consultation; I'll probably kick it off on
> Friday and have it run for two weeks. You can find the draft here:
> https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS
>
> I would appreciate if folks who are knowledgeable about the use of CSS/JS
> editing and user rights management in various parts of the community could
> look at it and add their concerns or suggestion to the talk page (or
> Phabricator if that's more appropriate). Suggestions for a better group
> name are especially welcome.
>
> (As I wrote it in the FAQ on the consultation page, I think making sure
> that MediaWiki is secure and at the same time empowers its users falls
> under the authority of the developer community, and so the normal code
> review process is appropriate for this change. Thus the consultation is not
> intended to be an RfC or other discussion/veto type process. If you
> disagree about the change in general, please discuss that on Phabricator,
> or the linked Gerrit patches.)
>
> Thanks!
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

Are we running same firefox? I have same experience like you, but with
Chrome. Firefox is best performing and rock solid compared to anything else
to me and I run it on all my computers including virtual boxes, with ~100
tabs I achieved months of uptime with no crash. Can't say this about chrome
or others.

On Tue, 5 Sep 2017 at 02:08, Risker  wrote:

> Gonna be honest...after using Firefox almost exclusively for the last 10
> years whenever I had a choice, I'm ready to give up on it. I don't expect
> all the bells and whistles (and privacy compromises) of the big commercial
> browsers, but Firefox has decided to take a path that is actively awful.
> It's not just awful on Wikipedia (where I know logged-in users with lots of
> preferences and scripts are always going to be slow), it is awful on every
> website I go to, and it crashes on a multiple-times-a-day basis.  It does
> this on all three of my computers.  I've been trying to stay loyal and look
> at the bigger "free knowledge" bit...but I have had six crashes today and
> I'm done.  I hear this a lot from people I know outside of Wikimedia, and
> I've been told its unreliability is why several companies have decided
> against adding it (or have removed it) as an acceptable alternate browser.
>
> So no, I do not think it would be a good idea for anyone, let alone the
> Wikimedia Foundation, to advocate on behalf of this software.
>
> Risker/Anne
>
> On 3 September 2017 at 03:22, Stas Malyshev 
> wrote:
>
> > Hi!
> >
> > > After Firefox and Chromium, there's a bunch of open source web browsers
> > > listed on [2], but a brief spot check showed many as being Linux only
> > > (or outdated Mac builds). One that looked promising was Brave[3],
> though
> > > it's a relatively new browser and I would need to do more research
> > > regarding #3.
> >
> > I've been using Brave for a couple of months occasionally, and it seems
> > to work pretty well. It has (some) adblocking in default config, and
> > some other privacy-enhancing settings, which are probably not very
> > important for Wikimedia sites but may either break some other sites or
> > make them bearable :)
> > It's pretty young, so I don't think we can say much about security
> > record yet - IIRC it's based on Chromium, and it's updated pretty
> > frequently, and it's easy to use (though the UI might be a bit more
> > spartan then others for now, and not many extensions available - but for
> > ex-IE users it may not be an issue).
> >
> > --
> > Stas Malyshev
> > smalys...@wikimedia.org
> >
> > ___
> > 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] Global language preference

[Petr Bena]

I understand that there exist some JS hacks, but I doubt that is what
average user can live with. I think we should make these options
available for general public, in a user-friendly manner and not only
to few people with knowledge that enables them to hack mediawiki
interface so that it works well enough for them.

On Wed, May 10, 2017 at 1:42 PM, Johan Jönsson  wrote:
> A couple of relevant links:
> https://phabricator.wikimedia.org/T16950
> https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Global_preferences
>
> //Johan Jönsson
> --
>
> On Wed, May 10, 2017 at 9:48 AM, Yongmin H.  wrote:
>
>> Language is hackable via JS but settings like 'set timezone to blah blah,
>> disable VE if it's enabled, disable compact language if enabled, set email
>> to plaintext only, disable xwiki notification, ...' can't be done via JS
>> hack, which is unfortunate.
>>
>> --
>> Yongmin
>> Sent from my iPhone
>> https://wp.revi.blog
>> Please note that this address is list-only address and any non-mailing
>> list mails will be treated as spam.
>> Please use https://encrypt.to/0x947f156f16250de39788c3c35b625da5beff197a.
>>
>> 2017. 5. 10. 16:26 Martin Urbanec  작성:
>>
>> > Hi Petr,
>> >
>> > an user can archieve that aim using global script and then viewing all
>> > projects they want to change. AFAIK this was requested in the community
>> > wishlist.
>> >
>> > Martin
>> >
>> > st 10. 5. 2017 v 9:20 odesílatel Petr Bena  napsal:
>> >
>> >> Hi all,
>> >>
>> >> We have central auth, global user pages and stuff like that, do we
>> >> have some kind of global preferences too? So that one could set
>> >> interface language to English and have it like that on every single
>> >> project they work on?
>> >>
>> >> I don't really see a need to have different projects with different
>> >> interface language but if there was a need for this we could probably
>> >> make it possible to override (like add language "Same as meta" which
>> >> would be default option, or something of that kind).
>> >>
>> >> Maybe something that makes this possible already exists but I am not
>> >> aware of that.
>> >>
>> >> ___
>> >> Wikitech-l mailing list
>> >> Wikitech-l@lists.wikimedia.org
>> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Wikitech-l] Global language preference

[Petr Bena]

Hi all,

We have central auth, global user pages and stuff like that, do we
have some kind of global preferences too? So that one could set
interface language to English and have it like that on every single
project they work on?

I don't really see a need to have different projects with different
interface language but if there was a need for this we could probably
make it possible to override (like add language "Same as meta" which
would be default option, or something of that kind).

Maybe something that makes this possible already exists but I am not
aware of that.

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

Re: [Wikitech-l] [Huggle] Fwd: EventStreams launch and RCStream deprecation

[Petr Bena]

Hello,

Thanks for the info, this means that we need to switch from RCStream, is
there any working example code, preferably written in Python or any other
sane terminal friendly language (eg. not html or JS) that is capable of
connecting to this stream and obtaining at least identicat information from
it as we did in case of RCStream?

P.S. I can't help myself but I really have to rant now because I hate how
much MW devs love to deprecate stuff and break compatibilty so often just
for trivial reasons. I am really glad that instead of using RCStream
directly I created that XmlRcs proxy in past, it's gonna save me massive
amount of work, because no, I am not gonna deprecate XmlRcs [1].

P.S. 2.0: Do you really have a date for decommission of a working service
already even though the replacement is still in early-cradle pre-alpha
phase? Is this really the best approach?

1: https://wikitech.wikimedia.org/wiki/XmlRcs

On Thu, 23 Feb 2017 at 22:11, Andrew Otto  wrote:

> Hi everyone!
>
> Wikimedia is releasing a new service: EventStreams
> [1].  This service
> allows us to publish arbitrary streams of JSON event data to the
> public.  (Pt: we’re looking for cool new uses
> [2]
> to put on an upcoming blog post.)
>
>
> Initially, the only stream available will be good ol’ RecentChanges
> .  This event stream
> overlaps functionality already provided by irc.wikimedia.org and RCStream
> .  However, this new
> service has advantages over these (now deprecated) services.
>
>
>1.
>
>We can expose more than just RecentChanges.
>2.
>
>Events are delivered over streaming HTTP (chunked transfer) instead of
>IRC or socket.io.  This requires less client side code and fewer
>special routing cases on the server side.
>3.
>
>Streams can be resumed from the past.  By using EventSource, a
>disconnected client will automatically resume the stream from where it left
>off, as long as it resumes within one week.  In the future, we would like
>to allow users to specify historical timestamps from which they would like
>to begin consuming, if this proves safe and tractable.
>
>
> I did say deprecated!  Okay okay, we may never be able to fully deprecate
> irc.wikimedia.org.  It’s used by too many (probably sentient by now) bots
> out there.  We do plan to obsolete RCStream, and to turn it off in a
> reasonable amount of time.  The deadline iis July 7th, 2017.  All
> services that rely on RCStream should migrate to the HTTP based
> EventStreams service by this date.  We are committed to assisting you in
> this transition, so let us know how we can help.
>
> Unfortunately, unlike RCStream, EventStreams does not have server side
> event filtering (e.g. by wiki) quite yet.  How and if this should be done
> is still under discussion .
>
> The RecentChanges data you are used to remains the same, and is available
> at https://stream.wikimedia.org/v2/stream/recentchange. However, we may
> have something different for you, if you find it useful. We have been
> internally producing new Mediawiki specific events
> 
> [3] for a while now, and could expose these via EventStreams as well.
>
> Take a look at these events, and tell us what you think.  Would you find
> them useful?  How would you like to subscribe to them?  Individually as
> separate streams, or would you like to be able to compose multiple event
> types into a single stream via an API?  These things are all possible.
>
> I asked for a lot of feedback in the above paragraphs.  Let’s try and
> centralize this discussion over on the mediawiki.org EventStreams talk
> page [4].   In summary,
> the questions are:
>
>
>-
>
>What RCStream clients do you maintain, and how can we help you migrate
>to EventStreams?
>
>-
>
>Is server side filtering, by wiki or arbitrary event field, useful to
>you? 
>-
>
>Would you like to consume streams other than RecentChanges?
>  (Currently
>available events are described the event-schemas repository
>
> 
>.)
>
>
>
> Thanks!
> - Andrew Otto
>
> [1] https://wikitech.wikimedia.org/wiki/EventStreams
> [2] https://www.mediawiki.org/wiki/EventStreams/Blog_-_Call_For_Entries
> [3]
> https://github.com/wikimedia/mediawiki-event-schemas/tree/master/jsonschema/mediawiki
> [4] https://www.mediawiki.org/wiki/Talk:EventStreams
>
>
>
>

[Wikitech-l] IRC: wm-bot logs temporary outage

[Petr Bena]

Hi folks,

Just letting you know that wm-bot logs will not be available for a day
or two, reason is required migration to different OS as current OS is
no longer accepted on wikimedia labs and all instances that are
running it have to be terminated.

If you want to track progress see https://phabricator.wikimedia.org/T157838

Bot is already up and running on new Debian instance and new logs are
being collected, but the web server and web scripts are still not
fully operational, we need to migrate about 3GB of text log files from
IRC channels and also postgre DB which has similar size (not sure how
to do that on-line, probably not even possible).

Having say that, there may be some more outages because of postgre
server switch, but they shouldn't be so much visible.

Sorry for turbulences and thank you for your patience

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

Re: [Wikitech-l] What happened to RobLa?

[Petr Bena]

Hello,

I don't like to sound like a bad guy, but I really find it quite
inappropriate to discuss this sort of stuff on a public mailing list.
This really is a personal matter. If he didn't post any dramatical
announcement perhaps he wanted to "leave quietly"?

You know, people sometimes do this sort of stuff for very personal
reasons, they just don't want to discuss with public, and who knows,
maybe he would return back one day? He wouldn't be first to do that :)
Or maybe he is going to stick around as a volunteer? Let's be
optimistic!

If you really want to know the details, you can always ask him
directly. Fortunately he is not dead, so no need to mourn him. As an
employee of WMF, he was always very friendly and extremely useful, so
indeed I /do/ hope he will stay with us, at least as a volunteer.

On Thu, Nov 3, 2016 at 10:16 AM, Tilman Bayer  wrote:
> On Tue, Nov 1, 2016 at 3:54 AM, Federico Leva (Nemo) 
> wrote:
>
>> As a reminder on goodbyes, WMF HR used to announce everyone's last day at
>> https://identi.ca/wikimediaatwork (can't take more than a couple
>> minutes); then the announcements became monthly, then quarterly; then we
>> lost this courtesy as well https://meta.wikimedia.org/wik
>> i/Talk:Wikimedia_Foundation_reports#Staff .
>
>
> As already noted higher up on that talk page, that's a misconception.
> Timely updates now happen on the WMF wiki instead, where RobLa's departure
> had already been recorded by HR before you sent this email:
> https://wikimediafoundation.org/w/index.php?title=Template:Staff_and_
> contractors&action=history
>
>
>>
>
>
> --
> Tilman Bayer
> Senior Analyst
> Wikimedia Foundation
> IRC (Freenode): HaeB
> ___
> 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] irc.wikimedia.org (kraz) reboot

[Petr Bena]

Yep a rewrite that consists of tossing 2000+ lines of code and
replacing them with, eh, 3 lines?

https://github.com/huggle/XMLRCS/tree/master/clients/c%23/XmlRcs

:p

On Fri, Oct 21, 2016 at 4:59 PM, Danny B.  wrote:
>
>
> -- Původní zpráva --
> Od: Petr Bena 
> Komu: Wikimedia developers 
> Datum: 21. 10. 2016 0:44:50
> Předmět: Re: [Wikitech-l] irc.wikimedia.org (kraz) reboot
>
> "Or you can fix them by using alternative RC providers:
> http://wikitech.wikimedia.org/wiki/RCFeed
> "
> That's actually not a fix, but complete rewrite.
>
>
> Danny B.
> ___
> 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] irc.wikimedia.org (kraz) reboot

[Petr Bena]

Or you can fix them by using alternative RC providers:
http://wikitech.wikimedia.org/wiki/RCFeed

On Thu, Oct 20, 2016 at 7:47 PM, Daniel Zahn  wrote:
> Hi,
>
> this is to let you know that kraz, the server that runs irc.wikimedia.org
> had to be rebooted for a kernel upgrade.
>
> If you have IRC clients on that server (i know some use it for
> anti-vandal tools etc), and the clients don't auto-reconnect, please
> make them connect again now. (And ideally fix them so they
> automatically do it in the future).
>
> Thank you
>
> --
> Daniel Zahn 
> Operations Engineer
>
> ___
> 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] Dumps.wm.o access will be https only

[Petr Bena]

Can you give us some justification for this change? It's not like when
downloading dumps you would actually leak some sensitive data...

On Fri, Apr 1, 2016 at 1:03 PM, Ariel Glenn WMF  wrote:
> We plan to make this change on April 4 (this coming Monday), redirecting
> plain http access to https.
>
> A reminder that our dumps can also be found on our mirror sites, for those
> who may have restricted https access.
>
> Ariel Glenn
> ___
> 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] Is there some non-ssl mirror of wikipedia?

[Petr Bena]

I noticed that since we enforce SSL on Wikipedia for everyone,
Wikipedia is much more restricted in some countries, such as China,
where it's entirely blocked (I think only SSL is blocked, but users
now have no option to fall back to non-ssl version).

Is there some non-ssl mirror for people in these countries? Or did we
just gave up on "free knowledge for everyone"?

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

Re: [Wikitech-l] Compression with API

[Petr Bena]

Interesting. I was googling for something like that, but for whatever
reasons it just wasn't anywhere in the results...

On Mon, Nov 30, 2015 at 5:12 PM, Brad Jorsch (Anomie)
 wrote:
> On Mon, Nov 30, 2015 at 11:10 AM, Petr Bena  wrote:
>
>> Is there any reason not to do that?
>>
>
> That the HTTP Accept-Encoding header[1] already exists?
>
>  [1]: https://tools.ietf.org/html/rfc7231#section-5.3.4
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> 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] Compression with API

[Petr Bena]

Hi,

I created this ticket: https://phabricator.wikimedia.org/T119878

The basic idea is that it shouldn't be a big problem to compress
output of api.php script using some widely available library, like
gzip.

That way the size of communication between client and server would be
much smaller and users with slow internet might benefit from this. I
am not sure how much the data would be reduced, but it could be a
significant number in some cases.

What do you think about it? Is there any reason not to do that?

Note I don't propose some breaking change, rather just create an
optional parameter "compression" that would be passed for API
requests.

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

Re: [Wikitech-l] Compression with API

[Petr Bena]

Also, mobile phones would probably benefit from this most, if there is
some wiki-reader app that uses API for it to work.

On Mon, Nov 30, 2015 at 5:10 PM, Petr Bena  wrote:
> Hi,
>
> I created this ticket: https://phabricator.wikimedia.org/T119878
>
> The basic idea is that it shouldn't be a big problem to compress
> output of api.php script using some widely available library, like
> gzip.
>
> That way the size of communication between client and server would be
> much smaller and users with slow internet might benefit from this. I
> am not sure how much the data would be reduced, but it could be a
> significant number in some cases.
>
> What do you think about it? Is there any reason not to do that?
>
> Note I don't propose some breaking change, rather just create an
> optional parameter "compression" that would be passed for API
> requests.

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

Re: [Wikitech-l] Git for idiots

[Petr Bena]

Ok, I will try to merge all useful stuff in here:
https://www.mediawiki.org/wiki/Git_for_dummies

On Tue, Nov 10, 2015 at 8:26 PM, Nick Wilson (Quiddity)
 wrote:
> On Tue, Nov 10, 2015 at 10:54 AM, Legoktm  wrote:
>>
>> Hi,
>>
>> On 11/10/2015 09:06 AM, Petr Bena wrote:
>> > Perhaps it would worth merging and putting to some central location?
>>
>> Yes, that sounds like a good idea. I typically recommend
>> <https://www.mediawiki.org/wiki/User:Wctaiwan/Gerrit_cheatsheet> to
>> people who are confused with git.
>>
>
> +1, as someone who uses it rarely enough to /always/ have to consult the FAQs.
> I compiled a list at https://www.mediawiki.org/wiki/Git/Tips#See_also
> and posted at https://www.mediawiki.org/wiki/Topic:Ssg7cjp65lw1oc7y
>
> ___
> 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] Git for idiots

[Petr Bena]

Now I also found this awesome guide:
https://www.mediawiki.org/wiki/User:Aude/Git

Perhaps it would worth merging and putting to some central location?

On Tue, Nov 10, 2015 at 5:58 PM, Petr Bena  wrote:
> Hello,
>
> I would like to remind that I made this guide some time ago:
>
> https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
>
> It always quite sucked and still does, but I tried to slightly rewrite
> it now, so it should contain more accurate information.
>
> I would like to keep it as a super simple manual / cheat sheet for
> git, that is as much clear and simple as possible.
>
> If you ever struggled with git, maybe it could help you. If you are a
> git expert you may want to contribute to it? The name of the guide may
> not be a best choice, so I might eventually move it to [[Git for
> dummies]] or something like that, so that it sounds a bit more
> friendly.
>
> I don't know if we already have any super simple guide / cheat sheet
> for git, where you could find everything essential on 1 page (and it
> was a wiki page editable by everyone), but I think we don't. We might
> use this as one?

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

[Wikitech-l] Git for idiots

[Petr Bena]

Hello,

I would like to remind that I made this guide some time ago:

https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots

It always quite sucked and still does, but I tried to slightly rewrite
it now, so it should contain more accurate information.

I would like to keep it as a super simple manual / cheat sheet for
git, that is as much clear and simple as possible.

If you ever struggled with git, maybe it could help you. If you are a
git expert you may want to contribute to it? The name of the guide may
not be a best choice, so I might eventually move it to [[Git for
dummies]] or something like that, so that it sounds a bit more
friendly.

I don't know if we already have any super simple guide / cheat sheet
for git, where you could find everything essential on 1 page (and it
was a wiki page editable by everyone), but I think we don't. We might
use this as one?

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

Re: [Wikitech-l] Parsoid still doesn't love me

[Petr Bena]

Do you really want to say that reading from disk is faster than
processing the text using CPU? I don't know how complex syntax of mw
actually is, but C++ compilers are probably much faster than parsoid,
if that's true. And these are very slow.

What takes so much CPU time in turning wikitext into html? Sounds like
JS wasn't a best choice here.

On Fri, Nov 6, 2015 at 11:37 PM, Gabriel Wicke  wrote:
> We don't currently store the full history of each page in RESTBase, so your
> first access will trigger an on-demand parse of older revisions not yet in
> storage, which is relatively slow. Repeat accesses will load those
> revisions from disk (SSD), which will be a lot faster.
>
> With a majority of clients now supporting HTTP2 / SPDY, use cases that
> benefit from manual batching are becoming relatively rare. For a use case
> like revision retrieval, HTTP2 with a decent amount of parallelism should
> be plenty fast.
>
> Gabriel
>
> On Fri, Nov 6, 2015 at 2:24 PM, C. Scott Ananian 
> wrote:
>
>> I think your subject line should have been "RESTBase doesn't love me"?
>>  --scott
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Gabriel Wicke
> Principal Engineer, 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] AWS usage

[Petr Bena]

As to why:

AWS is more flexible and more reliable than wikimedia-labs, other than
that it's basically the same. If they really need to use AWS it's
probably because they don't like the restrictions that come with
wikimedia labs (stuff must be open source, comply with policies, only
ubuntu or debian, no proprietary software, hard-to-get public IP, long
waiting time for stuff that you can't do yourself (request new
project), no IPv6 and many others)

On Thu, Oct 8, 2015 at 6:08 AM, John Mark Vandenberg  wrote:
> On Thu, Oct 8, 2015 at 1:54 AM, Petr Bena  wrote:
>> Hi,
>>
>> Why do you even care? Is this question directed to foundation only or
>> community developers as well? "Used by wikimedia" is very broad term.
>
> Pywikibot uses Travis-CI, and I was looking at their S3 artefacts
> integration for storage of coverage data.
> It turns out to be quite a bit more expensive than I had assumed.
> https://phabricator.wikimedia.org/T74863#1710830
>
> Also of interest was that given some people are dead against allowing
> Travis-CI to do builds for free, it appears parts of our community are
> using AWS directly instead of Labs, which is not free.
>
> I used the broad term "Wikimedia", as it is the broader community that
> could be using Labs.  It seems to be worth understanding why they are
> choosing to not use Labs, and how much it is costing "us".
>
> --
> John Vandenberg
>
> ___
> 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] AWS usage

[Petr Bena]

Sorry, I mentioned the question for OP of this thread.

On Wed, Oct 7, 2015 at 5:06 PM, Greg Grossmeier  wrote:
> 
>> Why do you even care? Is this question directed to foundation only or
>> community developers as well? "Used by wikimedia" is very broad term.
>
> I interpreted "Wikimedia" as WMF, for better or worse, in my email, just
> so it's clear.
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> 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] AWS usage

[Petr Bena]

Hi,

Why do you even care? Is this question directed to foundation only or
community developers as well? "Used by wikimedia" is very broad term.



On Wed, Oct 7, 2015 at 4:42 PM, Greg Grossmeier  wrote:
> 
>> Is AWS (Amazon Web Services) being used by Wikimedia directly; US
>> Foundation, or by other affiliates?
>
> Not for anything user facing. I *think* the Performance team uses AWS
> for a testing hosting (it runs Windows, I think, or I'm confusing it
> with another team).
>
>> All use of Travis-CI is indirectly using AWS.  Are there other indirect uses?
>
> Travis-CI is only currently used by a very small number of repositories,
> luckily.
>
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> 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] Wikitext linting service

[Petr Bena]

Hello,

I would like to get your input for this potential Google-Code /
Outreachy task: https://phabricator.wikimedia.org/T114631

Quick summary: Right now there is no simple way to detect syntax
errors of a wikicode (text user input as a source code for wiki page).
Its existence would make it simple for tools and bots to validate
wikitext (tools like ORES, Huggle, AWB and many others) as well as it
could make it possible for new features such as real-time syntax
checking to be implemented into MediaWiki (so that user would be
notified about syntax errors while typing the source code or upon page
saving).

Before this task gets proposed I would like to discuss it, whether
it's needed, who would benefit from it, how it should be implemented
and so on. Please respond to the phabricator task if possible.

Thank you

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

Re: [Wikitech-l] Understanding weird behaviour of diffto in API

[Petr Bena]

yay, that fixed the problem, thanks :o

On Tue, Sep 15, 2015 at 6:24 PM, Brad Jorsch (Anomie)
 wrote:
> On Tue, Sep 15, 2015 at 11:53 AM, Petr Bena  wrote:
>
>> Just to make clear what my problem is, here is example. There is a
>> user 75.69.113.86 who made 3 consecutive edits to page "Battle
>> Tendency". These edits can be displayed using these 3 API's:
>>
>> *
>> https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167574&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml
>
>
> This diff is from 679358832 to 681167574.
>
>
>> *
>> https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167835&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml
>
>
> This is from 681167574 to 681167835.
>
>
>> *
>> https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167909&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml
>
>
> And this is from 681167835 to 681167909.
>
>
>> The combined diff of all three edits I am trying to get has link
>>
>> https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167574&rvdiffto=681167909&titles=Battle%20Tendency&rawcontinue=1&format=xml
>>
>> but as you can see, it's not actually containing all these changes.
>> Why is that?
>
>
> Because you're asking for the diff from 681167574 to 681167909 (which
> covers only the last two of your three links), not the diff from
> *679358832* to 681167909.
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> 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] Understanding weird behaviour of diffto in API

[Petr Bena]

Just to make clear what my problem is, here is example. There is a
user 75.69.113.86 who made 3 consecutive edits to page "Battle
Tendency". These edits can be displayed using these 3 API's:

* 
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167574&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml
* 
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167835&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml
* 
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167909&rvdiffto=prev&titles=Battle%20Tendency&rawcontinue=1&format=xml

The combined diff of all three edits I am trying to get has link
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment&rvlimit=1&rvstartid=681167574&rvdiffto=681167909&titles=Battle%20Tendency&rawcontinue=1&format=xml

but as you can see, it's not actually containing all these changes.
Why is that? I would like to see a diff of these 3 edits from
681167574 which is oldest to 681167909 which in time of me writing
this was last revision.

On Tue, Sep 15, 2015 at 5:39 PM, Petr Bena  wrote:
> That "compare" feature look promising. Thanks
>
> On Tue, Sep 15, 2015 at 5:36 PM, Brad Jorsch (Anomie)
>  wrote:
>> On Tue, Sep 15, 2015 at 10:39 AM, Petr Bena  wrote:
>>
>>> I suppose in that case I would set RevID to 520 and DiffTo to 20. That
>>> however doesn't seem to work. It shows the diff, but other way, it
>>> shows diff from 520 to 20 (and I think it even excludes that revision)
>>> not from 20 to 520, including both 20 and 520.
>>>
>>
>> Yes, because you're diffing *from* 520 *to* 20.
>>
>> If you have two specific revisions you're trying to compare, you might just
>> want to look at action=compare
>> <https://en.wikipedia.org/w/api.php?modules=compare>.
>>
>>
>>> Even more weird thing that happens to me, is that when I swap RevID and
>>> DiffTo, the results seem to be identical.
>>>
>>
>> That seems doubtful.
>>
>>
>> --
>> Brad Jorsch (Anomie)
>> Senior Software Engineer
>> 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] Understanding weird behaviour of diffto in API

[Petr Bena]

That "compare" feature look promising. Thanks

On Tue, Sep 15, 2015 at 5:36 PM, Brad Jorsch (Anomie)
 wrote:
> On Tue, Sep 15, 2015 at 10:39 AM, Petr Bena  wrote:
>
>> I suppose in that case I would set RevID to 520 and DiffTo to 20. That
>> however doesn't seem to work. It shows the diff, but other way, it
>> shows diff from 520 to 20 (and I think it even excludes that revision)
>> not from 20 to 520, including both 20 and 520.
>>
>
> Yes, because you're diffing *from* 520 *to* 20.
>
> If you have two specific revisions you're trying to compare, you might just
> want to look at action=compare
> <https://en.wikipedia.org/w/api.php?modules=compare>.
>
>
>> Even more weird thing that happens to me, is that when I swap RevID and
>> DiffTo, the results seem to be identical.
>>
>
> That seems doubtful.
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> 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] Understanding weird behaviour of diffto in API

[Petr Bena]

I am trying to understand how this works:
https://www.mediawiki.org/wiki/API:Revisions

There is a parameter DiffTo which says: Revision ID to diff each
revision to. Use "prev", "next" and "cur" for the previous, next and
current revision respectively.

I suppose that I can give it revision ID instead of that string hint.
So let's say we have 4 edits made to the page [[X]], their ID's are:

* 520
* 510
* 20
* 1

Now I want to create a diff of last three changes, so that I see what
has changed from revision 20 until revision 520 INCLUDING these 2
revisions, that means, I want to see all changes that were made in 20,
510 and 520 up to the current version.

I suppose in that case I would set RevID to 520 and DiffTo to 20. That
however doesn't seem to work. It shows the diff, but other way, it
shows diff from 520 to 20 (and I think it even excludes that revision)
not from 20 to 520, including both 20 and 520.

How does the whole thing actually work? I might need something like
"DiffFrom" when I think of that, but there is no such a thing. Even
more weird thing that happens to me, is that when I swap RevID and
DiffTo, the results seem to be identical.

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

Re: [Wikitech-l] The "other" developers at the Wikimedia Developer Summit

[Petr Bena]

Is there going to be a hangout stream for the presentations so that
people who can't attend (trip is just too expensive) can see or
participate at them?

On Tue, Sep 15, 2015 at 2:21 PM, Quim Gil  wrote:
> You have probably read the announcement of the Wikimedia Developer Summit
> 2016 registration and call for participation.
>
> https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
>
> I just want to stress that this year we are putting a special emphasis on
> inviting not only the developers of MediaWiki core, extensions, and APIs,
> but also the "other" developers using this platform to create gadgets,
> bots, templates, tools, apps, and third party products relying on Wikimedia
> APIs.
>
> We want to increase their participation bringing their own proposals and
> joining others' as stakeholders, and we want to meet with them during the
> event in San Francisco. We have a modest sponsorship travel budget for
> those registering before OCTOBER 2nd (deadline for presentation of new
> proposals).
>
> Reaching out to all these developers is not simple, as they are quite
> spread. Your help forwarding our invitation to the appropriate communities,
> mailing lists, Talk pages, etc, is very welcome.
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] Phabricator filter by language

[Petr Bena]

As I said this would be optional just for tickets where you actually
need help of someone who understand that language, for example in
Huggle we know C++, but aren't really good with CSS which we need help
with as well. There are some tickets that need a look of CSS expert
but right now there is no way to point that out.

On Tue, Jul 28, 2015 at 6:02 PM, Stephen Niedzielski
 wrote:
>   We have a couple templates[0] for reporting bugs in the Android app that
> would almost always be "language-java". I'm sure we could add the
> appropriate tags when they exist, although it might be a little redundant.
> On a related note, we've been trying to add the "Easy" tag where
> appropriate.
>
>
> --stephen
>
> [0] https://phabricator.wikimedia.org/T104086
>
> On Tue, Jul 28, 2015 at 8:00 AM, Quim Gil  wrote:
>
>> On Fri, Jul 17, 2015 at 10:04 AM, Petr Bena  wrote:
>>
>> > Hi,
>> >
>> > What if we added extra projects to phabricator for programming
>> > languages (such as language-php, language-c)
>>
>>
>> I think a previous step should e to have landing pages for such languages
>> in mediawiki.org, pointing to the main projects and resources related to
>> such languages. Quite often we meet new potential developers that want to
>> contribute but have no strong opinion about where. They do have an opinion
>> about their programming skills, so usually the reply is I can code in this
>> or that language.
>>
>> Once a page like i.e. mw:Java exists and it is linked from the right
>> venues, then it starts making sense to tag Phabricator tasks requiring Java
>> skills, hopefully finding some Easy ones to offer a great search query for
>> whoever might be interested.
>>
>> Related: https://phabricator.wikimedia.org/T91633 (the 'what I can do
>> for...' idea, which at least in the case of Mozilla started by asking you
>> to choose a programming langiage).
>>
>> --
>> Quim Gil
>> Engineering Community Manager @ Wikimedia Foundation
>> http://www.mediawiki.org/wiki/User:Qgil
>> ___
>> 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] Wikipedia iOS app moving to GH

[Petr Bena]

Force pushes can be disabled if you contact github support

On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza  wrote:
> On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena  wrote:
>
>> Good job, you aren't the only one. Huggle team is using it for quite
>> some time. To be honest I still feel that github is far superior to
>> our gerrit installation and don't really understand why we don't use
>> it for other projects too.
>>
>
> GitHub is focused on small projects; for a project with lots of patches and
> committers it is problematic in many ways:
> * poor repository management (fun fact: GitHub does not even log force
> pushes, much less provides any ability to undo them)
> * noisy commit histories due to poor support of amend-based workflows, and
> also because poor message generation of the editing interface (Linus wrote
> a famous rant
> <https://github.com/torvalds/linux/pull/17#issuecomment-5654674> on that)
> * no way to mark patches which depend on each other
> * diff view works poorly for large patches
> * CR interface works poorly for large patches (no way to write draft
> comments so you need to do two passes; discussions can be marked as
> obsolete by unrelated code changes in their vicinity)
> * hard to keep track of cherry-picks
> ___
> 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 iOS app moving to GH

[Petr Bena]

Good job, you aren't the only one. Huggle team is using it for quite
some time. To be honest I still feel that github is far superior to
our gerrit installation and don't really understand why we don't use
it for other projects too.

The GitHub's pull requests are more compliant with original git
philosophy of Linus, see this video:
https://www.youtube.com/watch?v=4XpnKHJAok8 and would be sufficient
replacement to our current "git-review" mechanism, which is very
complex and unfriendly to new developers who probably find it very
difficult to use.

On Wed, Jul 22, 2015 at 12:40 PM, Brian Gerstle  wrote:
> Hey everyone,
>
> I'm writing with plans for the Wikimedia iOS engineering team to move its
> workflow to GitHub with Travis CI, much like RESTbase.
>
> The Wikimedia iOS engineers have been maintaining their own CI and build
> server and using Gerrit for code review. The more time efficient and
> commonplace approach for open source iOS software development leans heavily
> on GitHub with Travis CI instead (e.g., WordPress[0][1] and Firefox[2][3]).
> By using GitHub with Travis CI, the team believes it will work faster,
> improve testing, grow developer confidence in making code changes, and,
> most importantly, deploy fewer bugs to production.
>
> For builds requiring sensitive information (e.g., prod certs), will
> continue to run on WMF's Mac Mini. As is done for Android, when betas are
> pushed, the team will notify mobile-l.
>
> Feel free to reply or email me directly with any questions or comments.
>
> Regards,
>
> Brian
>
> 0: https://github.com/wordpress-mobile/WordPress-iOS
> 1: https://travis-ci.org/wordpress-mobile/WordPress-iOS
> 2: https://github.com/mozilla/firefox-ios
> 3: https://travis-ci.org/mozilla/firefox-ios
>
> --
> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
> IRC: bgerstle
> ___
> 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] Phabricator filter by language

[Petr Bena]

Asking of stackoverflow to resolve a phabricator task is same as
asking there to do your homework.

How is CSS not common amongst MediaWiki, did something change recently? :P

On Sun, Jul 19, 2015 at 3:39 AM, Gergo Tisza  wrote:
> On Fri, Jul 17, 2015 at 3:04 AM, Petr Bena  wrote:
>
>> What if we added extra projects to phabricator for programming
>> languages (such as language-php, language-c) which could be optionally
>> added to some tickets if help of people who know these languages would
>> be needed. So that it would be possible for example to c++ experts to
>> filter out open tasks that need c++ expert to look in them and so on?
>>
>> Currently I have few of such tasks that I would like to have experts
>> in some language to look at, but there isn't really an easy way to do
>> that.
>>
>> What you think? Should we add these meta-projects?
>>
>
> Having a tag does not make experts magically find the task, especially for
> languages wich are relatively uncommon amongst MediaWiki devs. IMO it's
> more practical to ask on StackOverflow or ##c++ or some other forum that's
> specifically a gathering place for language experts.
> ___
> 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] Phabricator filter by language

[Petr Bena]

That's not useful at all. What is I wanted to filter out all tickets
that need some python expert to look at them? How is knowledge that
pywikibot uses python good for that? I don't need this per project,
but per ticket. For example I need a CSS expert to look at some ticket
of huggle, which is a C++ project. I would happily flag it
"need-css-expert" or whatever but there is no option for that. Also if
I was an expert in some expert, I would like to be able to filter out
tickets made by people who need me :P

On Fri, Jul 17, 2015 at 10:25 AM, Ricordisamoa
 wrote:
> You can already infer some languages from the project: Pywikibot → Python,
> Hierator → Java etc.
> And nearly any other one will have language-php then. But for C++ it might
> still make sense.
>
>
> Il 17/07/2015 10:04, Petr Bena ha scritto:
>>
>> Hi,
>>
>> What if we added extra projects to phabricator for programming
>> languages (such as language-php, language-c) which could be optionally
>> added to some tickets if help of people who know these languages would
>> be needed. So that it would be possible for example to c++ experts to
>> filter out open tasks that need c++ expert to look in them and so on?
>>
>> Currently I have few of such tasks that I would like to have experts
>> in some language to look at, but there isn't really an easy way to do
>> that.
>>
>> What you think? Should we add these meta-projects?
>>
>> ___
>> 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] Phabricator filter by language

[Petr Bena]

Hi,

What if we added extra projects to phabricator for programming
languages (such as language-php, language-c) which could be optionally
added to some tickets if help of people who know these languages would
be needed. So that it would be possible for example to c++ experts to
filter out open tasks that need c++ expert to look in them and so on?

Currently I have few of such tasks that I would like to have experts
in some language to look at, but there isn't really an easy way to do
that.

What you think? Should we add these meta-projects?

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

Re: [Wikitech-l] [IRC] BotBot logs

[Petr Bena]

Yes it was, labs still didn't recover from the outage:
https://phabricator.wikimedia.org/T103696?workflow=103265

On Fri, Jun 26, 2015 at 3:19 AM, Stephen Niedzielski
 wrote:
>   This seems to have stopped working a few days ago. I get a 502 Bad
> Gateway. I was thinking it was probably related to the recent labs woes but
> it never came back.
>
>
> --stephen
>
> On Sat, Jun 13, 2015 at 2:40 PM, Keegan Peterzell 
> wrote:
>
>> Very cool. Thank you, Petr.
>>
>> --
>> Keegan Peterzell
>> Community Liaison, Product
>> 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

Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

[Petr Bena]

There is no such a thing like "properly break". That's like if someone
was happily sad. Come on

On Thu, Jun 18, 2015 at 4:09 PM, Brad Jorsch (Anomie)
 wrote:
> On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan 
> wrote:
>
>> On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg 
>> wrote:
>>
>> >
>> > The API currently emits a warning if a query continuation mode isnt
>> > selected.
>> >
>> > I guess on July 1 the API could emit an error, and not return any query
>> > data.
>> > Then the data isnt going to cause weird behaviour - it will break,
>> > properly.
>> >
>> >
>> Hmm, this is actually an interesting idea - would it make sense to error on
>> missing "continue" or "rawcontinue" for all action=query for about a month
>> or two, so that everyone notices it right away and gets updated, and than
>> resume with the new behavior?
>
>
> I saw at least one major bot had all of its actual continuation uses fixed
> after the first notification, but did not bother to fix cases where it was
> receiving the warning but was never going to continue the query. Others may
> well have done the same.
>
> For example, if a client wants to get the current content for enwiki's Main
> Page, it might hit
> https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&rvlimit=1&titles=Main%20Page.
> That returns continuation (and the warning) in case the client would want
> further revisions, but the client here doesn't. Similar cases could be made
> for fetching the most recent protection log entry of a page, the imageinfo
> for the current version of an image, and so on.
>
> The current plan, as shown in https://gerrit.wikimedia.org/r/#/c/160223/,
> is to output a different warning for some period of time after the
> changeover. People investigating the sudden failure of their
> bot/script/gadget would hopefully see that.
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> 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] [IRC] BotBot logs

[Petr Bena]

I fixed slugs now, so every channel has perma links in format of
http://botbot.wmflabs.org/freenode/CHANNEL for example
http://botbot.wmflabs.org/freenode/wikimedia-labs/

On Sat, Jun 13, 2015 at 4:54 PM, Petr Bena  wrote:
> Hi,
>
> Krinkle wanted to use BotBot.me log viewer as a frontend for wm-bot's
> logs. It unfortunatelly uses slightly different database schemas, but
> I managed to create some views in wm-bot's db that actually produces
> similar columns and behold! It works:
> http://botbot.wmflabs.org/freenode/15/
>
> Well, to a point. Some features do not work yet, such as searching,
> but I will look into it. Let me know if anything didn't work as
> expected! Also, don't even bother unchecking hide join / part it will
> not work. wm-bot stores irc commands as numerics while BotBot uses
> text column here. I can create some procedure in SQL to convert this,
> but it wouldn't work with indexes and that would totally kill the
> performance of log viewer, so I am afraid these won't be available for
> a while.
>
> Have fun

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

[Wikitech-l] [IRC] BotBot logs

[Petr Bena]

Hi,

Krinkle wanted to use BotBot.me log viewer as a frontend for wm-bot's
logs. It unfortunatelly uses slightly different database schemas, but
I managed to create some views in wm-bot's db that actually produces
similar columns and behold! It works:
http://botbot.wmflabs.org/freenode/15/

Well, to a point. Some features do not work yet, such as searching,
but I will look into it. Let me know if anything didn't work as
expected! Also, don't even bother unchecking hide join / part it will
not work. wm-bot stores irc commands as numerics while BotBot uses
text column here. I can create some procedure in SQL to convert this,
but it wouldn't work with indexes and that would totally kill the
performance of log viewer, so I am afraid these won't be available for
a while.

Have fun

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

Re: [Wikitech-l] Wikipedia-Europe PMC hackathon

[Petr Bena]

\O/ MORE HACKATHONS per year! yay

On Tue, Jun 9, 2015 at 4:53 PM, Dan Bolser  wrote:
> Sorry if this is the wrong list, please feel free to distribute as
> appropriate...
>
> Details (developing) here:
> https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Computational_Biology/EBI_hackathon_on_September_4,_2015
>
> Message from Jo McEntyre:
>
> We are organising a Wikipedia-Europe PMC hackathon on 4th Sept on the
> genome campus, around the Wikipedia Science conference:
> https://wikimedia.org.uk/wiki/Wikipedia_Science_Conference.
>
> With Daniel Mietchen, the three themes we have identified are:
> - contributing datasets e.g. data citations, text-mined entities from
> Europe PMC to Wikidata & possibly seeing this pushed through to some
> Wikipedia pages
> -  import of full text articles into Wikisource and potential
> highlighting named entities
> - pushing PMID-PMCID-DOI mapping to Wikidata/Wikipedia
>
> We would very much like you to attend!
> ___
> 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-api-announce] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

[Petr Bena]

* 3.1.5 not 3.15, sorry for confusion :P

On Thu, Jun 4, 2015 at 3:19 PM, Petr Bena  wrote:
> Out of curiosity, this may also break all versions of huggle that are
> older than 3.15, which was released sometime around November 2014.
>
> I strongly recommend you to upgrade if you are using such an ancient
> version. I don't know what is going to happen, but it may break.
> Unless someone patches the legacy huggle version, it will probably
> remain defunct.
>
>
> On Wed, Jun 3, 2015 at 11:23 PM, Maarten Dammers  wrote:
>> Hi,
>>
>> Brad Jorsch (Anomie) schreef op 3-6-2015 om 18:43:
>>>
>>> 
>>
>> Could you please stop using the announce list for chatter? Probably better
>> to put the announce list on moderation.
>>
>> Maarten
>>
>>
>>
>> ___
>> 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-api-announce] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

[Petr Bena]

Out of curiosity, this may also break all versions of huggle that are
older than 3.15, which was released sometime around November 2014.

I strongly recommend you to upgrade if you are using such an ancient
version. I don't know what is going to happen, but it may break.
Unless someone patches the legacy huggle version, it will probably
remain defunct.


On Wed, Jun 3, 2015 at 11:23 PM, Maarten Dammers  wrote:
> Hi,
>
> Brad Jorsch (Anomie) schreef op 3-6-2015 om 18:43:
>>
>> 
>
> Could you please stop using the announce list for chatter? Probably better
> to put the announce list on moderation.
>
> Maarten
>
>
>
> ___
> 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] [IRC] wm-bot's IRC logs web viewer quick outage

[Petr Bena]

Hi,

I will be migrating wm-bot's database server to new box running
postgres today. It shouldn't harm any log collection in channels where
logging is enabled, but it will make it impossible to use the SQL
based viewer at http://tools.wmflabs.org/wm-bot/logs for a while (I
hope just few hours).

The reason for the outage is that migration will take 2 parts: First I
replace bot core with version that uses postgres - that shouldn't take
more than 1 second. Since that moment new logs will be written to
postgres, but old would still stay in MySQL. Then I will have to move
all data to postgres, logs table has millions of rows and about 8GB so
that might take a while...

So, there should be no outage in logs but web viewer won't be working
for a while.

The reason for migration is that MySQL doesn't scale very well, is
missing lots of useful features (roles, tablespaces and lots of other
advanced stuff that is very useful on labs - it supports nfs based
storage and so on), and the old server basically ran out of space.

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

[Wikitech-l] Hackathon anti-vandalism mini-conference

[Petr Bena]

Hi,

I was looking at pages on wiki and couldn't find where to submit
proposals for presentations or cons that would take place on Lyon's
hackathon, so I will post it here.

I don't know how many people who do or have done some antivandalism
(see [[w:WP:VAND|Vandalism]] for info) work in any way are going to be
at Lyon, but if there was at least a small group of people who would
be interested in following topics, it might do to set up some
mini-conference there where we could have some presentations and
discussions.

The topics would be:

WMF-specific:
* Definitions of what kind of issues we are dealing with every day (eg
what is vandalism, how much does it actually affect wikipedia,
statistics and so on)
* Overview of current technologies and tactics used to deal with
vandalism on Wikipedia add sister sites
* Collaboration - how can we connect existing tools we have in order
to make them significantly more efficient
* Future of anti-vandalism: what challenges are there going to be?
What all can we do and improve?
* Presentations of various tools we already have: application based
and web based as well as fully automated tools (ClueBot and other
tools living on labs etc) how they work and what could be improved?
* Hacking?
* Drinking? Oh yes! let's get drunk and use our vandalism knowledge to
blow up the wikipedia! :P

MW-specific:
* Is there any vandalism on small 3rd sites and would there be any use
for a tool to deal with it?
* Effective dealing with spam and robots

Is there someone who would be interested in hacking / talking about
this? Is it worth of having some mini-con on this topic at Lyon this
year?

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

Re: [Wikitech-l] Maps

[Petr Bena]

One foundation to rule them all? :P

On Wed, Mar 18, 2015 at 10:06 AM, Max Semenik  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

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Petr Bena]

Ok, here I copy my message

Petrb (talkcontribsblock)

Hi,

I think you all missed some old good rants. So here is one :) why the
hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read
and remember?


On Tue, Mar 17, 2015 at 2:42 PM, Brad Jorsch (Anomie)
 wrote:
> On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) <
> nwil...@wikimedia.org> wrote:
>
>> We’d like to hear which features you use on the current LQT boards,
>> and that you’re concerned about losing in the Flow conversion.
>
>
> Working watchlist functionality, see
> https://phabricator.wikimedia.org/T76862 and
> https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own
> pseudo-watchlist rather sucks, but at least it functions correctly.
>
> Please give us feedback at
>> https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
>> centralized, and test freely at the sandbox.[6]
>>
>
> No thanks, I prefer this mailing list thread. Feel free to copy this there
> if you want, but please reply here too
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

I randomly opened RecentChanges page on enwiki and this is what I saw:
http://img.ctrlv.in/img/15/03/06/54f9d5645eb03.png from 50 edits, at
least 8 were automated, just as much interesting as any regular bot
edit.

It usually is even worse, anyway as you can see about 20% of all edits
you can see now in recent changes are automated "bot-like" edits made
by humans. When I enable "show bots" from 50 edits I see 1 edit made
by a bot. From simple observing of recent changes you will see that
bots are producing far less edits than users with automated tools.
Still bots are problem that needs to be filtered out, while these
users are not?

This was originally my point. I don't really care if we just extend
bot flag for regular users as well, or if we create a new flag, but we
should do something about this. It would definitely make life of many
users easiers, especially those who actively review the contributions
of others.

On Fri, Mar 6, 2015 at 5:13 PM, Brad Jorsch (Anomie)
 wrote:
>  no way represents anything official>
>
> On Fri, Mar 6, 2015 at 5:19 AM, Ricordisamoa 
> wrote:
>
>> It is complex and bureaucratic on the English Wikipedia, i.e., less than
>> 1/890 of the projects.
>>
>
> I note that enwiki's process for receiving the bot flag and rules around
> bot editing are "complex and bureaucratic" in large part because what one
> person thinks is an obvious fix that no one could object to (e.g.
> "==Section==" versus "== Section ==") turns out result in a huge outcry
> when a bot is doing it all over the place.
>
> The idea is that the review process (which is basically just having one of
> a list of experienced bot operators look over the proposal for problems,
> then review some sample edits) will hopefully catch problems before they
> become a big deal, and the rules make it easier to stop for (hopefully)
> calm discussion rather than arguing while perceived disruption continues.
>
> Instead, I think bots are easily tricked by edge cases, whereas human
>> intervention usually decreases the chance of mistakes.
>>
>
> On the other hand, a tool may be more aggressive with proposing changes
> that would be fooled by edge cases while relying on the human to fix it
> before submitting. Even if the tool is not being more aggressive, the human
> is vulnerable to missing an error through inattention or through
> misunderstanding their responsibility and blindly clicking "approve".
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

If there are some issues that tool edits should be reviewed
differently than bot edits, then it is just another reason to make a
separate flag independent from bot flag for these edits. That way both
tool and bot edits could be filtered out and reviewed separately.

On Fri, Mar 6, 2015 at 5:31 PM, Petr Bena  wrote:
> I randomly opened RecentChanges page on enwiki and this is what I saw:
> http://img.ctrlv.in/img/15/03/06/54f9d5645eb03.png from 50 edits, at
> least 8 were automated, just as much interesting as any regular bot
> edit.
>
> It usually is even worse, anyway as you can see about 20% of all edits
> you can see now in recent changes are automated "bot-like" edits made
> by humans. When I enable "show bots" from 50 edits I see 1 edit made
> by a bot. From simple observing of recent changes you will see that
> bots are producing far less edits than users with automated tools.
> Still bots are problem that needs to be filtered out, while these
> users are not?
>
> This was originally my point. I don't really care if we just extend
> bot flag for regular users as well, or if we create a new flag, but we
> should do something about this. It would definitely make life of many
> users easiers, especially those who actively review the contributions
> of others.
>
> On Fri, Mar 6, 2015 at 5:13 PM, Brad Jorsch (Anomie)
>  wrote:
>> > no way represents anything official>
>>
>> On Fri, Mar 6, 2015 at 5:19 AM, Ricordisamoa 
>> wrote:
>>
>>> It is complex and bureaucratic on the English Wikipedia, i.e., less than
>>> 1/890 of the projects.
>>>
>>
>> I note that enwiki's process for receiving the bot flag and rules around
>> bot editing are "complex and bureaucratic" in large part because what one
>> person thinks is an obvious fix that no one could object to (e.g.
>> "==Section==" versus "== Section ==") turns out result in a huge outcry
>> when a bot is doing it all over the place.
>>
>> The idea is that the review process (which is basically just having one of
>> a list of experienced bot operators look over the proposal for problems,
>> then review some sample edits) will hopefully catch problems before they
>> become a big deal, and the rules make it easier to stop for (hopefully)
>> calm discussion rather than arguing while perceived disruption continues.
>>
>> Instead, I think bots are easily tricked by edge cases, whereas human
>>> intervention usually decreases the chance of mistakes.
>>>
>>
>> On the other hand, a tool may be more aggressive with proposing changes
>> that would be fooled by edge cases while relying on the human to fix it
>> before submitting. Even if the tool is not being more aggressive, the human
>> is vulnerable to missing an error through inattention or through
>> misunderstanding their responsibility and blindly clicking "approve".
>> ___
>> 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] [Wikitech] Wikimedia Hackathon Lyon: registrations opened

[Petr Bena]

I have a question regarding scholarship: is there a way to indicate
that I would like to apply for a full scholarship, but in case the
application wouldn't pass, I am also interested in partial
scholarship?

Partial scholarship is still better than none, in which case I might
not be able to attend at all...

On Fri, Mar 6, 2015 at 6:30 AM, Matthew Flaschen
 wrote:
> On 03/05/2015 12:16 PM, Sylvain Boissel wrote:
>>
>> *The registration is now open* and also includes the possibility to
>> apply for a travel, accommodation or full scholarship; You can find the
>> form at https://dons.wikimedia.fr/civicrm/event/register?reset=1&id=8
>
>
> How should volunteer developers fill it out if they are applying for a full
> scholarship (and attendance is conditional on that)?
>
> I see the "Are you a volunteer developer needing sponsorship?: yes, travel
> and accommodation" pair.
>
> However, there are some other questions where it's not clear how someone
> should/might respond (e.g. Accomodation, Payment method).
>
> A scholarships section or link at
> https://www.mediawiki.org/wiki/Lyon_Hackathon_2015 would also be helpful.
>
> Thanks,
>
> Matt Flaschen
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Cross wiki templates

[Petr Bena]

That isn't exactly what I want.

I would like to have a template {{Foo}} that would return value of
wikidata -> [[Bar]] -> property "Version" where "Bar" is hardcoded, so
no matter of page I include this template on, the value is same. Your
templates are dynamic, changing for every article you use them on.

On Wed, Mar 4, 2015 at 3:32 PM, Thomas Tanon  wrote:
>> Unfortunately I don't know of any
> examples of templates that actually do it, but maybe Wikidata people can
> provide some.
>
> It's now done by some infoboxes of the French Wikipedia like 
> https://fr.wikipedia.org/wiki/Mod%C3%A8le:Infobox_Monument
> They are implemented using this Lua module [1] that allows to describe 
> infoboxes as Lua tables. Example of description: 
> https://fr.wikipedia.org/wiki/Module:Infobox/Monument
>
> Thomas
>
> [1] https://fr.wikipedia.org/wiki/Module:Infobox
>
>> Le 4 mars 2015 à 14:58, Lydia Pintscher  a 
>> écrit :
>>
>> On Wed, Mar 4, 2015 at 2:36 PM, Petr Bena  wrote:
>>> Hi,
>>>
>>> Sorry, I know I asked about this thing recently, but I can't remember
>>> what the outcome was.
>>>
>>> I know it's currently not possible to create cross wiki templates, but
>>> is there any plan to implement this feature? For example pages like
>>> http://enwp.org/Linux contains "Latest version" and probably many
>>> other pages reference this latest version. Not only on english
>>> wikipedia, but many other wikis as well.
>>>
>>> We have the people to update all wikis when new version is out, but we
>>> don't have them for every piece of software on the planet, so having a
>>> central template that would contain DATA * that could be accessed
>>> anywhere would be nice.
>>>
>>> * Now why I highlighted DATA? Because I was thinking that project
>>> called "wikidata" would actually fit this purpose. Unfortunatelly it's
>>> not. The internal API's of wikidata do not allow for some weird
>>> security reasons to access data for any article from article with
>>> different name. So if there was entry in wikidata for linux, and I
>>> wanted to access property "version" in article [[Linux kernel
>>> history]] I wouldn't be able to do that. {{FIXME}}
>>
>> This is exactly what Wikidata is for. And the reason you can't access
>> data from arbitrary items right now isn't some weird security reason.
>> It is not being able to purge pages as data changes. The mechanism for
>> that is being rolled out now but will still take a while to get to
>> your wiki. You want to track https://phabricator.wikimedia.org/T49930
>>
>>
>> Cheers
>> Lydia
>>
>> --
>> Lydia Pintscher - http://about.me/lydia.pintscher
>> Product Manager for Wikidata
>>
>> Wikimedia Deutschland e.V.
>> Tempelhofer Ufer 23-24
>> 10963 Berlin
>> www.wikimedia.de
>>
>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>>
>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
>> unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
>> Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
>>
>> ___
>> 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] Cross wiki templates

[Petr Bena]

Hi,

Sorry, I know I asked about this thing recently, but I can't remember
what the outcome was.

I know it's currently not possible to create cross wiki templates, but
is there any plan to implement this feature? For example pages like
http://enwp.org/Linux contains "Latest version" and probably many
other pages reference this latest version. Not only on english
wikipedia, but many other wikis as well.

We have the people to update all wikis when new version is out, but we
don't have them for every piece of software on the planet, so having a
central template that would contain DATA * that could be accessed
anywhere would be nice.

* Now why I highlighted DATA? Because I was thinking that project
called "wikidata" would actually fit this purpose. Unfortunatelly it's
not. The internal API's of wikidata do not allow for some weird
security reasons to access data for any article from article with
different name. So if there was entry in wikidata for linux, and I
wanted to access property "version" in article [[Linux kernel
history]] I wouldn't be able to do that. {{FIXME}}

Thanks

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

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

[Petr Bena]

I don't believe that users would actually use it if this permission
was so hard to obtain as bot flag is (on english wiki). If there was
such a huge complex bureaucratic process for this, most of users would
just keep doing semi-automated edits as regular edits. The summary of
differences between flags:

* Bot edits are usually more trusted and are evaluated and reviewed by
different people. That means bot edits can be safely ignored by most
of users. This wouldn't really apply for semi-automated edits made by
users. They are still humans and they make mistakes, they should be
reviewed by admins, other users etc at some point. But most of regular
users can safely ignore them.
* Bot flags is hard to obtain, usually a matter of weeks. "Tool flag"
shouldn't be any harder than getting rollback permissions.
* Bot flag applies for all edits, tool flag should be used only for some edits.
* Bots are robots (non-thinking processes) that work fully
automatically. Tool edits would be made by people. There is a
difference between these 2 BUT should this difference be visible?
(this is actually a question)

In case that there is no need to differentiate between bot edits and
automated edits made by users, let's rename "bot" to "automated edit"
in bot flag (and rename whole bot flag) using different letter (b ->
a) and let's make it possible for trusted users to flag their edits as
"automated edit" even without requirement to be in "bot group". Eg.
bots would still have higher API limits, regular users not, but both
trusted and bots could mark their edits as "automated".

IMHO I don't think we need to be make a distinction between bots and
people. Bots should have "bot" in their username which makes it simple
to see if edit was made by robot or human and in both cases the edits
are automated.

On Mon, Feb 23, 2015 at 11:23 AM, Bináris  wrote:
> 2015-02-11 14:02 GMT+01:00 Ricordisamoa :
>
>> Keep in mind that it isn't always easy to tell 'tool' and 'bot' edits
>> apart. Several scripts can perform actions whose degree of automation
>> varies widely.
>> For my part, I make most of my semi-automated edits using my bot's
>> account, but many users also have separate 'flood' accounts for use with
>> Wikidata Game  and similar
>> tools.
>>
>
> Definitely this is the point. In enwiki's environment the word "bot" is
> usually meant as a fully automated tool, while other communities treat it
> differently. Let's see a major utility of Pywikibot, replace.py. This is
> equally prepared for automatic and semiautomatic mode, and some tasks may
> be solved automatically, while others -- above all spelling corrections --
> manually. This still means a very high speed rate of editing but it is
> human-controlled.
> If I use it in manual mode, it is a tool, and when I see it working well,
> and at a given point I choose "a" (replace all) instead of "y" (yes,
> replace actual occurance), it suddenly becomes a bot?
>
> I think these tool-assisted edits like AWB are essentially bot edits with
> human contribution: high speed, huge amount of edits in a short time that
> may be misused before anybody notices. Either they flood recent changes or
> if they are hidden, they are very hard to notice in case of a mistake and
> even harder to undo. Therefore the right of using AWB is equal to the right
> of using PWB and should require a highly trusted user in my opinion.
>
> That does not mean I am against a new group (which still means that every
> community may use or not use it); that means I don't see any important
> difference between "bot" and "tool" account.
> ___
> 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] Transfering domain cswp.cz to WMF

[Petr Bena]

Hi,

Long time ago I purchased domain cswp.cz in order to use it in same
way as enwp.org for czech wikipedia (cswp.org was taken by something).

I think that it would be probably better if it was owned and
maintained by WMF rather than me, but I don't really know where to
ask, neither if ops are actually interested in maintaining it, the
script which redirects the page is pretty simple:

http://cs.wikipedia.org/wiki";;
header ("Location: $target"."$uri");
exit();

I can't really provide any data on usage of this domain, because I
never collected any, but if there isn't any long-term plan for global
wiki shorteners I think this domain could be used.

Thank you

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

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

[Petr Bena]

I don't really see what is a problem here. On meta you can request
deletion of all userpages in 2 minutes, I myself got my userpages
deleted within 2 days and I didn't have to care at all. It was super
simple and it worked.

I've seen a lot of problematic deployments of things that didn't work,
but this is not a case, believe me.

On Sun, Feb 22, 2015 at 12:37 PM, Andre Klapper  wrote:
> Emilio,
>
> it is in everybody's interest that Wikimedia is an environment where
> people treat each other with respect and assume that people mean well.
> Criticize ideas instead of people. There is some guidance at
> http://wikimediafoundation.org/wiki/Code_of_conduct_policy
>
> Thank you.
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> 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] If you hear about 'hackathon buddies'...

[Petr Bena]

Is there any limit for a number of buddies? I suppose that one WMF
employee can have more than 1 non-WMF buddy, otherwise the limit of
non-WMF people at hackathon would equal number of employees :P

P.S. I no have a buddy :'( no one lieks me

On Thu, Feb 19, 2015 at 3:57 PM, Quim Gil  wrote:
> Yesterday we opened the travel request process for Wikimedia Foundation
> employees in Engineering and Product willing to participate at the
> Wikimedia Hackathon or Wikimania. There is no public link, but you can
> follow this task at https://phabricator.wikimedia.org/T89355
>
> In this process, we are asking WMF employees to find a hackathon buddy with
> the sole requirement of not being another WMF employee. In fact, in the
> registration for the hackathons we will request the same to all
> participants.
>
> https://www.mediawiki.org/wiki/Hackathons#Pairing_buddies
>
> This means that non-WMF contributors might receive a request from a WMF
> employee to be hackathon buddies. This also means that if you are planning
> to participate in any of these events (and especially if you plan to
> request travel sponsorship to Lyon) you will be encouraged to find a buddy
> as well.
>
> It's going to be fun.  :) And no worries, we will help making connections
> to whoever needs that help.
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] Global user pages deployed to all wikis

[Petr Bena]

Now maybe create some user friendly documentation less technical than
what is on extension-desc which tell users how to use this?

On Thu, Feb 19, 2015 at 9:30 AM, florian.schmidt.wel...@t-online.de
 wrote:
> Yeah, thanks for your work on this Kunal!
>
> enwiki: userpage deletion requested
> dewiki: local userpage deleted
>
> :D
>
> Best / Freundliche Grüße
> Florian Schmidt
>
> -Original-Nachricht-
> Betreff: [Wikitech-l] Global user pages deployed to all wikis
> Datum: Thu, 19 Feb 2015 02:07:16 +0100
> Von: Legoktm 
> An: wikitech-l@lists.wikimedia.org,  Coordination of technology deployments 
> across languages/projects 
>
> 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

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

Re: [Wikitech-l] Html.php line 269

[Petr Bena]

Most of browsers would probably handle it OK, but validators not.

On Wed, Feb 18, 2015 at 10:45 PM, Petr Bena  wrote:
> Yep
>
> That makes me feel like this is bug which everyone overlooked because
> it's true by default. If you set it to false mediawiki would likely
> write out syntactically wrong code.
>
> On Wed, Feb 18, 2015 at 10:43 PM, Gergo Tisza  wrote:
>> On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena  wrote:
>>
>>> (Perhaps wgWellFormedXml is true by default?)
>>
>>
>> It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml
>> ___
>> 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] Html.php line 269

[Petr Bena]

I think it's the other way, omiting the html tags is probably correct,
as long as both opening and ending tags are omitted :P so I think the
closeElement function needs a fix

On Wed, Feb 18, 2015 at 10:42 PM, Ricordisamoa
 wrote:
> Uploaded https://gerrit.wikimedia.org/r/191473/ for consistency with
> closeElement.
> Thanks for reporting.
>
> Il 18/02/2015 22:38, Petr Bena ha scritto:
>
>> I was digging and I found that commit you sent - eefe1b13a but you can
>> see that this commit modified 2 functions: both open and closeElement,
>> however for some reason the code was removed from closeElement so now
>> calling openElement('html') would produce empty string, while
>> closeElement('html') would produce  and that should IMHO create
>> HTML code that would only contain closing tags in case that html /
>> head didn't have any parameters. Actually head, at least on wmf
>> installation doesn't have any parameters, but it has opening tag,
>> which is weird. (Perhaps wgWellFormedXml is true by default?)
>>
>> On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber 
>> wrote:
>>>
>>> On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena  wrote:
>>>
>>>> Can someone explain the point of these lines to me?
>>>>
>>>>
>>>> https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
>>>>
>>> Someone thought it would be clever to reduce page size by a few bytes
>>> here
>>> and there. :)
>>>
>>> In practice we always have attributes on the  so this would only
>>> take
>>> effect on  for this particular case. However there are other bits
>>> which can be more aggressively dropped, such as closing tags for table
>>> parts etc.
>>>
>>> Here's the commit that added this and related bits:
>>>
>>> https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
>>>
>>>
>>>> If these tags are optional, they can be there, so why remove them? If
>>>> you remove them, you should probably also care about them in
>>>> closeElement() so that mediawiki doesn't produce html which has only
>>>> ending tags for html and head.
>>>>
>>> I believe that's also covered, yes. (Keep in mind also that the way the
>>> HTML content model works is that those elements always exist in the DOM;
>>> the tags can simply be omitted from the markup because they are implied
>>> by
>>> the surrounding content.)
>>>
>>>
>>>> It seems that on WMF installation we don't use anyway as there is head
>>>> tag. So why is it there? What purpose does it server?
>>>>
>>> I think we still have the well-formed XML mode enabled for
>>> backwards-compatibility?
>>>
>>> -- brion
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Html.php line 269

[Petr Bena]

That patch you made even breaks tests:
https://integration.wikimedia.org/ci/job/mediawiki-core-phpcs-HEAD/13002/console
:)

so either remove a unit test for that feature, or just fix the
closeElement but I don't even know if it's really broken, maybe there
is some more magic on behing that would fix the broken html before it
gets printed out

On Wed, Feb 18, 2015 at 10:47 PM, Petr Bena  wrote:
> I think it's the other way, omiting the html tags is probably correct,
> as long as both opening and ending tags are omitted :P so I think the
> closeElement function needs a fix
>
> On Wed, Feb 18, 2015 at 10:42 PM, Ricordisamoa
>  wrote:
>> Uploaded https://gerrit.wikimedia.org/r/191473/ for consistency with
>> closeElement.
>> Thanks for reporting.
>>
>> Il 18/02/2015 22:38, Petr Bena ha scritto:
>>
>>> I was digging and I found that commit you sent - eefe1b13a but you can
>>> see that this commit modified 2 functions: both open and closeElement,
>>> however for some reason the code was removed from closeElement so now
>>> calling openElement('html') would produce empty string, while
>>> closeElement('html') would produce  and that should IMHO create
>>> HTML code that would only contain closing tags in case that html /
>>> head didn't have any parameters. Actually head, at least on wmf
>>> installation doesn't have any parameters, but it has opening tag,
>>> which is weird. (Perhaps wgWellFormedXml is true by default?)
>>>
>>> On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber 
>>> wrote:
>>>>
>>>> On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena  wrote:
>>>>
>>>>> Can someone explain the point of these lines to me?
>>>>>
>>>>>
>>>>> https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
>>>>>
>>>> Someone thought it would be clever to reduce page size by a few bytes
>>>> here
>>>> and there. :)
>>>>
>>>> In practice we always have attributes on the  so this would only
>>>> take
>>>> effect on  for this particular case. However there are other bits
>>>> which can be more aggressively dropped, such as closing tags for table
>>>> parts etc.
>>>>
>>>> Here's the commit that added this and related bits:
>>>>
>>>> https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
>>>>
>>>>
>>>>> If these tags are optional, they can be there, so why remove them? If
>>>>> you remove them, you should probably also care about them in
>>>>> closeElement() so that mediawiki doesn't produce html which has only
>>>>> ending tags for html and head.
>>>>>
>>>> I believe that's also covered, yes. (Keep in mind also that the way the
>>>> HTML content model works is that those elements always exist in the DOM;
>>>> the tags can simply be omitted from the markup because they are implied
>>>> by
>>>> the surrounding content.)
>>>>
>>>>
>>>>> It seems that on WMF installation we don't use anyway as there is head
>>>>> tag. So why is it there? What purpose does it server?
>>>>>
>>>> I think we still have the well-formed XML mode enabled for
>>>> backwards-compatibility?
>>>>
>>>> -- brion
>>>> ___
>>>> Wikitech-l mailing list
>>>> Wikitech-l@lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Html.php line 269

[Petr Bena]

Yep

That makes me feel like this is bug which everyone overlooked because
it's true by default. If you set it to false mediawiki would likely
write out syntactically wrong code.

On Wed, Feb 18, 2015 at 10:43 PM, Gergo Tisza  wrote:
> On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena  wrote:
>
>> (Perhaps wgWellFormedXml is true by default?)
>
>
> It is: https://www.mediawiki.org/wiki/Manual:$wgWellFormedXml
> ___
> 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] Html.php line 269

[Petr Bena]

I was digging and I found that commit you sent - eefe1b13a but you can
see that this commit modified 2 functions: both open and closeElement,
however for some reason the code was removed from closeElement so now
calling openElement('html') would produce empty string, while
closeElement('html') would produce  and that should IMHO create
HTML code that would only contain closing tags in case that html /
head didn't have any parameters. Actually head, at least on wmf
installation doesn't have any parameters, but it has opening tag,
which is weird. (Perhaps wgWellFormedXml is true by default?)

On Wed, Feb 18, 2015 at 10:31 PM, Brion Vibber  wrote:
> On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena  wrote:
>
>> Can someone explain the point of these lines to me?
>>
>> https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
>>
>
> Someone thought it would be clever to reduce page size by a few bytes here
> and there. :)
>
> In practice we always have attributes on the  so this would only take
> effect on  for this particular case. However there are other bits
> which can be more aggressively dropped, such as closing tags for table
> parts etc.
>
> Here's the commit that added this and related bits:
> https://github.com/wikimedia/mediawiki/commit/eefe1b13a382a7d11c2137bbf900b783ee445323
>
>
>> If these tags are optional, they can be there, so why remove them? If
>> you remove them, you should probably also care about them in
>> closeElement() so that mediawiki doesn't produce html which has only
>> ending tags for html and head.
>>
>
> I believe that's also covered, yes. (Keep in mind also that the way the
> HTML content model works is that those elements always exist in the DOM;
> the tags can simply be omitted from the markup because they are implied by
> the surrounding content.)
>
>
>>
>> It seems that on WMF installation we don't use anyway as there is head
>> tag. So why is it there? What purpose does it server?
>>
>
> I think we still have the well-formed XML mode enabled for
> backwards-compatibility?
>
> -- brion
> ___
> 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] Html.php line 269

[Petr Bena]

Can someone explain the point of these lines to me?

https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269

If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.

It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?

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

Re: [Wikitech-l] IRC: wm-bot now speak with GitHub fluently

[Petr Bena]

As half of wikimedia labs just died, rendering this feature unusable,
I am taking back teh "Pretty stable" feature :/

On Tue, Feb 17, 2015 at 5:17 PM, Petr Bena  wrote:
> It wouldn't be me if I didn't forget how the whole thing works 5
> minutes after I finish it. So yes, I forgot some more details, here I
> correct the how-to guide, there is also a version on meta:
> https://meta.wikimedia.org/wiki/Wm-bot#Git_Hub
>
> How to setup:
>
> 1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
> 2) Enable relay in that channel (type @relay-on)
> 3) type @github+  for example for repository
> http://github.com/benapetr/test it would be @github+ benapetr/test
> 4) Add web hook in github settings of your repository to
> http://wm-bot.wmflabs.org/github/index.php
>
> On Tue, Feb 17, 2015 at 4:55 PM, Petr Bena  wrote:
>> I forgot few things:
>>
>> The bot used to be available to everyone, but freenode staff requested
>> me to limit it only for wikimedia people, so that there aren't people
>> who abuse it. For that reason in order to get the bot in your channel
>> you need to have wikimedia cloak, if you don't have it, just ask in
>> #wm-bot and someone will help you out.
>>
>> Also, these @github+ / @github- commands need to be issued in YOUR
>> channel, not #wm-bot
>>
>> Thanks :)
>>
>> On Tue, Feb 17, 2015 at 4:50 PM, Petr Bena  wrote:
>>> Hi folks,
>>>
>>> I was too tired of semi-working unstable random IRC services that
>>> provides IRC commit messages from github to your channel, so I created
>>> a simple plugin to wm-bot which can handle that now.
>>>
>>> Features:
>>>
>>> * It's incredibly easy to setup (10 seconds setup)
>>> * Requires no registration
>>> * Pretty stable (running on wikimedia labs)
>>> * Self-service - everyone can configure the bot as they want directly from 
>>> IRC
>>>
>>> How it works in few steps:
>>>
>>> 1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
>>> 2) type @github+  for example for repository
>>> http://github.com/benapetr/test it would be @github+ benapetr/test
>>> 3) Add web hook in github settings of your repository to
>>> http://wm-bot.wmflabs.org/github/index.php
>>>
>>> That's all
>>>
>>> Example output:
>>> (10:41:00)  GitHub [benapetr/test-wm]  benapetr pushed 1
>>> commits: 
>>> https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
>>> (10:41:00)  GitHub [benapetr/test-wm]  commit by benapetr
>>> (Petr Bena) 
>>> https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed01421ce6effe
>>> test
>>>
>>> Formatting kind of suck, but you can fix it! Handler is written in
>>> PHP: 
>>> https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/GitHub/listener/github.php

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

Re: [Wikitech-l] IRC: wm-bot now speak with GitHub fluently

[Petr Bena]

It wouldn't be me if I didn't forget how the whole thing works 5
minutes after I finish it. So yes, I forgot some more details, here I
correct the how-to guide, there is also a version on meta:
https://meta.wikimedia.org/wiki/Wm-bot#Git_Hub

How to setup:

1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
2) Enable relay in that channel (type @relay-on)
3) type @github+  for example for repository
http://github.com/benapetr/test it would be @github+ benapetr/test
4) Add web hook in github settings of your repository to
http://wm-bot.wmflabs.org/github/index.php

On Tue, Feb 17, 2015 at 4:55 PM, Petr Bena  wrote:
> I forgot few things:
>
> The bot used to be available to everyone, but freenode staff requested
> me to limit it only for wikimedia people, so that there aren't people
> who abuse it. For that reason in order to get the bot in your channel
> you need to have wikimedia cloak, if you don't have it, just ask in
> #wm-bot and someone will help you out.
>
> Also, these @github+ / @github- commands need to be issued in YOUR
> channel, not #wm-bot
>
> Thanks :)
>
> On Tue, Feb 17, 2015 at 4:50 PM, Petr Bena  wrote:
>> Hi folks,
>>
>> I was too tired of semi-working unstable random IRC services that
>> provides IRC commit messages from github to your channel, so I created
>> a simple plugin to wm-bot which can handle that now.
>>
>> Features:
>>
>> * It's incredibly easy to setup (10 seconds setup)
>> * Requires no registration
>> * Pretty stable (running on wikimedia labs)
>> * Self-service - everyone can configure the bot as they want directly from 
>> IRC
>>
>> How it works in few steps:
>>
>> 1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
>> 2) type @github+  for example for repository
>> http://github.com/benapetr/test it would be @github+ benapetr/test
>> 3) Add web hook in github settings of your repository to
>> http://wm-bot.wmflabs.org/github/index.php
>>
>> That's all
>>
>> Example output:
>> (10:41:00)  GitHub [benapetr/test-wm]  benapetr pushed 1
>> commits: 
>> https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
>> (10:41:00)  GitHub [benapetr/test-wm]  commit by benapetr
>> (Petr Bena) 
>> https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed01421ce6effe
>> test
>>
>> Formatting kind of suck, but you can fix it! Handler is written in
>> PHP: 
>> https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/GitHub/listener/github.php

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

Re: [Wikitech-l] IRC: wm-bot now speak with GitHub fluently

[Petr Bena]

I forgot few things:

The bot used to be available to everyone, but freenode staff requested
me to limit it only for wikimedia people, so that there aren't people
who abuse it. For that reason in order to get the bot in your channel
you need to have wikimedia cloak, if you don't have it, just ask in
#wm-bot and someone will help you out.

Also, these @github+ / @github- commands need to be issued in YOUR
channel, not #wm-bot

Thanks :)

On Tue, Feb 17, 2015 at 4:50 PM, Petr Bena  wrote:
> Hi folks,
>
> I was too tired of semi-working unstable random IRC services that
> provides IRC commit messages from github to your channel, so I created
> a simple plugin to wm-bot which can handle that now.
>
> Features:
>
> * It's incredibly easy to setup (10 seconds setup)
> * Requires no registration
> * Pretty stable (running on wikimedia labs)
> * Self-service - everyone can configure the bot as they want directly from IRC
>
> How it works in few steps:
>
> 1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
> 2) type @github+  for example for repository
> http://github.com/benapetr/test it would be @github+ benapetr/test
> 3) Add web hook in github settings of your repository to
> http://wm-bot.wmflabs.org/github/index.php
>
> That's all
>
> Example output:
> (10:41:00)  GitHub [benapetr/test-wm]  benapetr pushed 1
> commits: 
> https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
> (10:41:00)  GitHub [benapetr/test-wm]  commit by benapetr
> (Petr Bena) 
> https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed01421ce6effe
> test
>
> Formatting kind of suck, but you can fix it! Handler is written in
> PHP: 
> https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/GitHub/listener/github.php

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

[Wikitech-l] IRC: wm-bot now speak with GitHub fluently

[Petr Bena]

Hi folks,

I was too tired of semi-working unstable random IRC services that
provides IRC commit messages from github to your channel, so I created
a simple plugin to wm-bot which can handle that now.

Features:

* It's incredibly easy to setup (10 seconds setup)
* Requires no registration
* Pretty stable (running on wikimedia labs)
* Self-service - everyone can configure the bot as they want directly from IRC

How it works in few steps:

1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
2) type @github+  for example for repository
http://github.com/benapetr/test it would be @github+ benapetr/test
3) Add web hook in github settings of your repository to
http://wm-bot.wmflabs.org/github/index.php

That's all

Example output:
(10:41:00)  GitHub [benapetr/test-wm]  benapetr pushed 1
commits: https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
(10:41:00)  GitHub [benapetr/test-wm]  commit by benapetr
(Petr Bena) 
https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed01421ce6effe
test

Formatting kind of suck, but you can fix it! Handler is written in
PHP: 
https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/GitHub/listener/github.php

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

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

[Petr Bena]

I think it's pretty clear what I am proposing here :P there is a real
problem and this is a real solution. Regarding "vandals would have fun
with that" I think you are over estimating them, most of them are
barely able to use regular web based interface for anything more
clever than removing half of article, they don't even understand wiki
code so far to understand API interface.

On other hand if there was a privilege for this, each wiki could
restrict it as they wanted. This is not a bot flag any more than this
"wikidata" flag we have is. It's just another flag. That's all.

On Sat, Feb 14, 2015 at 10:48 PM, Brian Wolff  wrote:
>>
>> -- Every registered user would be able to flag edit as tool edit (bot
>> needs special user group)
>
> Vandals would have fun with that, but bot group could be set up like that
> (e.g. "flood" group)
>
>> -- The flag wouldn't be intended for use by robots, but regular users
>> who used some automated tool in order to make the edit
>
> Semantics of flags are up to wiki communities. They can make it mean
> whatever they desire.
>
>> -- Users could optionally mark any edit as tool edit through API only
>
> So like the bot flag (if they have the rights) :p
>
>> other suggestion that was somewhere else in thread about retroactively
> matking rdits
>
> Sounds kind of like the little known bot rollback feature minus the
> rollback aspect.
>
> --
> This sounds either like you are proposing the bot flag, with a minor
> varation in the user given semantics. Or are proposing multiple levels of
> bot flaggedness so that tool edits could be independently hidden in rc
> separate from "tool" edits.
>
> --bawolff
> ___
> 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] "Needs Volunteer" priority field value in Phabricator

[Petr Bena]

I like that volunteer flag, please keep it.

On Fri, Feb 13, 2015 at 6:42 PM, Andre Klapper  wrote:
> Apparently the idea to rename the Priority field value from "Lowest" in
> Bugzilla to "Needs Volunteer" in Phabricator created more confusion than
> expected. I am sorry for that - wasn't intended.
>
> To fix that, there are two questions that welcome input in
> https://phabricator.wikimedia.org/T78617 :
>
>
> 1) Our Phabricator currently offers six levels of prioritization. See
> https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels
> Do project maintainers / devs really feel a need for planning to
> differentiate between "low" priority and one level below that?
> Or could we reduce our six levels with five levels?
>
> 2) If there is a need for a level below "low": Let's rename "Needs
> Volunteer" back to "Lowest" (Looking at the proposed names in T78617,
> "Lowest" seems to be the least confusing term / smallest evil.)
>
>
> If you feel like helping make a decision by adding some *additional*
> arguments based on your experience, please raise your voice in T78617
> after reading the existing comments and arguments in that task.
>
> Thank you for your help!
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> 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] New recent changes library for .Net

[Petr Bena]

Hi

Some of you who use JS and Python were probably excited about
deployment of new RCStream (1) and some of you who use .Net were
probably disapointed how complex it is to get it, JSON and
websockets.IO running on .Net in order to get it working.

Here I made a super simple C# library that utilizes a XmlRcs (2) proxy
to RCStream using only native .Net libraries that are provided by
microsoft and mono. That means this library is working out of the box
anywhere. You can get it here:
https://github.com/huggle/XMLRCS/tree/master/clients/c%23/XmlRcs

This library makes it extremely simple for anyone to connect to
wikimedia recent changes stream for any WMF project and hook event to
any change made to wiki. This would be probably very useful for .Net
bots and tools.

Let me know if you needed any help or improvements, or just use that
github tracker! Have fun

1 http://wikitech.wikimedia.org/RCStream
2 http://wikitech.wikimedia.org/XmlRcs

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

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

[Petr Bena]

What would be the letter for it then? s? t? a?

On Thu, Feb 12, 2015 at 8:31 PM, Pine W  wrote:
> I think bot edits are most closely aligned with fully automated editing.
> Perhaps "semi-automated edit" would work.
>
> Pine
> On Feb 12, 2015 10:34 AM, "Marc A. Pelletier"  wrote:
>
>> On 15-02-12 01:13 AM, Pine W wrote:
>>
>>> What would it take to implement a new "tool edit flag" userright
>>>
>>
>> In the time-honored spirit of bikeshedding, I'd suggest that the right
>> name for this is "automated edit" rather than "tool edit".
>>
>> -- Marc
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

Regarding "everyone loves JSON these days":

I truly, deeply, hate it.

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

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

Re: [Wikitech-l] Cross-wiki template

[Petr Bena]

OK Thanks

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

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

Re: [Wikitech-l] Cross-wiki template

[Petr Bena]

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

If yes, please tell me how.

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

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

[Wikitech-l] Cross-wiki template

[Petr Bena]

Hi,

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

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

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

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

[Petr Bena]

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

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

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

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

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

Re: [Wikitech-l] Why there is no authentication mechanism for desktop applications

[Petr Bena]

I know this and that is why I started this thread :)

On Wed, Feb 11, 2015 at 5:17 PM, Guillaume Paumier
 wrote:
> Hello,
>
> Le mercredi 11 février 2015, 16:59:45 Petr Bena a écrit :
>>
>> We have OAuth for browser based programs. But nothing for desktop
>> applications that are being used by users. (Like AWB etc).
>
>> It sounds pretty simple to me, so why we don't have anything like that?
>
> The reason currently given at
> https://www.mediawiki.org/wiki/OAuth/For_Developers#Intended_Users
> is:
>
> "… not… Desktop applications (the Consumer Secret needs to be secret!)"
>
> --
> Guillaume Paumier
>
> ___
> 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] Why there is no authentication mechanism for desktop applications

[Petr Bena]

From developer point of view session looks much more easy to implement
than signed api calls. I wouldn't even need to change the code of
application for it to work.

On Wed, Feb 11, 2015 at 6:43 PM, Chris Steipp  wrote:
> On Wednesday, February 11, 2015, Guillaume Paumier 
> wrote:
>
>> Hello,
>>
>> Le mercredi 11 février 2015, 16:59:45 Petr Bena a écrit :
>> >
>> > We have OAuth for browser based programs. But nothing for desktop
>> > applications that are being used by users. (Like AWB etc).
>>
>> > It sounds pretty simple to me, so why we don't have anything like that?
>>
>> The reason currently given at
>> https://www.mediawiki.org/wiki/OAuth/For_Developers#Intended_Users
>> is:
>>
>> "... not... Desktop applications (the Consumer Secret needs to be secret!)"
>>
>
>
> That's why we don't use OAuth for these (see my last email on that too). We
> can shift our threat model to change this, but it comes at a cost
> (vandalism can't be blocked at the app-level, we have to require https for
> more pieces of the protocol, etc).
>
> Petr's current request sounds a little more like google's per-application
> passwords, except they are also limited in what rights they can use. Petr,
> I'm assuming you wouldn't want to do an OAuth-like signature on each
> request, but instead use it to login, then use the session cookie for
> future requests? Or were you thinking signed api calls like with OAuth?
>
>
>>
>> --
>> Guillaume Paumier
>>
>> ___
>> 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] Why there is no authentication mechanism for desktop applications

[Petr Bena]

Hi,

We have OAuth for browser based programs. But nothing for desktop
applications that are being used by users. (Like AWB etc).

These applications now have to ask for password, which is kind of safe
given that they are open source and running on computer of the user,
so at some point giving them password is as much insecure as giving it
to your we browser, but still, I believe that there could be slightly
better security model in use, that would make it safe to provide
password to a program that was compiled by anyone and that can be
potentially unsafe.

Let's take this sample model similar to OAuth:

* User would have extra panel in preferences, where they could
generate access tokens.
* For each token user could specify what application would have access to.

Generated tokens would be given to application instead of login and
password and the application could use them to login into mediawiki.

Users could revoke the tokens in anytime effectively invalidating any
tokens that potential hacker could steal using that 3rd application.

It sounds pretty simple to me, so why we don't have anything like that?

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

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

[Petr Bena]

I believe that majority of users will not like to have to ask for some
extra permissions in order to use some feature and so they will not
ask for them and not use it. So in case this "tool edit" flag was
restricted to some special permissions, users would keep using
automated tools and their edits wouldn't be flagged at all. This is a
reason why I think there shouldn't really be any restriction. I don't
think we have many vandals out there who are able to damage wikipedia
using API. There may be some, like 1 out of 10 000. But I doubt that
it really would be a real problem.

I am basically fine with anything that would be possible to be used by
tools (eg. it needs interface in API's) and that isn't restricted to
some group permissions. People who have permissions to use tools on
wikis, should be able to flag their edits as tool edits.

On Wed, Feb 11, 2015 at 4:35 PM, Brad Jorsch (Anomie)
 wrote:
> Please excuse the combined replies.
>
> On Wed, Feb 11, 2015 at 4:10 AM, Pine W  wrote:
>
>> Definitely worth discussing. For ENWP, I suggest bringing this up on VP:T.
>>
>
> Probably better to host the discussion on Meta, since it affects all wikis.
> Then you could advertise it on enwiki and other major wikis.
>
>
> On Wed, Feb 11, 2015 at 4:57 AM, Petr Bena  wrote:
>
>> As I said, I belive that any registered user should be able to use,
>> with no need for permissions as I see no way to abuse it.
>
>
> Well, there's marking edits as "tool" invalidly to the point where people
> can't filter these "tool" edits without missing vandalism.
>
>
>> Bot flag gives you higher api limits which can be abused,
>
>
> I note you're conflating the 'bot' right (which is what allows for marking
> an edit as 'bot', and generally forces it for web UI edits) with the 'bot'
> group that includes several other rights.
>
>
> On Wed, Feb 11, 2015 at 5:19 AM, Tim Landscheidt 
> wrote:
>
>> But I think it would be nice to add an option to the API to
>> attach tags to edits if they are contained in a whitelist
>> (so an editor cannot tag his edits as "hhvm" himself, but
>> only for example as "tool edit").
>>
>
> TTO is working on that, with me as the main reviewer.
> https://gerrit.wikimedia.org/r/#/c/188543/
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> 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] New feature: tool edit

[Petr Bena]

This is true but I don't understand why we can't have something like
OAuth for applications. I don't think it should be something complex.
User would just generate some "token" in mediawiki interface that
would be some long string which they would give to application, which
would then login to mediawiki using this string instead of username +
password combination.

This would be probably more secure than giving a password to it. This
is probably worth of separate wikitech thread.

Regarding the original topic: I think that this "tag" ability would be
useful but only as long as regular users can use these tags to filter
out selected edits from recent changes and similar. Otherwise it would
be only useful for tech people.

On Wed, Feb 11, 2015 at 2:59 PM, Ricordisamoa
 wrote:
> Il 11/02/2015 14:07, This, that and the other ha scritto:
>>
>> "Chris Grant"  wrote in message
>> news:caf_zkbp-abgzgcy4lqqvbtxur-2tjo8opmbwxtrosfvihuc...@mail.gmail.com...
>>
>>> On 11 Feb 2015 17:57, "Petr Bena"  wrote:
>>> >
>>> > As I said, I belive that any registered user should be able to use,
>>> > with no need for permissions as I see no way to abuse it.
>>>
>>> If anyone can use it, wouldn't the smarter vandals just use it to avoid
>>> the
>>> RC patrollers?
>>
>>
>> How does a user prove that they're using a particular tool a way that
>> can't be faked? Something like OAuth comes to mind. All edits made via an
>> OAuth consumer are already tagged with a unique tag, and I would assume that
>> it is not possible to falsely represent an OAuth consumer.
>>
>> I'm not sure whether this could work for common tools like AWB or Twinkle,
>> though:
>>
>> * I don't know whether OAuth works for client-side downloadable programs
>> like AWB.
>
> AFAIK the OAuth extension cannot work for them by design, see
> https://www.mediawiki.org/wiki/OAuth/For_Developers#Intended_Users.
>
>> * JavaScript tools edit as the user from the user's browser, and as such,
>> OAuth is not relevant to them. In any case, anything they do (like adding a
>> specific string to edit summaries, adding a tag to their edits, or the like)
>> can be easily spoofed or faked by a tech-savvy user.
>>
>> Before change tagging could be used as a way to *filter out* particular
>> tool edits (as opposed to being simply a way of identifying revisions that
>> satisfy some criterion) the RC tag filter would need to be improved.
>>
>> (I'm not pretending that change tagging is the only solution for Petr's
>> "tool edits" idea: I just think it is the most likely candidate for
>> implementing something like this.)
>>
>> TTO
>>
>>
>> ___
>> 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] New feature: tool edit

[Petr Bena]

First of all, this is why I am discussing it here, to avoid having
multiple people work on same thing.

Abuses:
I would consider this to be more like something like "minor edit" for
which you also don't need a permission. People who deal with vandals
probably shouldn't filter out users based on things like "minor edit"
or "tool edit", but rather on reputation, like huggle does. This is
basically just going to be useful for regular wikipedia users who just
want to filter out automated edits. For example in RFA you are
required to have some non-automated edit count. This would make it
easier to figure out things like this. You would be able to easily
filter out edits you are not interested in. I can't think of a better
use for this, but maybe there would be some.

Not sure if it worked for AWB, Twinkle or Huggle:
I don't know twinkle, but as far as I know both AWB and huggle are
using API's to interact with mediawiki. Huggle 3 is using ONLY api,
unless for regular, single page rendering. So if there was option in
API's for this (that is what I actually propose here) tools could just
add some parameter to API's url and that would flag the edit as tool
edit. It would be optional. If this is only going to work for OAuth
based tools, then it wouldn't work for non browser based tools.


On Wed, Feb 11, 2015 at 2:07 PM, This, that and the other
 wrote:
> "Chris Grant"  wrote in message
> news:caf_zkbp-abgzgcy4lqqvbtxur-2tjo8opmbwxtrosfvihuc...@mail.gmail.com...
>
>> On 11 Feb 2015 17:57, "Petr Bena"  wrote:
>> >
>> > As I said, I belive that any registered user should be able to use,
>> > with no need for permissions as I see no way to abuse it.
>>
>> If anyone can use it, wouldn't the smarter vandals just use it to avoid
>> the
>> RC patrollers?
>
>
> How does a user prove that they're using a particular tool a way that can't
> be faked? Something like OAuth comes to mind. All edits made via an OAuth
> consumer are already tagged with a unique tag, and I would assume that it is
> not possible to falsely represent an OAuth consumer.
>
> I'm not sure whether this could work for common tools like AWB or Twinkle,
> though:
>
> * I don't know whether OAuth works for client-side downloadable programs
> like AWB.
> * JavaScript tools edit as the user from the user's browser, and as such,
> OAuth is not relevant to them. In any case, anything they do (like adding a
> specific string to edit summaries, adding a tag to their edits, or the like)
> can be easily spoofed or faked by a tech-savvy user.
>
> Before change tagging could be used as a way to *filter out* particular tool
> edits (as opposed to being simply a way of identifying revisions that
> satisfy some criterion) the RC tag filter would need to be improved.
>
> (I'm not pretending that change tagging is the only solution for Petr's
> "tool edits" idea: I just think it is the most likely candidate for
> implementing something like this.)
>
> TTO
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

As I said, I belive that any registered user should be able to use,
with no need for permissions as I see no way to abuse it. Bot flag
gives you higher api limits which can be abused, but this would just
work to make it easier for users to hide out your edits. The
permission could be individually changed though per wiki if users
wanted to have it restricted.

The difference from bot flag is that bots are robots, not users, you
probably want to keep them separated. Giving bot flag to a regular
user is probably not a best idea.

On Wed, Feb 11, 2015 at 10:39 AM, Amir E. Aharoni
 wrote:
> It's relevant for all projects and languages.
>
> I haven't done it in a while, but I had my periods of massive AWB editing,
> and other RC patrollers rightly complained about it and asked me to do such
> things with a bot account.
>
> The question is, how would it be different from the usual
> bot accounts. Last time I checked, AWB worked through a browser control and
> not through API (though again, it was a while ago). And which users will
> have a permission to use it? Some "trusted" users? Autoconfirmed? AWB has
> its own permissions system based on wiki pages, so maybe this could be
> discarded of a new "tool edit" permission.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> 2015-02-11 11:10 GMT+02:00 Pine W :
>
>> Definitely worth discussing. For ENWP, I suggest bringing this up on VP:T.
>>
>> Thanks,
>> Pine
>> On Feb 11, 2015 12:45 AM, "Petr Bena"  wrote:
>>
>> > Hi,
>> >
>> > I think I proposed this once but I forgot the outcome.
>> >
>> > I would like to implement a new feature called "tool edit" it would be
>> > pretty much the same as "bot edit" but with following differences:
>> >
>> > -- Every registered user would be able to flag edit as tool edit (bot
>> > needs special user group)
>> > -- The flag wouldn't be intended for use by robots, but regular users
>> > who used some automated tool in order to make the edit
>> > -- Users could optionally mark any edit as tool edit through API only
>> >
>> > The rationale is pretty clear: there is a number of tools, like AWB
>> > and many others that produce incredible amounts of edits every day.
>> > They are spamming recent changes page -
>> > https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered
>> > out and most of regular users are not interested in them. This would
>> > make it possible to filter them out and it would also make it easier
>> > to figure out how many "real edits" some user has made, compared to
>> > automated edits made by tools.
>> >
>> > Is it worth implementing? I think yes, but not so sure.
>> >
>> > Thanks
>> >
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Petr Bena]

Yes, the question is however, if this passed "consensus" on english
wikipedia and I made a patch for mediawiki, assuming code would be
correct would it be merged to core of mediawiki or is there any other
requirement? Does it actually even need to pass consensus on
wikipedia? I think this would be useful for other wikis as well. We
already have bot flag and most of smaller wikis have no bots.

On Wed, Feb 11, 2015 at 10:10 AM, Pine W  wrote:
> Definitely worth discussing. For ENWP, I suggest bringing this up on VP:T.
>
> Thanks,
> Pine
> On Feb 11, 2015 12:45 AM, "Petr Bena"  wrote:
>
>> Hi,
>>
>> I think I proposed this once but I forgot the outcome.
>>
>> I would like to implement a new feature called "tool edit" it would be
>> pretty much the same as "bot edit" but with following differences:
>>
>> -- Every registered user would be able to flag edit as tool edit (bot
>> needs special user group)
>> -- The flag wouldn't be intended for use by robots, but regular users
>> who used some automated tool in order to make the edit
>> -- Users could optionally mark any edit as tool edit through API only
>>
>> The rationale is pretty clear: there is a number of tools, like AWB
>> and many others that produce incredible amounts of edits every day.
>> They are spamming recent changes page -
>> https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered
>> out and most of regular users are not interested in them. This would
>> make it possible to filter them out and it would also make it easier
>> to figure out how many "real edits" some user has made, compared to
>> automated edits made by tools.
>>
>> Is it worth implementing? I think yes, but not so sure.
>>
>> Thanks
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Wikitech-l] New feature: tool edit

[Petr Bena]

Hi,

I think I proposed this once but I forgot the outcome.

I would like to implement a new feature called "tool edit" it would be
pretty much the same as "bot edit" but with following differences:

-- Every registered user would be able to flag edit as tool edit (bot
needs special user group)
-- The flag wouldn't be intended for use by robots, but regular users
who used some automated tool in order to make the edit
-- Users could optionally mark any edit as tool edit through API only

The rationale is pretty clear: there is a number of tools, like AWB
and many others that produce incredible amounts of edits every day.
They are spamming recent changes page -
https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered
out and most of regular users are not interested in them. This would
make it possible to filter them out and it would also make it easier
to figure out how many "real edits" some user has made, compared to
automated edits made by tools.

Is it worth implementing? I think yes, but not so sure.

Thanks

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

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

[Petr Bena]

Regarding AGPL: please no

That would not just kill nearly all commercial usage of mediawiki, but
it would also introduce insane requirements to most of small wiki
maintainers who would have to start distributing the source code of
their customized wikis to public somehow + in case they wouldn't be
good php programmers and made some security bugs in software
themselves, they would make it much easier for hackers to find them.

On Sun, Feb 8, 2015 at 5:55 PM, Petr Bena  wrote:
> I don't really understand if apple provides their OS for free, why
> they can't create a lightweight version that would run in virtual box,
> for open source developers only... But that's their choice. Let's go
> back to original topic. GPL v 3 is a good idea :) I am just not sure
> if you don't need permissions from other developers who contributed
> the code in order to change the license.
>
> On Sun, Feb 8, 2015 at 5:53 PM, Petr Bena  wrote:
>> TBH as open source developer I don't feel like publishing kernel
>> sources makes it any easier for me to create applications for their
>> platform.
>>
>> If I want to create an application for android, I can download android
>> studio and run it on Windows, Linux or Mac. The studio itself is open
>> source and programs are easy to package.
>>
>> If I want to create an application for iPhone, I have to own a Mac,
>> because even if I wanted to buy OS only and install it on non-apple
>> hardware, it wouldn't work and xcode is not available for any other
>> platform than Mac. This is blocker for any open source developer who
>> wants to create non-profit software and isn't willing to put money
>> into something that is never gonna be useful for them, so that they
>> can create software that others can freely use.
>>
>> This is case of all apple products, even if I wanted to create a
>> program for Windows, which is commercial platform, I can easily do
>> that on linux and compile with mingw compiler that can build .exe
>> files on linux. But in case of apple you can only dream of that.
>>
>> On Sun, Feb 8, 2015 at 4:31 PM, Antoine Musso  wrote:
>>> Le 08/02/2015 15:26, Petr Bena a écrit :
>>>> What can I say, I always had a feeling that apple hates open source
>>>> and likes to block open source devs in all possible ways, this just
>>>> ensures me in this feeling. One more reason for me to be happy not to
>>>> have to work with their products.
>>>
>>> You have wrong feelings really: http://opensource.apple.com/
>>>
>>> Even the kernel (XNU) is published under an open source license:
>>>
>>>  http://www.opensource.apple.com/source/xnu/
>>>
>>>  FSF's Opinion of the Apple Public Source License (APSL) 2.0
>>>  https://www.gnu.org/philosophy/apsl.en.html
>>>
>>>
>>> The AppStore terms of service is not compatibe with GPLv2 since they
>>> restrict distribution and use in addition of the GPLv2 restrictions.  So
>>> it is not surprising that Apple acts as a good citizen by respecting the
>>> license and thus preventing people from adding GPLv2 apps. They just
>>> make sure the license is respected.
>>>
>>>
>>> --
>>> 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