Jussi-Ville Heiskanen wrote:
Erik Moeller wrote:
2009/9/28 Jimmy Wales jwales@wikia-inc.com:
If the Foundation is bottlenecked at the moment (understandable) then how can I help, how can we the community help, to take some of the burden off of them to get done what we need to get done for the sake of our mission? :-)
The process going forward is pretty clear -
a) make sure prototype setup reflects desired behavior as per the en.wp proposal and invite broader testing;
Perfectly reasonable.
b) make revisions to extension based on public and internal review with a particular eye to usability;
Absolutely commendable.
c) ensure that the extension is fully scalable to en.wp traffic volume;
Why on earth would we like to ensure that, particularly *before* point d) ?
I can fully understand that there is a contingent who devoutly hopes that after the current strictly limited use of FR is tried out and people gain more familiarity with the interface and the practical way the extension works, much of the mystique of it will vanish in a puff of smoke and people will be more amenable to extending its use.
Nevertheless in reality the current compromise proposal owes much to people who were able to only accept it with the proviso that quite the opposite of wanting to see it be possible to scale up, they required a reasonable assurance that its use would *not* be escalated without an overwhelming community consensus.
d) deploy on en.wp as per proposal (potentially, per c, initially in some scale-limited fashion).
Not doing d) before being sure of c) seems very much like putting the cart before the horse to me. Whether c) will be relevant at all would necessarily be contingent on the success of d), and the logical order thus should be to just do d) and see later if there is any relevance to c) at all.
Or to put it more plainly; it is a very remote possibility indeed that extending the Flagged Revision experiment in a form that ordinary articles would only display an approved revision (without very strict restrictions on which articles to apply this requirement to) for many people will be something they will accept. So making it a prerequisite that such an application has to be functionally available in the extension for uses as large as the English wikipedia before *any* use of the extension, is rather silly as a concept.
Yours,
Jussi-Ville Heiskanen
On Tue, Sep 29, 2009 at 10:44 AM, Jussi-Ville Heiskanen cimonavaro@gmail.com wrote:
Jussi-Ville Heiskanen wrote:
Erik Moeller wrote:
2009/9/28 Jimmy Wales jwales@wikia-inc.com:
If the Foundation is bottlenecked at the moment (understandable) then how can I help, how can we the community help, to take some of the burden off of them to get done what we need to get done for the sake of our mission? :-)
The process going forward is pretty clear -
a) make sure prototype setup reflects desired behavior as per the en.wp proposal and invite broader testing;
Perfectly reasonable.
b) make revisions to extension based on public and internal review with a particular eye to usability;
Absolutely commendable.
c) ensure that the extension is fully scalable to en.wp traffic volume;
Why on earth would we like to ensure that, particularly *before* point d) ?
I can fully understand that there is a contingent who devoutly hopes that after the current strictly limited use of FR is tried out and people gain more familiarity with the interface and the practical way the extension works, much of the mystique of it will vanish in a puff of smoke and people will be more amenable to extending its use.
Nevertheless in reality the current compromise proposal owes much to people who were able to only accept it with the proviso that quite the opposite of wanting to see it be possible to scale up, they required a reasonable assurance that its use would *not* be escalated without an overwhelming community consensus.
d) deploy on en.wp as per proposal (potentially, per c, initially in some scale-limited fashion).
Not doing d) before being sure of c) seems very much like putting the cart before the horse to me. Whether c) will be relevant at all would necessarily be contingent on the success of d), and the logical order thus should be to just do d) and see later if there is any relevance to c) at all.
Or to put it more plainly; it is a very remote possibility indeed that extending the Flagged Revision experiment in a form that ordinary articles would only display an approved revision (without very strict restrictions on which articles to apply this requirement to) for many people will be something they will accept. So making it a prerequisite that such an application has to be functionally available in the extension for uses as large as the English wikipedia before *any* use of the extension, is rather silly as a concept.
Yours,
Jussi-Ville Heiskanen
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I could be very wrong (and Erik feel free to correct if I am), but I think he was referring to scaling in a completely technical sense of the term, not "does it scale to Wikipedia's article count in relation to its community."
If it's going to bring the servers down, it needs to be fixed before deployment, meaning C is certainly before D :)
-Chad
On Tue, Sep 29, 2009 at 10:44 AM, Jussi-Ville Heiskanen < cimonavaro@gmail.com> wrote:
c) ensure that the extension is fully scalable to en.wp traffic volume;
Why on earth would we like to ensure that, particularly *before* point d) ?
In theory admins could choose to flag-protect every article, I suppose. Ensuring that the extension will scale assuming the flag-protection of say 10 times as many articles as are currently protected and/or semi-protected (with maybe 5 times the current average traffic per article) would probably be safe, though.
2009/9/29 Jussi-Ville Heiskanen cimonavaro@gmail.com:
Absolutely commendable.
c) ensure that the extension is fully scalable to en.wp traffic volume;
Why on earth would we like to ensure that, particularly *before* point d) ?
(...)
d) deploy on en.wp as per proposal (potentially, per c, initially in some scale-limited fashion).
Not doing d) before being sure of c) seems very much like putting the cart before the horse to me. Whether c) will be relevant at all would necessarily be contingent on the success of d), and the logical order thus should be to just do d) and see later if there is any relevance to c) at all.
I believe that "scalable" here refers to putting it on pages which recieve the kind of traffic and editing (or editing attempts) that very high-profile page on enwiki do, rather than "scalable to being applied to three million pages".
At the time Michael Jackson's death was being reported last month, for example, the page was recieving hundreds of thousands if not millions of hits; we protected it. Had we flagged-protected it - which we probably would have done - what would have happened? Would the system have coped? Would we have been able to handle that flood of edits, technically and organisationally?
Andrew Gray wrote:
I believe that "scalable" here refers to putting it on pages which recieve the kind of traffic and editing (or editing attempts) that very high-profile page on enwiki do, rather than "scalable to being applied to three million pages".
At the time Michael Jackson's death was being reported last month, for example, the page was recieving hundreds of thousands if not millions of hits; we protected it. Had we flagged-protected it - which we probably would have done - what would have happened? Would the system have coped? Would we have been able to handle that flood of edits, technically and organisationally?
Sincere thanks for clarifying that for me (also thanks to Chad and Anthony for useful explanations).
"Tech-speak" can be mildly confusing for us who may not fully always appreciate the very narrow definitions some terms in it have. I expect for some folks "lawyer-speak" is very much the same.
Indeed I fully agree that ensuring that using the extension on massively edited pages is something that works fine, is entirely prudent; whereas ensuring perfect functionality for the full force of the extension for application on all English wikipedia pages, is probably less so.
Yours,
Jussi-Ville Heiskanen
"Jussi-Ville Heiskanen" cimonavaro@gmail.com wrote in message news:4AC226E2.7010203@gmail.com...
Indeed I fully agree that ensuring that using the extension on massively edited pages is something that works fine, is entirely prudent; whereas ensuring perfect functionality for the full force of the extension for application on all English wikipedia pages, is probably less so.
It's not just that. On a technological level, considerable sections of the FlaggedRevs code are called on *every* page view, whether the page has FlaggedRevs behaviour or not. Even if it's eventually saying "no, carry on normally" in 99% of the cases, the question is still asked. And asked on every one of those six billion pageviews. When the answer is "yes, we need to do something special here", of course, the load that the FlaggedRevs extension applies to the servers increases further, but every extension installed affects performance on every pageview, to a greater or lesser degree. In the case of the site that carries such a huge proportion of our load *anyway*, "lesser" is definitely the degree to aim for.
--HM
On Fri, Oct 9, 2009 at 7:03 PM, Happy-melon happy-melon@live.com wrote: [snip]
It's not just that. On a technological level, considerable sections of the FlaggedRevs code are called on *every* page view, whether the page has FlaggedRevs behaviour or not. Even if it's eventually saying "no, carry on normally" in 99% of the cases, the question is still asked. And asked on every one of those six billion pageviews. When the answer is "yes, we need to do something special here", of course, the load that the FlaggedRevs
Completely hogwash.
The overwhelming majority of those "six billion pageviews" never touches mediawiki at all— they're satisfied out of the frontend caches.
Not that flaggedrevs doesn't have performance considerations, but you'd do well to keep the hyperbole down a notch.
...and it's not like we're talking about some extension which was only ever designed for tiny wikis (as many extensions are), dewp and enwp were always primary targets for this extension from inception.
On Fri, Oct 9, 2009 at 7:22 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Fri, Oct 9, 2009 at 7:03 PM, Happy-melon happy-melon@live.com wrote: [snip]
It's not just that. On a technological level, considerable sections of the FlaggedRevs code are called on *every* page view, whether the page has FlaggedRevs behaviour or not. Even if it's eventually saying "no, carry on normally" in 99% of the cases, the question is still asked. And asked on every one of those six billion pageviews. When the answer is "yes, we need to do something special here", of course, the load that the FlaggedRevs
Completely hogwash.
The overwhelming majority of those "six billion pageviews" never touches mediawiki at all— they're satisfied out of the frontend caches.
That's what I was thinking. FlaggedRevs works with the caching software, to invalidate pages properly, right?
In theory, if the extension is written right, it could even enhance performance, since the public version of articles will change less often, and therefore be cached more often.
That is something that needs to be tested, of course.
-------------------------------------------------- From: "Gregory Maxwell" gmaxwell@gmail.com Sent: Saturday, October 10, 2009 12:22 AM To: "Happy-melon" happy-melon@live.com; "Wikimedia Foundation Mailing List" foundation-l@lists.wikimedia.org Subject: Re: [Foundation-l] Status of flagged protection (flagged revisions) for English Wikipedia.
On Fri, Oct 9, 2009 at 7:03 PM, Happy-melon happy-melon@live.com wrote: [snip]
It's not just that. On a technological level, considerable sections of the FlaggedRevs code are called on *every* page view, whether the page has FlaggedRevs behaviour or not. Even if it's eventually saying "no, carry on normally" in 99% of the cases, the question is still asked. And asked on every one of those six billion pageviews. When the answer is "yes, we need to do something special here", of course, the load that the FlaggedRevs
The overwhelming majority of those "six billion pageviews" never touches mediawiki at all— they're satisfied out of the frontend caches.
Yes, that is true, and I had neglected that point. The squid infrastructure was implemented precisely to save the Apache servers from five of those six billion. Or whatever the number is.
Completely hogwash.
Not sure I'd go that far. My point was that every time a page is rendered, extension code adds load, whether or not the extension's behaviour is apparent on that page. Are you saying that that, too, is pure hyperbole?
...and it's not like we're talking about some extension which was only ever designed for tiny wikis (as many extensions are), dewp and enwp were always primary targets for this extension from inception.
Indeed. Your point?
--HM
wikimedia-l@lists.wikimedia.org