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

2020-04-27 Thread 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?

2020-04-06 Thread 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=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?

2020-04-05 Thread 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?

2020-04-05 Thread 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

2019-04-16 Thread 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

2019-04-16 Thread 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

2018-08-15 Thread 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

2018-08-15 Thread 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

2018-08-15 Thread 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

2018-08-15 Thread 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

2018-08-14 Thread 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 fun.
>> >
>> > Regards,
>> > Adam
>> >
>> > [1] https://en.wikipedia.org/wiki/Negative_

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

2018-08-13 Thread 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

2018-08-12 Thread 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

2018-08-12 Thread 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

2018-06-14 Thread 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

2018-06-11 Thread 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

2018-06-11 Thread 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

2018-06-11 Thread 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?

2017-09-08 Thread 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

2017-05-10 Thread 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 <jjons...@wikimedia.org> 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. <li...@revi.pe.kr> 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 <martin.urba...@wikimedia.cz> 작성:
>>
>> > 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 <benap...@gmail.com> 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

2017-05-10 Thread 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

2017-02-25 Thread 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] 

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

2017-02-19 Thread 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?

2016-11-03 Thread 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=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

2016-10-21 Thread 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. <wikipedia.dann...@email.cz> wrote:
>
>
> -- Původní zpráva ------
> Od: Petr Bena <benap...@gmail.com>
> Komu: Wikimedia developers <wikitech-l@lists.wikimedia.org>
> 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

2016-10-20 Thread 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

2016-04-01 Thread 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?

2015-12-06 Thread 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

2015-11-30 Thread 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 <benap...@gmail.com> 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

[Wikitech-l] Compression with API

2015-11-30 Thread 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

2015-11-30 Thread 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)
<bjor...@wikimedia.org> wrote:
> On Mon, Nov 30, 2015 at 11:10 AM, Petr Bena <benap...@gmail.com> 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

Re: [Wikitech-l] Git for idiots

2015-11-11 Thread 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)
<nwil...@wikimedia.org> wrote:
> On Tue, Nov 10, 2015 at 10:54 AM, Legoktm <legoktm.wikipe...@gmail.com> 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

[Wikitech-l] Git for idiots

2015-11-10 Thread 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] Git for idiots

2015-11-10 Thread 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 <benap...@gmail.com> 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

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

2015-11-09 Thread 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

2015-10-08 Thread 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 <jay...@gmail.com> wrote:
> On Thu, Oct 8, 2015 at 1:54 AM, Petr Bena <benap...@gmail.com> 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

2015-10-07 Thread 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

Re: [Wikitech-l] AWS usage

2015-10-07 Thread 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

[Wikitech-l] Wikitext linting service

2015-10-05 Thread 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

2015-09-16 Thread Petr Bena
yay, that fixed the problem, thanks :o

On Tue, Sep 15, 2015 at 6:24 PM, Brad Jorsch (Anomie)
<bjor...@wikimedia.org> wrote:
> On Tue, Sep 15, 2015 at 11:53 AM, Petr Bena <benap...@gmail.com> 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=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167574=prev=Battle%20Tendency=1=xml
>
>
> This diff is from 679358832 to 681167574.
>
>
>> *
>> https://en.wikipedia.org/w/api.php?action=query=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167835=prev=Battle%20Tendency=1=xml
>
>
> This is from 681167574 to 681167835.
>
>
>> *
>> https://en.wikipedia.org/w/api.php?action=query=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167909=prev=Battle%20Tendency=1=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=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167574=681167909=Battle%20Tendency=1=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

2015-09-15 Thread Petr Bena
That "compare" feature look promising. Thanks

On Tue, Sep 15, 2015 at 5:36 PM, Brad Jorsch (Anomie)
<bjor...@wikimedia.org> wrote:
> On Tue, Sep 15, 2015 at 10:39 AM, Petr Bena <benap...@gmail.com> 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

2015-09-15 Thread 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=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167574=prev=Battle%20Tendency=1=xml
* 
https://en.wikipedia.org/w/api.php?action=query=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167835=prev=Battle%20Tendency=1=xml
* 
https://en.wikipedia.org/w/api.php?action=query=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167909=prev=Battle%20Tendency=1=xml

The combined diff of all three edits I am trying to get has link
https://en.wikipedia.org/w/api.php?action=query=revisions=ids%7Ctags%7Cuser%7Ctimestamp%7Ccomment=1=681167574=681167909=Battle%20Tendency=1=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 <benap...@gmail.com> wrote:
> That "compare" feature look promising. Thanks
>
> On Tue, Sep 15, 2015 at 5:36 PM, Brad Jorsch (Anomie)
> <bjor...@wikimedia.org> wrote:
>> On Tue, Sep 15, 2015 at 10:39 AM, Petr Bena <benap...@gmail.com> 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] The "other" developers at the Wikimedia Developer Summit

2015-09-15 Thread 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

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

2015-09-15 Thread 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] Phabricator filter by language

2015-07-29 Thread 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
sniedziel...@wikimedia.org 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 q...@wikimedia.org wrote:

 On Fri, Jul 17, 2015 at 10:04 AM, Petr Bena benap...@gmail.com 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

2015-07-23 Thread Petr Bena
Force pushes can be disabled if you contact github support

On Wed, Jul 22, 2015 at 11:14 PM, Gergo Tisza gti...@wikimedia.org wrote:
 On Wed, Jul 22, 2015 at 4:39 AM, Petr Bena benap...@gmail.com 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

2015-07-22 Thread 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 bgers...@wikimedia.org 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

2015-07-18 Thread 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 gti...@wikimedia.org wrote:
 On Fri, Jul 17, 2015 at 3:04 AM, Petr Bena benap...@gmail.com 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

[Wikitech-l] Phabricator filter by language

2015-07-17 Thread 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] Phabricator filter by language

2015-07-17 Thread 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
ricordisa...@openmailbox.org 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

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

2015-06-26 Thread 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
sniedziel...@wikimedia.org 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 kpeterz...@wikimedia.org
 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

2015-06-18 Thread 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)
bjor...@wikimedia.org wrote:
 On Wed, Jun 17, 2015 at 10:13 PM, Yuri Astrakhan yastrak...@wikimedia.org
 wrote:

 On Wed, Jun 17, 2015 at 7:44 PM, John Mark Vandenberg jay...@gmail.com
 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=queryprop=revisionsrvprop=contentrvlimit=1titles=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

[Wikitech-l] [IRC] BotBot logs

2015-06-13 Thread 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] [IRC] BotBot logs

2015-06-13 Thread 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 benap...@gmail.com 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

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

2015-06-09 Thread Petr Bena
\O/ MORE HACKATHONS per year! yay

On Tue, Jun 9, 2015 at 4:53 PM, Dan Bolser dan.bol...@gmail.com 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

2015-06-04 Thread 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 maar...@mdammers.nl wrote:
 Hi,

 Brad Jorsch (Anomie) schreef op 3-6-2015 om 18:43:

 not an announcement

 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

2015-06-04 Thread Petr Bena
* 3.1.5 not 3.15, sorry for confusion :P

On Thu, Jun 4, 2015 at 3:19 PM, Petr Bena benap...@gmail.com 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 maar...@mdammers.nl wrote:
 Hi,

 Brad Jorsch (Anomie) schreef op 3-6-2015 om 18:43:

 not an announcement

 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

2015-05-27 Thread 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

2015-03-31 Thread 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

2015-03-18 Thread Petr Bena
One foundation to rule them all? :P

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

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

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

2015-03-17 Thread 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)
bjor...@wikimedia.org 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

2015-03-06 Thread 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 benap...@gmail.com 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)
 bjor...@wikimedia.org wrote:
 Note this reply is written with my enwiki community member hat on, and in
 no way represents anything official

 On Fri, Mar 6, 2015 at 5:19 AM, Ricordisamoa ricordisa...@openmailbox.org
 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

2015-03-06 Thread 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)
bjor...@wikimedia.org wrote:
 Note this reply is written with my enwiki community member hat on, and in
 no way represents anything official

 On Fri, Mar 6, 2015 at 5:19 AM, Ricordisamoa ricordisa...@openmailbox.org
 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

2015-03-06 Thread 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
mflasc...@wikimedia.org 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=1id=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

2015-03-04 Thread 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 thoma...@hotmail.fr 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 lydia.pintsc...@wikimedia.de a 
 écrit :

 On Wed, Mar 4, 2015 at 2:36 PM, Petr Bena benap...@gmail.com 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

2015-03-04 Thread 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

2015-02-23 Thread 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 wikipo...@gmail.com wrote:
 2015-02-11 14:02 GMT+01:00 Ricordisamoa ricordisa...@openmailbox.org:

 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 https://tools.wmflabs.org/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

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

2015-02-22 Thread 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 aklap...@wikimedia.org 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

[Wikitech-l] Transfering domain cswp.cz to WMF

2015-02-22 Thread 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:

?php
$uri   = $_SERVER['PHP_SELF'];
$target = 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] Global user pages deployed to all wikis

2015-02-19 Thread 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
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 legoktm.wikipe...@gmail.com
 An: wikitech-l@lists.wikimedia.org,  Coordination of technology deployments 
 across languages/projects wikitech-ambassad...@lists.wikimedia.org

 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] If you hear about 'hackathon buddies'...

2015-02-19 Thread 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 q...@wikimedia.org 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] Html.php line 269

2015-02-18 Thread 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 /html 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 bvib...@wikimedia.org wrote:
 On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com 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 html so this would only take
 effect on head 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

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

2015-02-18 Thread 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
ricordisa...@openmailbox.org 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 /html 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 bvib...@wikimedia.org
 wrote:

 On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com 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 html so this would only
 take
 effect on head 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

2015-02-18 Thread 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 benap...@gmail.com 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
 ricordisa...@openmailbox.org 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 /html 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 bvib...@wikimedia.org
 wrote:

 On Wed, Feb 18, 2015 at 1:23 PM, Petr Bena benap...@gmail.com 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 html so this would only
 take
 effect on head 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

2015-02-18 Thread Petr Bena
Most of browsers would probably handle it OK, but validators not.

On Wed, Feb 18, 2015 at 10:45 PM, Petr Bena benap...@gmail.com 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 gti...@wikimedia.org wrote:
 On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com 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

2015-02-18 Thread 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 gti...@wikimedia.org wrote:
 On Wed, Feb 18, 2015 at 1:38 PM, Petr Bena benap...@gmail.com 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] IRC: wm-bot now speak with GitHub fluently

2015-02-17 Thread 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+ full name of repository 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 benap...@gmail.com 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 benap...@gmail.com 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+ full name of repository 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) wm-bot GitHub [benapetr/test-wm]  benapetr pushed 1
 commits: 
 https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
 (10:41:00) wm-bot 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

2015-02-17 Thread 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 benap...@gmail.com 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+ full name of repository 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) wm-bot GitHub [benapetr/test-wm]  benapetr pushed 1
 commits: 
 https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
 (10:41:00) wm-bot 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

2015-02-17 Thread 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 benap...@gmail.com 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+ full name of repository 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 benap...@gmail.com 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 benap...@gmail.com 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+ full name of repository 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) wm-bot GitHub [benapetr/test-wm]  benapetr pushed 1
 commits: 
 https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
 (10:41:00) wm-bot 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

2015-02-17 Thread 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+ full name of repository 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) wm-bot GitHub [benapetr/test-wm]  benapetr pushed 1
commits: https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
(10:41:00) wm-bot 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

2015-02-15 Thread 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 bawo...@gmail.com 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] New feature: tool edit

2015-02-13 Thread Petr Bena
What would be the letter for it then? s? t? a?

On Thu, Feb 12, 2015 at 8:31 PM, Pine W wiki.p...@gmail.com 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 m...@uberbox.org 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

[Wikitech-l] New recent changes library for .Net

2015-02-13 Thread 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] Needs Volunteer priority field value in Phabricator

2015-02-13 Thread Petr Bena
I like that volunteer flag, please keep it.

On Fri, Feb 13, 2015 at 6:42 PM, Andre Klapper aklap...@wikimedia.org 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

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

2015-02-12 Thread 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
gerard.meijs...@gmail.com 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 benap...@gmail.com 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 wiki.p...@gmail.com 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 benap...@gmail.com 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] Cross-wiki template

2015-02-12 Thread 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
ricordisa...@openmailbox.org 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

Re: [Wikitech-l] Cross-wiki template

2015-02-12 Thread Petr Bena
OK Thanks

On Thu, Feb 12, 2015 at 1:43 PM, Quim Gil q...@wikimedia.org wrote:
 On Thu, Feb 12, 2015 at 1:32 PM, Petr Bena benap...@gmail.com 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

[Wikitech-l] Cross-wiki template

2015-02-12 Thread 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] Who moved my cheese?

2015-02-12 Thread Petr Bena
Regarding everyone loves JSON these days:

I truly, deeply, hate it.

On Thu, Feb 12, 2015 at 2:40 PM, Andrew Garrett agarr...@wikimedia.org 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] Why there is no authentication mechanism for desktop applications

2015-02-11 Thread 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 cste...@wikimedia.org wrote:
 On Wednesday, February 11, 2015, Guillaume Paumier gpaum...@wikimedia.org
 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 javascript:;
 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

2015-02-11 Thread Petr Bena
I know this and that is why I started this thread :)

On Wed, Feb 11, 2015 at 5:17 PM, Guillaume Paumier
gpaum...@wikimedia.org 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

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

2015-02-11 Thread 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

2015-02-11 Thread 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
at.li...@live.com.au wrote:
 Chris Grant  wrote in message
 news:caf_zkbp-abgzgcy4lqqvbtxur-2tjo8opmbwxtrosfvihuc...@mail.gmail.com...

 On 11 Feb 2015 17:57, Petr Bena benap...@gmail.com 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

2015-02-11 Thread 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
ricordisa...@openmailbox.org 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 benap...@gmail.com 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

2015-02-11 Thread 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)
bjor...@wikimedia.org wrote:
 Please excuse the combined replies.

 On Wed, Feb 11, 2015 at 4:10 AM, Pine W wiki.p...@gmail.com 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 benap...@gmail.com 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 t...@tim-landscheidt.de
 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

2015-02-11 Thread 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 wiki.p...@gmail.com 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 benap...@gmail.com 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

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

2015-02-11 Thread 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
amir.ahar...@mail.huji.ac.il 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.

 thinkingoutloudThe 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./thinkingoutloud


 --
 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 wiki.p...@gmail.com:

 Definitely worth discussing. For ENWP, I suggest bringing this up on VP:T.

 Thanks,
 Pine
 On Feb 11, 2015 12:45 AM, Petr Bena benap...@gmail.com 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] New feature: tool edit

2015-02-11 Thread 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

2015-02-08 Thread Petr Bena
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 hashar+...@free.fr 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

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

2015-02-08 Thread Petr Bena
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 benap...@gmail.com 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 hashar+...@free.fr 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

  1   2   3   4   5   6   7   >