> What is your plan to clean up the mess you made?
>
I need to call you out on this MZ. This is an incredibly rude way to
phrase this.
I get that our community tends to accept this kind of behavior, but I
think we should really put effort into coming up with some method of
discouraging people from acting this way.
- Ryan
> The link breakage sucks, but it's not my primary concern at this point. My
> primary concern is that the archive now appears to be corrupt. Messages have
> apparently gone missing from years ago (e.g., the Tim Starling Day
> announcement from October 31, 2003) and there are artifacts of messages now
> erroneously appearing in the August 2012 archive (31 messages with the
> subject line "No subject"). Is it possible for someone to take a look at
> this corruption and assess what can be done to fix it?
>
A lot of these have been broken for ages, due to the same problem as
now. Were these links working prior to this latest breakage?
- Ryan
>That said, I'm not overly irritated. There are a few links I need to
>update, but that's doable. Thanks for handling this issue, and for being
>responsive to the concerns raised.
While there's 475 links to wikitech-l archives on en wikipedia. That's
more than a "few" imo.
The real concern here is that many of those links will never be fixed,
and people looking in the obscure talk page archives of wikipedia,
will never be able to find the relavent mailing posts. This makes it
much harder to look into the history of certain things. I'm aware
similar incidents have happened in the past - that does not make
future incidents ok.
Secondly, I'd just like to extend a giant *hug* to Daniel Zahn, who
from the sounds of it did not expect this to be such a controversial
issue.
Third, I'd like to reiterate what others said about folks taking a
chill pill. Additionally I'd like to add that mistakes happen, we all
make them. The important thing is to realize we've made a mistake,
mitigate the affect of the mistake, and document the mistakes so that
others don't make them. Yelling and screaming about mistakes doesn't
really help anything.
--bawolff
Hi everyone,
I'm starting a separate thread, because this is an important topic and
I don't think it's well served as a subtopic of a "Wikidata blockers"
thread.
To recap, Jeroen submitted changeset 14295 in Gerrit
<https://gerrit.wikimedia.org/r/#/c/14295/> with the following
summary:
> This commit introduces a new table to hold site data and configuration,
> objects to represent the table, site objects and lists of sites and
> associated tests.
> The sites code is a more generalized and less contrived version of the
> interwiki code we currently have and is meant to replace it eventually.
> This commit does not do away with the existing interwiki code in any way yet.
> The reasons for this change where outlined and discussed on wikitech here:
> http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html
Thanks Brian for summarizing an important point:
On Fri, Aug 10, 2012 at 6:33 AM, bawolff <bawolff+wn(a)gmail.com> wrote:
> First and foremost, I'm a little confused as to what the actual use
> cases here are. Could we get a short summary for those who aren't
> entirely following how wikidata will work, why the current interwiki
> situation is insufficient? I've read the I0a96e585 and
> http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html,
> but everything seems very vague "It doesn't work for our situation",
> without any detailed explanation of what that situation is. At most
> the messages kind of hint at wanting to be able to access the list of
> interwiki types of the wikidata "server" from a wikidata "client" (and
> keep them in sync, or at least have them replicated from
> server->client). But there's no explanation given to why one needs to
> do that (are we doing some form of interwiki transclusion and need to
> render foreign interwiki links correctly? Want to be able to do global
> whatlinkshere and need unique global ids for various wikis? Something
> else?)
I've included the rest of Brian's mail below because I think his other
points are worth responding to as well, but included the above because
I wanted to reiterate his core set of questions.
I don't mean to jerk y'all around. I'm pushing the Platform devs
(Tim, Aaron, Chad, and Sam in particular) to be responsive here, and
based on the conversations that I've had with them, they have these
questions too.
Rob
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/thread.html#60992
---------- Forwarded message ----------
From: bawolff <bawolff+wn(a)gmail.com>
Date: Fri, Aug 10, 2012 at 6:33 AM
Subject: [Wikitech-l] Wikidata blockers weekly update
To: wikitech-l <wikitech-l(a)lists.wikimedia.org>
> Hey,
>
> You mean site_config?
> > You're suggesting the interwiki system should look for a site by
> > site_local_key, when it finds one parse out the site_config, check if it's
> > disabled and if so ignore the fact it found a site with that local key?
> > Instead of just not having a site_local_key for that row in the first place?
> >
>
> No. Since the interwiki system is not specific to any type of site, this
> approach would be making it needlessly hard. The site_link_inline field
> determines if the site should be usable as interwiki link, as you can see
> in the patchset:
>
> -- If the site should be linkable inline as an "interwiki link" using
> -- [[site_local_key:pageTitle]].
> site_link_inline bool NOT NULL,
>
> So queries would be _very_ simple.
>
> > So data duplication simply because one wiki needs a second local name
> will mean that one url now has two different global ids this sounds
> precisely like something that is going to get in the way of the whole
> reason you wanted this rewrite.
>
> * It does not get in our way at all, and is completely disjunct from why we
> want the rewrite
> * It's currently done like this
> * The changes we do need and are proposing to make will make such a rewrite
> at a later point easier then it is now
>
> > Doing it this way frees us from creating any restrictions on whatever
> source we get sites from that we shouldn't be placing on them.
>
> * We don't need this for Wikidata
> * It's a new feature that might or might not be nice to have that currently
> does not exist
> * The changes we do need and are proposing to make will make such a rewrite
> at a later point easier then it is now
>
> > So you might as well drop the 3 url related columns and just use the data
> blob that you already have.
>
> I don't see what this would gain us at all. It's just make things more
> complicated.
>
> > The $1 pattern may not even work for some sites.
>
> * We don't need this for Wikidata
> * It's a new feature that might or might not be nice to have that currently
> does not exist
> * The changes we do need and are proposing to make will make such a rewrite
> at a later point easier then it is now
>
> And in fact we are making this more flexible by having the type system. The
> MediaWiki site type could for instance be able to form both "nice" urls and
> index.php ones. Or a gerrit type could have the logic to distinguish
> between the gerrit commit number and a sha1 hash.
>
> Cheers
[Just to clarify, I'm doing inline replies to things various people
said, not just Jeroen]
First and foremost, I'm a little confused as to what the actual use
cases here are. Could we get a short summary for those who aren't
entirely following how wikidata will work, why the current interwiki
situation is insufficient? I've read the I0a96e585 and
http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html,
but everything seems very vague "It doesn't work for our situation",
without any detailed explanation of what that situation is. At most
the messages kind of hint at wanting to be able to access the list of
interwiki types of the wikidata "server" from a wikidata "client" (and
keep them in sync, or at least have them replicated from
server->client). But there's no explanation given to why one needs to
do that (are we doing some form of interwiki transclusion and need to
render foreign interwiki links correctly? Want to be able to do global
whatlinkshere and need unique global ids for various wikis? Something
else?)
>* Site definitions can exist that are not used as "interlanguage link" and
>not used as "interwiki link"
And if we put one of those on a talk page, what would happen? Or if
foo was one such link, doing [[:foo:some page]] (Current behaviour is
it becomes an interwiki).
Although to be fair, I do see how the current way we distinguish
between interwiki and interlang links is a bit hacky.
>And in fact we are making this more flexible by having the type system. The
>MediaWiki site type could for instance be able to form both "nice" urls and
>index.php ones. Or a gerrit type could have the logic to distinguish
>between the gerrit commit number and a sha1 hash.
I must admit I do like this this idea. In particular the current
situation where we treat the value of an interwiki link as a title
(aka spaces -> underscores etc) even for sites that do not use such
conventions, has always bothered me. Having interwikis that support
url re-writing based on the value does sound cool, but I certainly
wouldn't want said code in a db blob (and just using an integer
site_type identifier is quite far away from giving us that, but its
still a step in a positive direction), which raises the question of
where would such rewriting code go.
> The issue I was trying to deal with was storage. Currently we 100% assume
>that the interwiki list is a table and there will only ever be one of them.
Do we really assume that? Certainly that's the default config, but I
don't think that is the config used on WMF. As far as I'm aware,
Wikimedia uses a cdb database file (via $wgInterwikiCache), which
contains all the interwikis for all sites. From what I understand, it
supports doing various "scope" levels of interwikis, including per db,
per site (Wikipedia, Wiktionary, etc), or global interwikis that act
on all sites.
The feature is a bit wmf specific, but it does seem to support
different levels of interwiki lists.
Furthermore, I imagine (but don't know, so lets see how fast I get
corrected ;) that the cdb database was introduced not just as
convenience measure for easier administration of the interwiki tables,
but also for better performance. If so, one should also take into
account any performance hit that may come with switching to the
proposed "sites" facility.
Cheers,
-bawolff
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I've had a good idea for an anti-spam system for awhile.
Blocks, Captchas, and local filters, all the tricks we've been using end
up not working well enough to easily deal with the spam on a lot of wikis.
I know this because I've been continually dealing with the spam on a small
dead wiki. Simple AntiSpam, AntiBot, Captchas, TorBlock, Abuse Filter...
Time after time I expand my filters more and more. But inevitably a few
days later spam not covered by my filters comes through and I have to do
it again.
I ended up having to deal with it more today and then started writing out
the details I've had for awhile on a machine-learning based anti-spam
system.
https://www.mediawiki.org/wiki/User:Dantman/Anti-spam_system
Of course. While I have the whole idea for the ui, backend stuff, how to
handle the service, etc... I haven't done the actual machine-learning
stuff before.
Also naturally just like Gareth, OAuth, and other things this is just
another one of my ideas I don't have the time and resources to do and wish
I had the financial backing to work on.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Without calling out anyone specifically, everyone needs to calm down about
6 notches. If people can't talk to one another without hurling insults,
then I'll have to start putting people on moderation. Impassioned debate is
healthy, but the attacks need to stop.
-Chad
(wearing my list mod hat)
Good evening, wikitech-l!
I've been developing an extension recently called EtherEditor [0]. I
emailed this list about it twice [1] before [2], mostly to ask for help
testing it at various times.
To sum up, the extension, with proper configuration, enables multi-user,
real-time collaborative editing of the wikitext of any page.
Well, this project is coming to the point where *I* think it's pretty
stable. There are still a few details to iron out, and I'm excited to
fix those things, but there are also a few things I haven't ever tested.
Most notably, multiple users for an extended period of time, and all the
fun bugs that are sure to appear in that case.
So I'm here to ask for some volunteers to help me test EtherEditor
tomorrow, between 20:00 and 22:00 UTC. I'll be in #ethereditor on
Freenode with a list of things to try out, and really, some number of
people helping me stress test the connections to the backend would be
immensely useful.
If you don't have an account on Freenode, or prefer to contact me in
some other way, the best way is probably to use this email address. If
you have any questions, you can always ask them on-list.
If you want to chat about the extension at any time, you can always join
the IRC channel (#ethereditor on Freenode), and I'm always online.
Remember that IRC isn't necessarily a synchronous communication system,
and be patient when asking questions.
In case you want to try the extension, it is and has been running on my
TestWiki instance [3], so feel free to attack it! If you could report
any problems on the Bugzilla [4], I will gladly fix them with great
quickness! If you want to try installing it on your own MediaWiki
instance, the mw.org entry [0] has some instructions for that. As
before, please report problems to the Bugzilla [4] :)
Links:
[0] http://www.mediawiki.org/wiki/Extension:EtherEditor
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/061188.html
[2] http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/061517.html
[3] http://etherpad.wmflabs.org/wiki/index.php/Main_Page
[4]
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
Thanks, everyone!
--
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur(a)member.fsf.org
http://marktraceur.info
Is anybody working on OAuth for MediaWiki? Because if not I might put
something together (i.e., start putting together design documents based on
http://www.mediawiki.org/wiki/OAuth).
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com
A brief note, we're about to start a stress test of EtherEditor, an
extension for real-time collaborative editing, at 20:00 UTC. If you'd
like to help out, or if you'd like to watch, do please join us in
#ethereditor on Freenode. If you don't have IRC for whatever reason, but
still would like to help out with the project, feel free to email me
(either on-list or off) or just check out the mediawiki.org page about
the extension [0].
[0] http://www.mediawiki.org/wiki/Extension:EtherEditor
Thanks!
--
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur(a)member.fsf.org
http://marktraceur.info
> Hello,
>
> We didn't have a bug triage since May. I suggest organizing one in a few
> weeks (say 2?)
>
> I agree to take care of this if it is widely supported.
> How about focusing on patch triage?
>
> I mean reviewing bugs with patches attached but not in gerrit.
>
> Any other subject would be good as well.
>
> opinions?
>
> Matanya
I think this is an excellent idea.
A patch triage sounds like a good idea, especially for a first such
triage after no one doing them in a while. After all even in magical
git land, its still important to respond to bugzilla patches. If this
triage session is successful, I think doing future sessions of
"prioritize and assign the incoming bugs" would also be good
/me just really misses all hexmode's bug spam :)
Re Al Snow
> b. Verify fix
> * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
>
> c. Accept non-fix resolution
> * Accepting all non-fixed resolution.
> * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 non-"FIXED" RESOLUTION values)
I thought that's what Wikipedia was for (joke, but only sort of.
There's enough open bugs in need of love that verifying a RESOLVED
WORKSFORME bug really works for us doesn't seem that useful)
-bawolff