On Tue, Nov 4, 2008 at 1:44 PM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:
[snip]
would never catch up, but that's not a reason not
to try - even if we
accept we can't feature every FA, we can still try and feature as many
as possible.
Right. And even if we'd catch up with today's rate, tomorrow might
still be faster. A second article would *double* the coverage. I
think thats a pretty good return on inches of screen space.
My idea last time was to split FAs into two categories
(I think I
suggested pop culture articles and more academic articles, although
someone else suggested bios and non-bios which might be better -
easier to define, certainly) and take one from each, that way people
are more likely to find an FA they are interested in. An exception
could obviously be made when they are topical articles or interesting
pairs.
Clustering is an interesting idea. I'd support whatever. I'd
especially support mixing it up and trying different things.
I didn't realise it was randomised, that's
clever! I'd assumed it was
alphabetical by surname (which is how it displayed for me for the
first time - I've refreshed now and seen it switch, very clever
indeed!). Are we gathering the appropriate stats at the moment or was
that just an idea for the future (it's a good idea, either way)?
We can tell which one people click on, though we can't tell which
order they were when they clicked. (that could be done, though, I
suppose)
The reordering code was something I did for the WMF board elections
two-ish years ago. I wasn't aware of the decision to run two articles
until it was already live, then add in the time it took for an EnWP
admin bold enough to make the change. Unfortunately the site JS is
cached, so not everyone will see the random order. Fortunately (for
once) IE and Firefox have dumb caching which won't preserve the cache
across sessions, so I expect most of the public will get the random
ordering.
(When
we're done with this discussion we could move onto the fact that
both of today's articles are hard-full-protected and how nice it would
be if we were using revision flagging with display-flagged instead...)
It was unavoidable in this case - flagged revs would certainly have
been a better solution. We'll get there eventually!
I'd like to see a consensus demonstrated that flagged revs would have
been better here because even past proposals to use them strictly as a
replacement for protection have come under fire.