Hello,
The Wikimedia Language Engineering team will be hosting a bug triage
session on Wednesday, August 28th 2013 at 17:00 UTC (10:00 PDT) for
some of the bugs that exist in languages written from Right-to-Left
(RTL). During this 1 hour session we will be using the etherpad
linked below to
This make a second draw approach would also let you tune how often you
saw the bad articles. That is, if it's a bad article, then flip a coin
to see if you should make a second draw. Repeat if the new article is bad,
but never make more than N draws. Someone with time on their hands and a
The probability of displaying a bad page would be:
B q ((p B)^N - 1) / (p B - 1) + B (p B)^N
(modulo errors), where B is the fraction of bad pages, p is the
probability of repeating, q is the probability of displaying (so p+q =
1), and N is the allowed number of repetitions.
--
LF
On 23 August
1st wrote large response, while i was still in midst of reading
various responses, when i've seen last few responses which have
touched many important factors related to very large scale sites,
and that wikipedia want to keep geo-location geo-feature based
separation(s), then removed various
On Wed, Aug 21, 2013 at 5:04 PM, Chris Steipp cste...@wikimedia.org wrote:
On Wed, Aug 21, 2013 at 2:05 AM, Nicolas Vervelle nverve...@gmail.com
wrote:
Hi,
I'm completely new to OAuth, so bear with me if my questions are basic
or I
missed a point ;-)
It seems interesting, but seems
On Fri, Aug 23, 2013 at 9:24 AM, Lord_Farin lord_fa...@proofwiki.orgwrote:
The probability of displaying a bad page would be:
B q ((p B)^N - 1) / (p B - 1) + B (p B)^N
(modulo errors), where B is the fraction of bad pages, p is the
probability of repeating, q is the probability of
Hi,
It would be great if a few pairs of eyes could take a look at
https://meta.wikimedia.org/wiki/Tech/News/2013/34 before I send it to
translators, to check that I haven't missed anything super-important
or misunderstood what the commits are about.
The tech newsletter is aimed at non-expert
On Fri, Aug 23, 2013 at 10:38 AM, Nicolas Vervelle nverve...@gmail.comwrote:
On Wed, Aug 21, 2013 at 5:04 PM, Chris Steipp cste...@wikimedia.org
wrote:
For bots too, I'd like to have the extension implement something like
I am just wondering if we really need so complicated names like
[[Special:MWOAuthManageMyGrants]]
Couldn't it be just [[Special:MWOAuthManage]]
or [[Special:MWOAuthGrants]]
On Fri, Aug 23, 2013 at 5:52 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 10:38 AM,
My first thought when reading You can now use new styles of galleries and
give feedback to User:Bawolff. was We couldn't give feedback to Bawolff
before?
Also, is it worth mentioning the pending resolution of bug 39653, currently
scheduled for next week and in test on test wikis and mediawiki.org
quote name=Brad Jorsch (Anomie) date=2013-08-23 time=12:01:30 -0400
My first thought when reading You can now use new styles of galleries and
give feedback to User:Bawolff. was We couldn't give feedback to Bawolff
before?
Also, is it worth mentioning the pending resolution of bug 39653,
On Fri, Aug 23, 2013 at 7:38 AM, Nicolas Vervelle nverve...@gmail.comwrote:
The best workaround now is probably to have each user register their copy
of your desktop application as its own consumer. It's a little ugly
having
to give your user instructions on cutting and pasting tokens and
On Fri, Aug 23, 2013 at 8:59 AM, Petr Bena benap...@gmail.com wrote:
I am just wondering if we really need so complicated names like
[[Special:MWOAuthManageMyGrants]]
Couldn't it be just [[Special:MWOAuthManage]]
or [[Special:MWOAuthGrants]]
I think it would make sense. Could you open
On Fri, Aug 23, 2013 at 06:53:29AM -0700, Bry8 Star wrote:
At my first few small-scale implementations, i did not pay attention
to rate-limiting techniques, then i realized its importance over time.
RRL support for gdnsd is being tracked upstream at:
https://github.com/blblack/gdnsd/issues/36
2013/8/23 Lars Aronsson l...@aronsson.se
A naive approach would be
to ask for a random article that wasn't created by a
bot, but this is not to the point. Users want bot
generated articles to come up, only not so often.
Unfortunately, there is no exact measure of the human or bot factor of
On 8/23/13, Guillaume Paumier gpaum...@wikimedia.org wrote:
Hi,
It would be great if a few pairs of eyes could take a look at
https://meta.wikimedia.org/wiki/Tech/News/2013/34 before I send it to
translators, to check that I haven't missed anything super-important
or misunderstood what the
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
It would
On Fri, Aug 23, 2013 at 1:38 PM, Bináris wikipo...@gmail.com wrote:
Unfortunately, there is no exact measure of the human or bot factor of the
creator of an article, and I have long been sad because of this. Botness of
an editor is only stored in recent changes table for a while, and cannot be
- Should MediaWiki support allowing some users to use http for their
login, while most users use https? If yes, what are reasonable criteria for
determining who can use http (e.g., user groups, GeoIP, or some other
criteria)?
I don't have an answer for this, but if it is done
On Aug 23, 2013 7:46 PM, Chris Steipp cste...@wikimedia.org wrote:
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
Hi,
shameless plug to remind you of my regular blogging on Bugzilla use:
If you deal a lot with Wikimedia Bugzilla and if you deal with a lot of
bug reports with varying quality (for example because you triage bug
reports), I recommend to take a look at my latest blogpost covering
Greasemonkey
On Fri, Aug 23, 2013 at 10:46 AM, Chris Steipp cste...@wikimedia.org wrote:
With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.
I started:
The day we have all equally hoped for and dreaded is come to pass: Etherpad
Lite has now replaced Etherpad Classic in production, and the labs instance
is on its way out.
This is my as-wide-as-possible email warning to say that everything on the
labs instance, as really should have been expected,
CC'ing staff as we might have some non engineers using this service
who should know.
On Fri, Aug 23, 2013 at 1:02 PM, Mark Holmquist mtrac...@member.fsf.org wrote:
The day we have all equally hoped for and dreaded is come to pass: Etherpad
Lite has now replaced Etherpad Classic in production,
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually still
want that I can attempt to revive that part of my patch. I think it'd be of
especial interest to require HTTPS for checkusers and oversight people, due
to the legal problems
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page?
You're missing the point. People who have (for instance) checkuser or
oversight should be simply disallowed from logging in
On 08/23/2013 04:02 PM, Mark Holmquist wrote:
And in the future: If a URL has wmflabs.org in it...don't put anything,
ANYTHING, important there. The purpose of labs is to let us experiment with
new technology without having to worry about reliability.
It'd be more correct to say that any
On 23 August 2013 21:28, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page?
You're missing the point. People who have (for
On 23 August 2013 16:25, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually
still
want that I can attempt to revive that part of my patch. I think it'd be
of
especial interest to
quote name=Sumana Harihareswara date=2013-08-23 time=16:16:21 -0400
Thanks to Mark Holmquist for maintaining http://etherpad.wmflabs.org for
the past long while. It is going down in 2 weeks, so please retrieve
your text.
I recommend that you:
* go into your browser history
* search it
Why is a DB merge not possible? Will the DB be kept somewhere, e.g. in
the private data of downloads.wikimedia.org?
Nemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are the one we
/least/ want to have their password snooped, and the ones
On 23 August 2013 17:10, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are
Hello!
Here is your deployment highlights email for next week!
The full schedule can be found at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_August_26th
== Monday ==
* MediaWiki 1.22wmf14 will roll out to the second group of wikis:
All non-Wikipedia sites (Wiktionary,
We don't consider etherpad archive-worthy. It's always been considered an
ephemeral service and we're not willing to put any effort into to save data
from it. If you care about data that you've personally hosted in it, please
put it somewhere that's meant to be archived.
We don't have backups for
Rob H. has been doing this manually for us, and we've essentially been ensuring
our pads are in wikitext to assist with the drop-in ease of this process.
Sounds like a fun project, though, once we get etherpad-lite up to a current
rev :)
Thanks.
--Ken.
On Aug 23, 2013, at 4:43 PM, Greg
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker...@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities. A decision
to
On Fri, Aug 23, 2013 at 6:16 PM, Ryan Lane rlan...@gmail.com wrote:
Well, it's also possible that you're just not having clever enough ideas,
eh? ;)
True, but to be honest, if we come up with a clever enough idea, from
China's perspective that's just us getting around their security, which
On 23 August 2013 18:13, Tyler Romeo tylerro...@gmail.com wrote:
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker...@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those
On 23 August 2013 23:31, Risker risker...@gmail.com wrote:
There are other options. The question is whether or not they can be made to
work in the MediaWiki/WMF circumstances. If you looked at the data
collected to see where HTTPS attempts were unsuccessful, you'd see that
there are editors
On Fri, Aug 23, 2013 at 6:35 PM, David Gerard dger...@gmail.com wrote:
And until then, it actually needs to be HTTPS-only. I'm horrified it
isn't already.
Also, now would be a good time to mention that it is impossible to force
HTTPS login for checkusers due to the current GeoIP solution that
So, some ideas:
As for the idea that we need to fix internet that's so bad it can't handle
HTTPS for technical reasons; anything that's that broken is pretty
hopeless to fix from the web server's end. Instead, consider:
* provide support to groups working for improving internet access in areas
On 23 August 2013 18:35, David Gerard dger...@gmail.com wrote:
On 23 August 2013 23:31, Risker risker...@gmail.com wrote:
There are other options. The question is whether or not they can be made
to
work in the MediaWiki/WMF circumstances. If you looked at the data
collected to see where
On Fri, Aug 23, 2013 at 6:43 PM, Risker risker...@gmail.com wrote:
Well, I'm not terribly technical, but I don't think there's ever been
consideration of linking login requirements to user permissions. Perhaps
that needs to change. I'm concerned too.
Unfortunately it's very difficult to do
On 23 August 2013 18:42, Brion Vibber bvib...@wikimedia.org wrote:
So, some ideas:
snip
And for the some countries block our HTTPS issue:
* *actually support* use of Tor etc for editing, allowing folks in the
know to work around the government blocks and use the site over HTTPS
snip
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker...@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built
into their tools (I believe on all projects), so they can
edit/administer/checkuser/etc using Tor.
But given that over 95% of anything that comes
On 08/23/2013 05:33 PM, Risker wrote:
there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities
Interesting. Would you care to share with whom that offline
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvib...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker...@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built
into their tools (I believe on all projects), so they can
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion
is happening?
... and, more importantly, /why/ is that discussion taking place offline
in the first place?
-- Marc
___
Wikitech-l mailing
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker...@gmail.com wrote:
No it doesn't change the security consideration. What changes is the
recognition that the problem may actually be bigger than initially thought.
Everyone knew about China and Iran. Probably nobody knew about Pakistan,
On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer tba...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvib...@wikimedia.org
wrote:
I would strongly recommend a saner signup/account moderation system for
less trusted network origins such as Tor nodes, though. The key is
On 23 August 2013 19:40, Marc A. Pelletier m...@uberbox.org wrote:
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion
is happening?
... and, more importantly, /why/ is that discussion taking place offline
in the first place?
As you
On 23 August 2013 19:55, Rob Lanphier ro...@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker...@gmail.com wrote:
No it doesn't change the security consideration. What changes is the
recognition that the problem may actually be bigger than initially
thought.
Everyone
Tim Starling wrote:
The test used upload.wikimedia.org, at a time when the
browser would already have a keepalive connection open to port 80 but
not port 443. Client-side aborts caused by navigating away from the
page are not logged, and so if the HTTP request completes earlier than
the HTTPS
54 matches
Mail list logo
