On Tue, Nov 4, 2008 at 1:44 PM, Thomas Dalton thomas.dalton@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.