Le 26/09/13 00:46, Chad a écrit :
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at
a given time. Try `git branch -r` on core. We're at 86 branches now...that's
172 if you've got two remotes. It's only going to get
Hi Ori,
Is there a reason for having Guest Additions Version 4.1.12 in the VM
instead of 4.2?
$ vagrant up
(...)
[default] VM booted and ready for use!
[default] The guest additions on this VM do not match the installed version
of
VirtualBox! In most cases this is fine, but in rare cases it can
CC-BY-SA/GFDL is in the same spirit as GPL, which is an obviously
acceptable license for WMF (since MediaWiki is written in it).
Can you explain the need to relicense it under MIT?
2013/9/26 Steven Walling swall...@wikimedia.org
Forwarding, with permission.
For background the AFC Helper
Heya folks :)
Wikimedia Deutschland is looking for a software developer to work on
all kinds of frontend-related things on exciting projects like
Wikidata in a very cool team. If you're currently looking for a job
and have the necessary skills please apply. You can find details at
On Thu, Sep 26, 2013 at 1:52 AM, Željko Filipin zfili...@wikimedia.orgwrote:
Hi Ori,
Is there a reason for having Guest Additions Version 4.1.12 in the VM
instead of 4.2?
It's what Canonical's Vagrant image provides, and it's because that's the
version that is packaged for Precise.
A little additional information on topic 1 -- The pull request including the
changes that this contributor to the script made can be viewed at
https://github.com/WPAFC/afch/pull/54/files if it is of any interest. Thanks.
From:
Hi,
I noticed that there is a high amount of suspicious edits that may be
vandalism but were never reverted because people who were dealing with
vandals (using some automated tool) in that moment weren't able to
decide if it was vandalism or wasn't. For example some smart changes
to statistical
That idea sounds like something already that could be done by the Flagged Revs
extension.
Given that many of those suspicious edits could be extremely subtle, like minor
changes to mathematical equations and statistics, articles with lots of
potential for those types of subtle vandal edits
Hi,
That makes sense, but I don't think this is going to happen. Flagged
Revs were never really popular on english wikipedia and this is a real
problem that should be solved somehow. These edits were always
reviewed by people who are already using huggle or twinkle, this
change couldn't make it
On Wed, 2013-09-25 at 21:48 -0400, Mark A. Hershberger wrote:
According to the Version lifecycle[1], MediaWiki 1.22 is slated for
release on November 30th, at the very latest.
In that vein, we've come up with a timeline for the release[2]. If we
use this timeline and shoot for the latest
IANAL, but you might want to take a look at how the vlc people handled this
kind of problems - i remember a huge rewrite effort from their part, but no
link on hand, sorry.
Strainu
Mr. Donald J. Fortier II technical...@yahoo.com a scris:
A little additional information on topic 1 -- The pull
I made the mistake of looking at it, and now can no longer provide a clean
room implementation. If it is just the one jQuery commit, reverting it
should probably suffice.
On Sep 26, 2013 5:22 PM, Strainu strain...@gmail.com wrote:
IANAL, but you might want to take a look at how the vlc people
Hi Petr,
I can see the value. Although I'm not entirely sure how you were planning
on identifying these edits-- are you thinking all our current tools would
have another classification (like more review needed), and submit them?
Or would these be identified by another, new bot?
On Thu, Sep
On Thu, Sep 26, 2013 at 1:09 AM, Antoine Musso hashar+...@free.fr wrote:
Le 26/09/13 00:46, Chad a écrit :
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at
a given time. Try `git branch -r` on core. We're at
Yes, I mean this identification. The tools would have button like
needs review by expert which would have similar effect like skip
but the edit would be enqueued somewhere so that experts could review
it later and revert in case if it wasn't correct.
Only task what would need to be done by a bot
This queue already exists: it's the absolute complement of
[[Help:patrolled edit|]]s.
https://meta.wikimedia.org/wiki/Help:Patrolled_edit
Nemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
But this works the other way, every edit is marked as suspicious
while users can flag these that appear to be OK. What I am talking
about is the other way. Vandal fighters would flag these edits that
look weird to them and experts would review only those edits, not all
of them.
On Thu, Sep 26,
That's a problem in the client, not in MediaWiki. To implement that with
current code, you can patrol everything that is not suspicious and
you'll get what you describe; if your patrolling bot is error-prone you
may hypothetically need an unpatrol feature, but then just fix the bot.
Nemo
No I wouldn't. The queue would start getting filled up by good edits
in case everyone who uses huggle would disconnect or stopped using it.
The current system as it is clearly isn't sufficient for this. We need
to cherry-pick the bad edits, not good edits. Current system allows
only to flag good
I am also not talking about mediawiki at all. This evidence of edits
that needs further review could be stored off-wiki, for example on
wikimedia labs using some universal interface that all antivandalism
tools can use
On Thu, Sep 26, 2013 at 7:41 PM, Petr Bena benap...@gmail.com wrote:
No I
On 09/25/2013 12:17 PM, Juliusz Gonera wrote:
I've just checked on my local instance and it seems that this patch
does not change much for the MobileFrontend. As I stated in the first
message, we need to distinguish between warnings and disallowed edits
because they require different UI
Sumana Harihareswara recently provided me assistance with some code I wanted
to write and invited me to join the wikitech mailing list, and she also
suggested I share my response to her with the rest of the list subscribers,
which I have reproduced (with some mild alterations) below:
Thanks
On 26/09/13 23:06, Petr Bena wrote:
Hi,
I noticed that there is a high amount of suspicious edits that may be
vandalism but were never reverted because people who were dealing with
vandals (using some automated tool) in that moment weren't able to
decide if it was vandalism or wasn't. For
Tim Starling wrote:
I used to just revert them automatically when such changes appeared on
my watchlist. If someone changes the population of Denmark or the
formation enthalpy of carbon tetrachloride, without providing any
reference or any suggestion that it is a revert, the chances that the new
- Original Message -
From: MZMcBride z...@mzmcbride.com
Much of the content on Wikipedia and other Wikimedia wikis comes from
non-vested contributors. That is, many, many helpful additions and
corrections come from people who will make only a few edits in their
lifetime. While I
25 matches
Mail list logo
