It's designed so if there if there is a issue with the bot (eg: it's
malfunctioning etc) and causes issues the person whom is in control can
easily be identified.
As such, The user-agent you chose should reflect that.
On 11 July 2014 09:09, Amir Ladsgroup ladsgr...@gmail.com wrote:
Hello,
As
Le 11/07/2014 01:09, Amir Ladsgroup a écrit :
Hello,
As discussions in pywikipedia-l people are not sure whether is necessary to
add username of bot operator in user agent or not.
In user agent policy https://meta.wikimedia.org/wiki/User-agent_policy
it's mentioned that people need to add
Hi we are upgrading jquery cookie from an early alpha version of 1.1 to 1.2.
Please start upgrading your code to be compatible with jquery cookie 1.2. There
is just one deprecations to notice and that is $.cookie(#39;foo#39;, null) is
now deprecated. And replace it with Adding
This interesting bot showed up on hackernews today:
https://news.ycombinator.com/item?id=8018284
While in this instance the access to anonymous' editors IP addresses is
definitely useful in terms of identifying edits with probable conflict of
interest, it makes me wonder what the history is
On Fri, Jul 11, 2014 at 6:50 PM, Antoine Musso hashar+...@free.fr wrote:
Le 11/07/2014 01:09, Amir Ladsgroup a écrit :
Hello,
As discussions in pywikipedia-l people are not sure whether is necessary to
add username of bot operator in user agent or not.
In user agent policy
On 07/11/2014 09:34 AM, John Mark Vandenberg wrote:
Could ops confirm they have the username of each logged in edit at
their finger tips (i.e. roughly as easy to access as the user-agent)?
Pywikibot doesnt permit logged out edits.
We do, after the fact, from the same data Checkusers have
On Jul 11, 2014 9:45 AM, Marc A. Pelletier m...@uberbox.org wrote:
On 07/11/2014 09:34 AM, John Mark Vandenberg wrote:
Could ops confirm they have the username of each logged in edit at
their finger tips (i.e. roughly as easy to access as the user-agent)?
Pywikibot doesnt permit logged out
I agree that it’s a double standard, but looking at the bright side, it becomes
a big encouragement to anonymous users to register and log in. The Account
Creation Experience Team (or whoever the hell is in charge of that) can correct
me, but I would imagine that we would see a big drop in
On 07/11/2014 10:07 AM, Jeremy Baron wrote:
I can recall more than a few past conversations about this with mzmcbride,
Tim Starling and others.
Keep in mind I've only been around for ~18 months, so I am going to be
unaware of some previous discussion on the subject.
But yeah, /clearly/ the
I would imagine that we would see a big drop in registered accounts if IPs
were hashed.
Why? Most casual web users don't even know what an IP address is, let alone
what their own address is. In fact the evolution of browsers tends to even
hide the URL. This is the sort of technical
This is one of those perennial proposals that never quite seems to take
off; I can remember having some version of this discussion back in 2008,
and I know that some of our earliest edits show a partially obscured IP
address, not the whole thing. It might require Brion or Tim or someone else
of
Even in this day and age, there are plenty of people with stable IPs
With hashing, a given IP would always give the same hash. So this
uniqueness property would remain for people with stable IPs.
On Fri, Jul 11, 2014 at 10:55 AM, Risker risker...@gmail.com wrote:
This is one of those
As a quick implementation note, we would not be using a hash for the IP address.
Most likely, we would encrypt the IP with AES or something using a
configuration-based secret key. That way checkusers can still reverse the hash
back into normal IP addresses without having to store the mapping in
To my knowledge, there are currently six of these Twitter bots
(Canada, Denmark, France, Sweden, UK, US). I have collected them in a
Twitter list: https://twitter.com/palnatoke/lists/wikiedit
Please speak up if you notice more, so I can include them in the list, too.
Regards,
Ole
On Fri, Jul
Am 11.07.2014 17:19, schrieb Tyler Romeo:
Most likely, we would encrypt the IP with AES or something using a
configuration-based secret key. That way checkusers can still reverse the
hash back into normal IP addresses without having to store the mapping in the
database.
There are two problems
On Friday, July 11, 2014, Daniel Kinzler dan...@brightbyte.de wrote:
Am 11.07.2014 17:19, schrieb Tyler Romeo:
Most likely, we would encrypt the IP with AES or something using a
configuration-based secret key. That way checkusers can still reverse the
hash back into normal IP addresses
On Friday, July 11, 2014, Risker risker...@gmail.com wrote:
This is one of those perennial proposals that never quite seems to take
off; I can remember having some version of this discussion back in 2008,
and I know that some of our earliest edits show a partially obscured IP
address, not the
On Fri, Jul 11, 2014 at 8:45 AM, Luca Martinelli
martinellil...@gmail.com wrote:
so the Book Creator will still be active, maybe under another name,
maybe with another engine, but still active?
Same name and functionality, just the Order a printed book feature
will disappear.
Erik
--
Erik
I kinda like the idea of an
anonymous-but-consistent proto-account that can be transformed into a
named login if desired, but it needs to be thought out in more detail to
resolve potential difficulties.
One could automatically create a pseudo-account (Anonymous #12345) upon
first edit. And
On 11 July 2014 17:10, Gilles Dubuc gil...@wikimedia.org wrote:
Maybe it's a cookie-based approach you had in mind? Where we automatically
create an account tied to the user agent. That would mitigate the issue of
converting a pseudo-account that might have been shared between several
people
This was merged on May 9th, so I have moved the RfC
https://www.mediawiki.org/wiki/Requests_for_comment/Publishing_the_RecentChanges_feed
to the archive - is that right?
Can I understand better where we're using PubSubHubbub vs WebSockets vs
rcstream?
Sumana Harihareswara
Senior Technical Writer
On 07/11/2014 06:12 AM, Thomas Mulhall wrote:
Hi we are upgrading jquery cookie from an early alpha version of 1.1
to 1.2. Please start upgrading your code to be compatible with jquery
cookie 1.2. There is just one deprecations to notice and that is
$.cookie(#39;foo#39;, null) is now deprecated.
On 07/11/2014 11:45 AM, Brion Vibber wrote:
As I recall, UseModWiki (the perl-based wiki software we used before
switching to a custom solution which evolved into MediaWiki) obscured the
last octet of the IP address, which still left you with enough information
in most cases to track down an ISP
it may surprise you but there are other languages than python and in
these, things like this aren't that simple...
On Sun, May 11, 2014 at 1:14 AM, Alex Monk kren...@gmail.com wrote:
I've fiddled around with this a bit:
On my Ubuntu system, I simply got a library: sudo pip install
On 04/18/2014 04:21 AM, Ori Livneh wrote:
Is there a way to accept pull-requests from GitHub?
I don't think we can merge directly there. The canonical repo is
git.wikimedia.org, and I think merging in GitHub would create an
inconsistent state.
According to
On Fri, Jul 11, 2014 at 11:34 AM, Matthew Flaschen mflasc...@wikimedia.org
wrote:
On 04/18/2014 04:21 AM, Ori Livneh wrote:
Is there a way to accept pull-requests from GitHub?
I don't think we can merge directly there. The canonical repo is
git.wikimedia.org, and I think merging in GitHub
Le 11/07/2014 20:34, Matthew Flaschen a écrit :
According to
https://github.com/wikimedia/mediawiki-core/settings/hooks (may not be
visible to non-Wikimedians, sorry), the WebHook receiver
http://tools.wmflabs.org/suchaserver/cgi-bin/receiver.py is defunct.
Anyone know the story there?
On 11 July 2014 19:49, Antoine Musso hashar+...@free.fr wrote:
If not supported, have a bot detecting such pull requests and autoclose
them with instructions about how to create an account on labs and push a
change.
If I remember correctly, Yuvi had a bot that did something like this. It
Le 05/05/2014 11:29, Petr Bena a écrit :
Given the current specifications I can only support this change as
long as current IRC feed is preserved as IRC is IMHO, as much as evil
it looks, more suitable for this than WebSockets.
I am not saying that IRC is suitable for this and I know that
On Fri, Jul 11, 2014 at 11:49 AM, Antoine Musso hashar+...@free.fr wrote:
What would be nice: disable pull requests on Github.
If not supported, have a bot detecting such pull requests and autoclose
them with instructions about how to create an account on labs and push a
change.
Not
On 11 July 2014 21:49, Antoine Musso hashar+...@free.fr wrote:
There is a manual tool at:
https://tools.wmflabs.org/gerrit-patch-uploader/
https://gerrit.wikimedia.org/r/#/q/owner:gerritpatchuploader,n,z
I have plans to extend the uploader to allow simpele github uploads (just
like the
On Fri, Jul 11, 2014 at 2:49 PM, Antoine Musso hashar+...@free.fr wrote:
Le 11/07/2014 20:34, Matthew Flaschen a écrit :
According to
https://github.com/wikimedia/mediawiki-core/settings/hooks (may not be
visible to non-Wikimedians, sorry), the WebHook receiver
On Fri, 11 Jul 2014 21:35:56 +0200, Merlijn van Deen
valhall...@arctus.nl wrote:
I have plans to extend the uploader to allow simpele github uploads (just
like the bugzilla option), but I have not had time to work on this yet.
If
anyone feels like working on it: see
I was wrong - the code is merged but we need to have more architectural
discussion before we deploy, so I moved it out of the RfC archive.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
On Fri, Jul 11, 2014 at 1:18 PM, Sumana Harihareswara suma...@wikimedia.org
wrote:
This
right now it seems to me worse in many points:
* it requires more traffic (slower and ineffective)
* it requires some extra libraries that enlarge dependency tree
* protocol itself is extra complicated and unflexible compared to IRC,
which can be programmed in few minutes
what's the point in
BTW do you have any use data or feedback from people who switched from
IRC to this one? Based on what you decided you are going to phase it
out? I bet my shoes when you turn of IRC feed, half of wikipedia will
break and other half will start blaming all devs here on wikitech-l
for breaking
On 07/11/2014 02:54 PM, Alex Monk wrote:
On 11 July 2014 19:49, Antoine Musso hashar+...@free.fr wrote:
If not supported, have a bot detecting such pull requests and autoclose
them with instructions about how to create an account on labs and push a
change.
If I remember correctly, Yuvi had
Also https://bugzilla.wikimedia.org/show_bug.cgi?id=67888 needs to be
fixed so that people have some chance to test if their tools works
with websocket at least few months before switch to it
On Fri, Jul 11, 2014 at 11:14 PM, Petr Bena benap...@gmail.com wrote:
BTW do you have any use data or
The 'jquery.json' module has been deprecated, and we plan to remove it
in MW 1.25. You can replace it with the 'json' module.
* In your extension or gadget's ResourceLoader dependencies, change
'jquery.json' to 'json'
* Use JSON.stringify instead of $.toJSON
* Use JSON.parse instead of
Hello!
Please join Nuria Ruiz and Andrew Otto next Tuesday, July 15th at 10am SF
time/5pm UTC
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Analytics+Tech+Talkiso=20140715T10p1=224am=30
for a 30 min tech talk. You can join our hangout or follow along on
youtube:
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-16
Wednesday 16 July at 18:00 UTC, we're going to chat with Yair rand and
Slevinski about their vertical writing support proposal. This will be in
#wikimedia-office on Freenode IRC. Please check it out and comment ahead of
Hi sorry for sending the email so many times it because someone says that it is
going to spam so I tried removing http:// which the email service thinks is
spam.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
So, early next week has already passed, and a week after that too. :(
Any update on when you'll be making an announcement?
-- Legoktm
On 6/27/14, 4:49 PM, Greg Grossmeier wrote:
Hello all,
We're in negotiations with one of applicants for the MediaWiki release
management RFP and will make
quote name=Legoktm date=2014-07-11 time=17:32:35 -0700
So, early next week has already passed, and a week after that too. :(
Any update on when you'll be making an announcement?
My sincere apologies Lego, negotiations are taking longer than
anticipated. No one likes those things :)
--
| Greg
44 matches
Mail list logo
