> From: Bryan Derksen [mailto:bryan.derksen@shaw.ca]
> Cyberjunkie wrote:
>
> >Be bold!
> >
> >
> Well, I guess just having a vote cascade on the mailing list
> isn't going
> to work. Hrmph. Anyone know who specifically is "in charge"
> of deciding
> what Wikimedia configuration to use? Or is the problem perhaps that
> there _isn't_ anyone specifically in charge? :)
Until now, developers simply judged consensus - usually from the mailing
list. If they hesitate to do so now, with 100 times as many contributors
as we had 2 years ago, then let's put it to a vote.
Angela, what's the proper way to vote on this?
Ed Poor
Yes, of course that is the problem. There are several developers who
> could enable the feature, but all of them are now in fear
> that something
> will go Horribly Wrong(tm), so each individual one of them
> doesn't want to
> be held responsible in the end, so they don't do it and hope that
> someone else will do it and take the blame instead.
>
> Which is kind of weird, because Brion and Tim have done much more
> "dangerous" things in the past, and every once in a while it
> does bring
> the servers down, but they always fix it swiftly and it's
> never a big deal.
>
> This wouldn't be any different, had it not been for the initial
> FUD-laden discussion, which now leaves the developers fearful
> of social
> repercussions.
>
> Timwi
If one developer will turn it on, while half a dozen other articles
eyeball the system for problems, the experiment should be safe enough.
No one will blame you. Tell you what, let ME take the blame.
Uncle Ed
I have no idea what this is all about, but I noticed with some
surprise that someone briefly put Edward R. Murrow in the category of
"Soviet spies!" I can only suppose that someone is trying to fill out
that category to make it contain exactly 205 names.
--
Daniel P. B. Smith, dpbsmith(a)verizon.net
"Elinor Goulding Smith's Great Big Messy Book" is now back in print!
Sample chapter at http://world.std.com/~dpbsmith/messy.html
Buy it at http://www.amazon.com/exec/obidos/ASIN/1403314063/
> The code has already been tested in such a fashion - the
> question is whether it can stand a production load.
>
> Perhaps the true problem is that we do not have any method of
> simulating a production load adequately.
>
> -Matt
You can copy all "hits" and "edits" from the production server into a
log. Then feed the log into the test server at whatever rate you choose.
I can help design this.
Ed Poor
Former holder of various offices
I think my original point still went unaddressed...I think we're still going
about using mistaken ideas about judging the current state of the articles
collectively. In particular, I strongly do *not* believe that hitting the
"random page" button 20 times (or even 20,000 times) is a very valid way of
assessing the success of the project, for specific reasons. I don't mean to
sound like I'm attacking those who've done this...after all, who hasn't
played around with the random page button?? I know *I* certainly have. But,
we should remain critical.
There are many objections. First, as Charles pointed out, in any system
which is growing even roughly *exponentially*, you would expect the relative
*percentage* of a particular type of article to remain roughly constant over
time. In other words, it should come as neither a great shock nor a great
threat that the *percentage* of stubs, bad articles, etc. has remained
constant over time. This is what is expected, given the growth, and given
that we're nowhere near an "equilibrium".
Here is a more equitable procedure: hitting the "random page" button
essentially assigns the same probability to each article. But, is this
really useful? What would be *more* accurate would be to assign a
probability to each article proportional to the actual number of hits it
gets from flesh-and-blood readers. By assigning equal probability to every
article, this puts some obscure fan fluff stub article on an equal par with
[[United Stated of America]], even though the latter may command 100s or
1000s of times the actual page views/day of the former.
But an even stronger objection I have to the "hit the random page button 20
times" approach is that it collects an essentially *static* view of the
process. To put it mathematically, we are only looking at the 0th
derivative, instead of the *FIRST* derivative, let alone the 2nd or
higher-order derivatives. Of course -- in order to consider anything beyond
the "0th derivative" you have to have more than a static view. You have to
know what's going on in some time-region. You have to have a *longitudinal*
view.
Here's what I would suggest would be more enlightening: go back 24 months,
when the English wiki had roughly 200,000 articles. *Then*, hit the random
page button 20 times. Then follow and see how those 20 articles have
improved or degraded in the following 24 months. If many of the worst of
these 20 articles show little or negligible improvement in the past 24
months, then I think this is something that needs to be thought about. But
as it is, we're ignoring the possibility that many of the good (or even
brilliant) articles of today might have been classified as stub or atrocious
24 months ago. And then we're pointing to the stubs and atrocious articles
of *today* as evidence that the project is failing?? Does the irony of this
make sense?
There are many other issues which are completely ignored by taking a static
view. For instance, someone noted that general articles on basic issues are
often in a much worse shape than highly-specialised articles on obscure
topics. This has sometimes been an issue in math. It's something that needs
to be thought about.
darin
> Poor, Edmund W wrote:
>
> > But all is not lost. If we mark articles as bad or stub, we
> could keep
> > them somewhat hidden from the public.
> >
> >
> >
> *COUGH* validation feature *COUGH*
>
> 'cuse me, I'm recovering from a cold ;-)
>
> Magnus
Jeez Louise, Magnus: WHEN are you going to turn on the validation
feature? Are you waiting for Anthere or someone to "certify" that there
is a "consensus" to try out the feature?
Please just turn it on. We will all play with it for a few weeks and
decide if it should be permanent.
And if there's a "performance degradation", surely you will detect that
problem and yank the feature. But you already assured us that this is
highly unlikely.
Ed Poor
A professional software developer at a major TV network
> and turn it on and see what happens. If all else fails the
> person who runs the other wiki project I work on would love
> to have this feature.
>
> --
> geni
Well, I'm the technical coordinator for another wiki project - with less
than 100 users. I could have our programming staff (1 young man from
Russia!) test the feature and then report back to you guys in a couple
of weeks.
But you're really making a mountain out of a molehill. The only risk is
a slight degradation in performance. And that goes away instantly, as
soon as ANY of the programmers turns the switch off.
Right, Magnus, Timwi, et al.?
Ed Poor
Developer Emeritus, Wikipedia
Technical Coordinator for the UC's "Encyclopedia Project"
> It seems to me (please correct me if I'm wrong) that Brion
> has failed to
> provide adequate explanation with regards to the perceived
> problems with
> the feature. It seems that several times, Magnus Manske (the
> author of
> the feature) has posted to wikitech-l asking why the feature
> isn't being
> enabled; Brion would reply stating a few "problems" which
> Magnus quite
> convincingly demonstrates are either fixed by now, or have never
> actually been a problem. Brion then never replies to those
> refutations
> again and just leaves everyone puzzled.
>
> > but it's understandably frustrating to those of us who
> REALLY REALLY
> > WANT IT IN.
>
> The situation as I have outlined it above is not only
> frustrating, but
> actually somewhat angering. If he can't turn the feature on
> or explain
> what's wrong with it, then maybe he shouldn't be "in charge"
> or at least
> not the only one.
>
> Timwi
This is the kind of politics that made me quit the development team a
couple of years ago, and also what led me to being mostly inactive even
after joining _three_ years ago. Technical leadership is difficult, and
developers are no better than average (merely because they are computer
"scientists") than any other group, at cooperating.
I hope one person will be BOLD, knowing that if a problem actually DOES
crop up, the feature can simply be shut off.
Ed Poo
Developer Emeritus
> Well, your list at least led me to [[opcode]], which was
> awful, so I rewrote it. ;)
>
> Our coverage of many basic computing topics is rather
> surprisingly horrendous.
>
> -Matt (User:Morven)
It's so bad, I shudder at the prospect of trying to fix ANY of it -
especially when I have to fight against non-programmers and other
ignorant folks. Now, if a Wikipedia developer or two wanted to join me
for a WikiProject Computing . . .
Ed Poor
Professional Software Development Engineer