Many of the list regulars might remember the global sysop proposal that had
been brought up around May and June 2009. The idea ultimately fizzled,
because there was simply not enough support to actually have a global,
non-opt out sysop group. Since then, a new proposal has been drawn up, which
is currently running, that allows communities to opt-in to a global sysop
wikiset, which would allow users in the global sysop usergroup to act as
sysops only on those wikis. However, the issue with this is that no project
has actually bothered to opt-in, so the process has been dead for the better
part of a year. Meanwhile, the stewards have had to combat an increasing
amount of vandalism on the small wikis, and even though global rollbackers
can help some, blocking vandals and deleting nonsense pages ultimately
becomes the job of just a few of the active stewards.
The situation could be easily remedied if there were a global sysop group;
there are a good number of trustworthy global rollbackers who would be
excellent global sysops. I drew up a proposal to automatically opt-in "small
wikis" (as defined within the below proposal) into a global sysop wikiset.
Global sysops would have full administrator tools on those wikis, but would
use them only in response to blatant vandalism. Please take a look at the
third link and give your opinions about the proposal on the talk page.
2008 Proposal: http://meta.wikimedia.org/wiki/Global_sysops_(2008_proposal)
Current process (opt-in), inactive:
http://meta.wikimedia.org/wiki/Global_sysops
Opt-out proposal:
http://meta.wikimedia.org/wiki/Global_sysops/opt-out_proposal
----
User:NuclearWarfare on all WMF wikis
I propose the foundation-announce-l mailing list be set up with the
following posting rules:
1) One post per person per thread. That includes the initiator of the
thread.
2) Responses in a thread must be in response to the original message. No
responding to responses.
4) A person may initiate a maximum of two threads per week. Exception for
foundation staff, board members, list administrator(s), and with permission
of the list administrator(s). Responses per week are unlimited subject to
rules 1 and 2.
5) Posts generally do not go through a moderation queue. Anyone breaking
the rules will be put on moderation or unsubscribed at the discretion of the
list administrator(s).
Thomas Dalton asked:
"Has tech money been spent on other things previously? That is news to me."
For your edification, Thomas, since at least you seem willing to listen, as
opposed to some others here who simply "tut tut" at all the "trolling" and
the "time wasting" any critics might have to offer:
http://philanthropy.com/giveandtake/article/858/wikipedias-fund-raising-suc…
Please make sure to read my comment there, which references this document:
http://wikimediafoundation.org/wiki/Planned_Spending_Distribution_2007-2008
Which does not "square away" with this document, specifically Page 4:
http://upload.wikimedia.org/wikipedia/foundation/4/41/FY_2008_09_Annual_Pla…
...which says, "tech department underspending equalled 1.7m".
Anthony's not exactly being fair, though, when he sort of suggests that the
shortfall in Technology spending went instead to the Executive Director. As
far as I can tell, it went into the bank, to be spent in the FOLLOWING YEARS
on the Executive Director's need to expand staff to unprecedented levels.
Pay attention, Thomas. I've discussed this issue in many places. On the
Wikimedia-controlled places, I'm often censored or blocked, but there are
plenty of other non-WMF venues where facts can be laid out for the curious
to learn the truth:
http://www.mywikibiz.com/Top_10_Reasons_Not_to_Donate_to_Wikipedia
Greg
Recently, I reported on a simple study of how likely one was to
encounter recent vandalism in Wikipedia based on selecting articles at
random and using revert behavior as a proxy for recent vandalism.
http://lists.wikimedia.org/pipermail/foundation-l/2009-August/054171.html
One of the key limitations of that work was that it was looking at
articles selected at random from the pool of all existing page titles.
That approach was of the most immediate interest to me, but it didn't
directly address the likelihood of encountering vandalism based on the
way that Wikipedia is actually used because the selection of articles
that people choose to visit is highly non-random.
I've now redone that analysis with a crude traffic based weighting.
For traffic information I used the same data stream used by
http://stats.grok.se. That data is recorded hourly. For simplicity I
chose 20 hours at random from the last eight months and averaged those
together to get a rough picture of the relative prominence of pages.
I then chose a selection of 30000 articles at random with their
probability of selection proportional to the traffic they received,
and repeated the prior analysis previously described. (Note that this
has the effect of treating the prominence of each page as a constant
over time. In practice we know some pages rise to prominence while
other fall down, but I am assuming the average pattern is still a good
enough approximation to be useful.)
>From this sample I found 5,955,236 revert events in 38,096,653 edits.
This is an increase of 29 times in edit frequency and 58 times the
number of revert events that were found from a uniform sampling of
pages. I suspect it surprises no one that highly trafficked pages are
edited more often and subject to more vandalism than the average page,
though it might not have been obvious that the the ratio of reverts to
normal edits is also increased over more obscure pages.
As before, the revert time distribution has a very long tail, though
as predicted the times are generally reduced when traffic weighting is
applied. In the traffic weighted sample, the median time to revert is
3.4 minutes and the mean time is 2.2 hours (compared to 6.7 minutes
and 18.2 hours with uniform weighting). Again, I think it is worth
acknowledging that having a majority of reverts occur within only a
few minutes is a strong testament to the efficiency and dedication
with which new edits are usually reviewed by the community. We could
be much worse off if most things weren't caught so quickly.
Unfortunately, in comparing the current analysis to the previous one,
the faster response time is essentially being overwhelmed by the much
larger number of vandalism occurrences. The net result is that
averaged over the whole history of Wikipedia a visitor would be
expected to receive a recently degraded article version during about
1.1% of requests (compared to ~0.37% in the uniform weighting
estimate). The last six months averaged a slightly higher 1.3% (1 in
80 requests). As before, most of the degraded content that people are
likely to actually encounter is coming from the subset of things that
get by the initial monitors and survive for a long time. Among edits
that are eventually reverted the longest lasting 5% of bad content
(those edits taking > 7.2 hours to revert) is responsible for 78% of
the expected encounters with recently degraded material. One might
speculate that such long-lived material is more likely to reflect
subtle damage to a page rather than more obvious problems like page
blanking. I did not try to investigate this.
In my sample, the number of reverts being made to articles has
declined ~40% since a peak in late 2006. However, the mean and median
time to revert is little changed over the last two years. What little
trend exists points in the direction of slightly slower responses.
So to summarize, the results here are qualitatively similar to those
found in the previous work. However with traffic weighting we find
quantitative differences such that reverts occur much more often but
take less time to be executed. The net effect of these competing
factors is such that the bad content is more likely to be seen than
suggested by the uniform weighting.
-Robert Rohde
Hi,
Some question about lucene-search-2 binary,
1. Do I need apache's lucene library when building lucene-search-2 binary?
Or it is already included in lucene-search-2 source tree?
2. Did lucene-search-2 in wikimedia (before migration to 2.1) use the
same binary as found in sourceforge,
http://sourceforge.net/projects/lucene-search/files/ ?
3. Which version of lucene library is used to build binary found in
sourceforge and in wikimedia?
Best regards,
Anon.
2009/8/28 Delphine Ménard <notafishz(a)gmail.com>:
> Is there a live transcript/audio/video of the board session planned?
>
It's a full-conference event (see bottom of
<http://wikimania2009.wikimedia.org/wiki/Schedule>), so I'm pretty
sure it will be broadcast through the streaming site:
<http://stream.wikimedia.org.ar/>.
--
Casey Brown
Cbrown1023
Hello,
There is a Q&A session with the whole board scheduled for this
afternoon at 3:45 EST, at the end of Wikimania:
http://wikimania2009.wikimedia.org/wiki/Schedule
It will run for an hour. If you have questions to ask but are not
physically at the event, you can post questions in #wikimania on IRC.
SJ
PS - I'd like to see regular public IRC discussions and Q&As w/the
Board. We are discussing having one primarily with the new Board
members (Arne, Matt and myself) within the next few weeks.
I wonder what takes so long to upload a small data file?
http://meta.wikimedia.org/w/index.php?title=Board_elections/2009/Votes&oldi…
Let's see... August 25 minus August 12 equals nearly two weeks of delay (and
subterfuge?)...
It only took three days to post the ballots in 2008:
http://meta.wikimedia.org/w/index.php?title=Board_elections/2008/Votes/en&o…
What's different about 2009? I mean, other than the fact that the
Wikivoices interview tape #45 of the Board candidates was mysteriously
"lost", and that the WMF staff budget is about three times larger now than
it was then. This must be the professionalism and efficiency we were
expecting from all of the added money being thrown at the Foundation.
--
Gregory Kohs