Just to be clear, we are not doing fundraising earmarks for the 2010
fundraiser. As I mentioned earlier, this was discussed earlier in the
year and ruled out for the current fundraiser. Any such plan would need
thorough discussion, both with the community and the WMF. In addition,
we usually start planning our testing methodology and analytics goals 4
or 5 months ahead of the fundraiser so that development can be completed
well before the fundraiser begins. That said, I think earmarks are
definitely an idea that should be discussed for the future. Did you have
any thoughts on the objections that I listed in the previous email?
Right now the Foundation is generally opposed to the idea of fundraising
earmarks, so we would need to address those objections before we start
talking about any implementation details.
Thanks for the R links. The research and analytics people here are very
big fans of R. The links you sent look like they could be useful for us.
Ryan Kaldari
On 9/4/10 3:26 PM, James Salsman wrote:
It's great to see that donor logs are going in to
a database instead
of just a text file, but multiple regression in SQL is absurdly
difficult because of the limitations of SQL, so I still recommend R,
in particular:
http://cran.r-project.org/web/packages/RMySQL/RMySQL.pdf
and
http://wiener.math.csi.cuny.edu/Statistics/R/simpleR/stat006.html
I will ask Arthur Richards for data coding formats.
I predict that multiple response checkboxes will do better than the
more constraining radio buttons, but there is no reason that they
should not be measured as any other independent variable. It is
probably a lot more important to measure the number of earmarks
offered: 0-26. There is plenty of reason to believe that showing 26
options will have a slight advantage over 25, but I can't see the test
results from the Red Cross (they measure the things which increase
donations of blood much more carefully than money, at least in their
publications that I've been able to find.) Don't forget the control
case where no donor selections are offered. Optimization requires
measurement, and it is easy to measure offering a lot of options up
front.
Do you think that variations on the disclaimer should also be tried?
I think there is reason to believe something terse might result in
more donations, e.g.: "These options are advisory only." and/or "The
Wikimedia Foundation reserves the right to override donor selections,
cancel any project, and use any funds for any purpose." and/or "All
donations are discretionary, these options are offered for polling
purposes only." or some combination. What does Mike Godwin think a
good set of disclaimers to test might be?
I conflated the proposed stimulus list down to 25 non-default items
and enumerated them with letters of the alphabet so that everyone
would understand that it is feasible to test additional proposals as
well. I have not yet surveyed the Village Pumps or mailing lists for
additional stimulatory ideas but I hope people who have or who see
anything missing will suggest at least five more. Translations would
be great, too.
(default) Use my donation where the need is greatest.
A. Auction the order of search failover links to search engine companies.
B. Broaden demographics of active editors.
C. Compensate people who submit improvements to the extent that they
are necessary and sufficient.
D. Display most popular related articles.
E. Enhance automation of project tasks.
F. Enhance site performance in underserved geographic regions.
G. Enhance visualizations of projects and their editing activity.
H. Establish journalism awards, expense accounts and compensation for
independent Wikinews reporters, fact checkers, photographers and
proofreaders.
I. Establish secure off-site backup copies.
J. Establish simple Wikipedias for beginning readers in languages
other than English.
K. Improve math formula rendering.
L. Increase the number of active editors.
M. Increase the number of articles, images, and files.
N. Increase the number of unique readers.
O. Make it easier for people to add recorded audio pronunciations.
P. Obtain expert article assessments.
Q. Obtain reader quality assessments.
R. Perform external code reviews.
S. Perform independent usability testing.
T. Produce regular snapshots and archives.
U. Retain more active editors.
V. Strengthen Wikimedia Foundation financial stability.
W. Support a thriving research community.
X. Support an easier format to write quiz questions.
Y. Support more reliable server uptime.
Z. Support offline editing.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l