Hi all,
It's been 10 days since the last note on flagged revisions, which is
sufficiently important to warrant a follow up at this point in my view. I'll
try and focus the questions a bit in order not to pester, but with the
intention of helping things forward;
see https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 for bug details.
* Flagged Revisions is approved for use on the English Wikipedia, my
understanding is that there really isn't that much technical work still to
do on the extension - is this true?
* Is there anything a regular editor such as myself can do to help
prioritise this in the hearts, minds and fingers of our wonderful
developers?
* Personally, I believe this function to be one of the most important
matters before the foundation currently, I further believe that this view is
relatively widely held (and sure, widely reviled too - but this is a wiki,
right!) - I've copied foundation-l in on this note with the intention of
further general discussion occurring there, and bug-specific chat only on
the wiki-tech list, I hope this is an appropriate use of resources :-)
I've offered appreciation, a dollop of charm, and a little bit of money to
try and keep this moving forward.... I'm not sure I'm above offering sex, so
please throw me a bone for the sake of the decorum of these lists, if
nothing else :-)
best,
Peter,
PM.
On Wed, Jun 10, 2009 at 12:46 PM, Gregory Maxwell <gmaxwell(a)gmail.com>wrote:
> Am I confused or didn't enwp approved flagged revisions, but then it
> was held up due to "purely technical reasons" ... what is this crap
> now?
>
> ---------- Forwarded message ----------
> From: K. Peachey <p858snake(a)yahoo.com.au>
> Date: Tue, Jun 9, 2009 at 10:29 PM
> Subject: Re: [Wikitech-l] flagged revisions
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> On Wed, Jun 10, 2009 at 12:08 PM, private musings<thepmaccount(a)gmail.com>
> wrote:
> > with apologies for re-vitalising a slightly old thread -I have a couple
> of
> > follow ups, which it'd be great to try and make some progress on....
> > My understanding is that Aaron (whom I haven't 'met' - so hello!) has
> > completed work on a test configuration of flagged revisions - I hope it's
> > appropraite for me to ask directly on this list whether or not Aaron
> > considers this development complete? (my understanding is that the
> extension
> > is pretty much ready to go?)
> > There is understandably considerable interest in the timeframe for
> > installing flagged revisions, I would hope it would be a positive step to
> > set some timeframes a bit tighter than 'hopefully by wikimedia' ;-) - is
> > this list an appropriate context for such discusison, and if so
> (hopefullly)
> > - could someone appropriately empowered flesh out the next steps a bit
> more,
> > and maybe try and establish a timetable of sorts?
> > My intention in posting about this every so often is to ensure that such
> an
> > important development doesn't sort of slip through the cracks - I think
> > communication on this matter has to date been ok, but not great - it'll
> be
> > cool to improve it a bit :-)
> > cheers,
> > Peter,
> > PM.
> The implementations depend on a per wiki basis depending on consensus,
> for example, wikinews and a few others such as the German Wikipedia
> already run it.
>
> The en.wiki is currently also looking at a slightly modified version
> nicked named "Flagged Protections" which is basically designed to work
> the same way protection does, articles are only covered by it when
> protected to a certain level.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Just a quick note y'all -- we've implemented bug 18902 so we can limit
saving of collections to autoconfirmed users and above. Will be peeking
at other issues with it over the next weeks.
-- brion
Hi all,
I need some hints about how to go about to create a dump filter and a
plugin for dumpBackup.php.
Since I'm a Delphi programmer I'll probably do well the programming of
the inner details, if I only knew how the stub for a filter (& a plugin)
should look.
I need to do quite extensive examination of the text content of articles
before knowing what to keep and what to skip. Sometimes I'd like to even
modify the text before dumping it. Hints about how to design a plugin
would also be apprechiated.
Options according to the dumpBackup.php file:
--plugin=<class>[:<file>]
--filter=<type>[:<options>]
If anyone has done a filter or plugin before, or have a link to an
example, I'd be very happy to take advice. :)
// Rolf Lampa
Hi all
I wonder if the column rc_ip can be safely removed from mediawiki. As far as I
know, it has been superceeded by the information in cu_changes, right? So I
propose to
a) either completely remove it
b) or set $wgPutIPinRC = false per default
c) and set $wgPutIPinRC = false for wikimedia projects.
The rationale is that IP addresses should only be recorded if this is explicitly
requested. In some jurisdiction (e.g. Germany) it is illegal to record this
information without notifying the users, and there is a requirement to only
record data at all if necessary. So it should be off per default. Many
privacy-concious hosters disable IP records in the server logs, recording the IP
in the database per default subverts this.
As to disabling on Wikimedia projects: this would make things easier for the
toolserver mainly. We don't need this info there, and having it might
conceivably make WMDE the target of legal action. We can easily exclude
cu_changes from replication, but we can't easily filter rc_ip from
recentchanges. So it would be better if it wasn't there in the first place.
Thoughts?
Daniel
After being subscribed to the list for two weeks and posting three mails on
one subject I received spam on the address that I used to subscribe/post.
Either address harvesters are adapting to read the "name at domain" format
that is used in the archive, or they auto-subscribe to mailinglists to get
addresses from the traffic, or the news gateways leaks addresses, or
whatever...
I'll unsubscribe and put this address on my blacklist of burnt addresses.
cheers
-henrik
2009/6/15 Huib Laurens <Abigor(a)forgotten-beauty.com>:
> I'm seeing a discussions or even multible discussions about how Commons
> needs to change to be a better service project. But when Commons needs
> to change, will we change all other projects also? There are still
> images getting deleted because we couldn't get the source information or
> other important information because the file was already deleted local,
> there is a bug to give Commons adminstrators view permission for deleted
> files globally, there has been a vote on Meta and still it isn't
> activated (more than a year waiting time). Things like that will make
> Commons also a better service project.. Or isn't that important enough?
Yes, that's exactly the sort of thing Commons needs.
(and this is something of what I meant when asking for constructinve
suggestions on what to do to improve things - in both directions.)
cc to wikitech-l - do you have a bug number for this?
- d.
2009/6/15 Huib Laurens <Abigor(a)forgotten-beauty.com>:
> Here is the page on meta:
> http://meta.wikimedia.org/wiki/Global_deleted_image_review
> That one links to the vote that passed with 80% support.
> And for the bug:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=14801
Looks like there's code to implement it, but it isn't very good ...
Is there an interested dev who could implement better code for this
bug? We appear to have the consensus, we just need good enough magical
incantations to implement it!
- d.
OK, thank you guys. Now the reasons are clear :-). In any case, this forced the parser improvement, so it's welcome anyway ;).
Best,
F.
--- El lun, 15/6/09, Platonides <Platonides(a)gmail.com> escribió:
> De: Platonides <Platonides(a)gmail.com>
> Asunto: Re: [Wikitech-l] Fixing problem with complete dumps in WikiXRay
> Para: wikitech-l(a)lists.wikimedia.org
> Fecha: lunes, 15 junio, 2009 10:44
> Felipe Ortega wrote:
> > Hello, all.
> >
> > For (yet) unknown reasons, last complete dump files
> (pages-meta-history.xml) in some languages are flawed.
> Certain revision items are missing info about rev_user. Even
> though there are only 3 or 4 of that kind, this is enough to
> mess up either the parsing process or the later SQL load
> into the DB.
> >
> > So far, the last 3 dumps of DE Wikipedia and 20090603
> from FR Wikipedia have presented this error.
> >
> > I have updated both WikiXRay parsers:
> > http://meta.wikimedia.org/wiki/WikiXRay_parser
> > http://meta.wikimedia.org/wiki/WikiXRay_parser_research
> >
> > They now probe whether the parsed revision item is
> complete or not, before creating the SQL. If it's flawed,
> its omitted and logged into an error file for later
> inspection.
> >
> > Regards,
> >
> > Felipe.
>
> They're an effect of revdelete.
> You can see how they have a parameter deleted.
> An example is available in the bug for pywikipediabot:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2790339&group_id=9…
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hello, all.
For (yet) unknown reasons, last complete dump files (pages-meta-history.xml) in some languages are flawed. Certain revision items are missing info about rev_user. Even though there are only 3 or 4 of that kind, this is enough to mess up either the parsing process or the later SQL load into the DB.
So far, the last 3 dumps of DE Wikipedia and 20090603 from FR Wikipedia have presented this error.
I have updated both WikiXRay parsers:
http://meta.wikimedia.org/wiki/WikiXRay_parserhttp://meta.wikimedia.org/wiki/WikiXRay_parser_research
They now probe whether the parsed revision item is complete or not, before creating the SQL. If it's flawed, its omitted and logged into an error file for later inspection.
Regards,
Felipe.