Thank you very much for this message. I fully admit that I may have missed it somewhere along the way, but I appreciate the succinct reasoning. I did go back and look at this is way at the bottom of the "why we need money" page, but I appreciate you posting about it here.
----- Original Message ----
From: Anthere <Anthere9(a)yahoo.com>
Beg your pardon ?
Financial statements go from june to june. So, "new" is at least 7
7 months ago, we had a "cash at the end of the year" of 500 000 dollars.
Our auditors recommanded to increase cash reserve to at least 3
($875,000), preferrably 6 months ($1,650,000) of operating expenses for
In june 2006, we were NOT overfunded, we were precisely within security
limits, with something like 3 to 6 months of operations in reserve.
Right now, we are VERY underfunded.
foundation-l mailing list
We on the Dutch Wikipedia have a problem since a month or two: we work
with the marked as patrolled system and normally this works fine, but
since a few months there are some anonymous changes who are bad, but are
marked as patrolled. We don't know what causes this problem, (a vandal,
an ignorant user, just some mistakes?) but we would like to find it out.
In order to do that we must know who marked which changes, so it would
be great if we could see this. In short: we want some sort of "recent
marked" list and a link in the difference page to the person who marked
a change. Is this easy to implent in a short time?
Thanks in advance,
Brion vibber wrote:
> Individual paragraphs, table cells, etc would be an even nicer
> fine-grained level to do inline editing on, but this requires having a
> reliable way to associate parts of rendered output with the parts of
> source code which created them.
I'm aware of these difficulties. There are a number of ways I can see this
being tackled. Firstly, only pure wikitext can be edited inline. That is, if
you try to edit some text which is the result of 2 #switch's inside 6 nested
templates being transcluded through 2 articles, then there's just no option
to edit inline. Either that, or attempting to edit that part inline sends
you to an appropriate edit page - either for the article, the template, the
nested template, etc - more difficult.
But focussing on the easy stuff: inline editing on a page with nothing but
nice, pure, transclusion-less wikitext, I don't see this as being so hard.
Obviously the renderer renders the code for inline editing into the output,
so there wouldn't be a correspondence issue.
For instance: for every paragraph, or the contents of every table cell, the
renderer can output some funky code that allows inline editing on that part.
This funky code is ultimately a function with inputs for two numbers that
define a range of characters in the wikitext that will be replaced by the
result of the inline editing. The renderer obviously renders these numbers
into the output as constants when it parses the wikitext.
Just another thought that came up with me today:
What about an auction. I dont know whether there is interesting stuff enough
to collect, and I dont expect thousends of dollars out of it, but wouldn't
it be fun for the community to have something like an auction? People can
give stuff that could be "cool to have" for the auction, to the foundation,
and the person that bids the highest amount of money, can get the thing. For
instance, I would be thinking of a postcard witht he signatures of all
boardmembers, a used cigarette of oscar (no, not really, please come up with
something more fun! :P ) or maybe even approach famous people to donate
something that belongs to them for this cause. The stuff can varie to
everything, but should be intensively prepared probably.
Would this be fun for the community? Would it be creating some money to the
foundation, would it be worth while? Are there maybe more ideas in this
trend, that together get a meaningfull amount of money together?
I understand of course it wont be possible anymore for this very
fundraising, but I think it would be an idea for the next one. I'm not sure
whether the foundation should "lower" itself to this level, or maybe it
explicitely *should*. Please shoot! :)
2007/1/6, Peter van Londen <londenp(a)gmail.com>:
> Waerth I would appreciate if you could stay with the subject, which is
> alternative funding of Wikimedia projects by a add-driven fanpedia. The
> fanpedia was brought up some days ago (and not reoccurring every two
> There are definitely more people than you mention; might not be the most,
> I have written, because most people on nl-wp don't care about how the
> projects are being funded. I wished that you had commented on the subject,
> in stead of flaming.
> I would like some comments about the feasibility of doing such a project.
> give up "add-freeness" for one project so that the other projects can be
> funded add-free. Is that compatible with the Mission/Vision? Are there
> points: like for instance legal liabilities as of the probable nature of
> content on a Fanpedia?
> Robert Scott Horning: I don't know Wikia, so I don't have any idea of a
> fanpedia under the wings of the Wikimedia Foundation would conflict with
> Wikia's interests or vice versa. Anyhow by transporting content to Wikia
> does not help much with funding of the Wikimedia Foundation, if I
> that correctly.
> SJKlein: any comments why you don't think it is a good idea?
> A lot of people involved in Wikipedia don't like adds or even sponsoring
> a sitenotice mentions the name of logo of the sponsor. We could keep
> advertising away of the "more-serious" project if we had an add-driven
> sisterproject. (It doesn't have to be a fanpedia, it can be a different
> project, but fancruft is popular!). It would be a compromise.
> Kind regards
> 2007/1/6, Walter van Kalken <walter(a)vankalken.net>:
> > >
> > >The thing is that a lot of people work on the fancruft, imho
> > >non-encyclopedian, part of Wikipedia and that is OK. Prison Break is
> > of
> > >the most visited articles on dutch Wikipedia. Most nl-Wikipedians are
> > uneasy with this kind of articles, which evoluate to a encyclopedia
> > the wikipedia in itself, and would be happy to move them to a different
> > project.
> > >
> > Most ?????? That is a very bold statement. I would say a minority.
> > Currently in the Dutch wikipedia it is only 4 or 5 people who bring this
> > up every 2 weeks or so. Including you. That is definately not most
> > wikipedians!!!
> > Waerth
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l(a)lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/foundation-l
> foundation-l mailing list
Peter van Londen wrote:
> GerardM and community
> I do agree with your view. I also think that lack of funds is a serious
> issue and I don't thank the opposition to have achieved not doing more
> matching donations this fundraiser.
> I do disagree with you that there is no serious alternative. There is
> and it
> is brought up in a separate thread by Teun Spaans (
> It is a separate project aimed at publishing fanstuff with adds (which is
> now part a popular part of every Wikipedia), so that the other
> projects can
> do without adds and we still have money to fund all projects and indeed
> expand on some further ideas.
> I don't understand that not more persons seem to be willing to judge
> on this
> idea? I don't care if thorough consideration will have a negative
> if there would be enough reason no to have a Fanpedia, but it is an
> alternative!! And until know it seems to be discarded. Please think
> about it
> and comment on that idea, it is worth considering. It seems that Wikia is
> doing good with this way of funding.
Well, the original suggestion didn't seem to think that the "fanstuff"
is currently being discarded, it indicated that a lot of what we
currently have is "fancruft" and could be moved elsewhere with ads
placed on it. But either way, all this does is get into the problem that
one person's junk is another person's treasure. Imagine how this could
skew an Articles for Deletion process - not only is this stuff we need
to get rid of, we're passing up an opportunity to make money off of it.
Taken to its logical conclusion, the consequence of this idea is that
Wikimedia projects *should* have advertising, and that the advertising
should be used specifically to improve the content. And a very simple
solution presents itself. Anything that is tagged as being disputed,
controversial, needing cleanup, unsourced, original research, vanity, or
a host of other problems - using one of the many such templates on the
English Wikipedia, for example - automatically gets advertising space
added along with the tag. (I'd even include libelous and
copyright-infringing material, except that making money directly from
illegal content would significantly change the potential for liability.)
Furthermore, we no longer need to worry about advertising compromising
the quality of our content, because we're only putting it in places
where it's already compromised.
Once the content is fully compliant with our policies, the advertising
is then removed. The absence of advertising would be the indication that
the quality has been reviewed and meets our standards. In fact, we can
even stop trying to come up with the long-awaited revision-flagging
feature, since we'd already have solved the problem it's designed to
Turning garbage into gold has been a fantasy since the alchemists.
There's a reason it's a fantasy.
On 07/01/07, Gordon Joly <gordon.joly(a)pobox.com> wrote:
> I have had one request from a wiki I run for a local history group -
> a spell checker. Everything else they like (the group had TWiki
> experience from another project).
Does the red-wiggly-underliner in Firefox 2 do any good here?
To follow up some of the replies:
I'm not suggesting WYSIWYG. I don't like Wysiwyg personnally, I think it
makes content editing more difficult and less clear.
My point in its simplest form was that there ARE ways of doing VERY funky
stuff. And I don't mean flashing animations, I mean stuff that actually
makes MediaWiki run better, be easier to use, attract more users, etc.
Compatibility isn't that much of an issue because:
* The features can be opt-in via user preferences (could even be as simple
as selecting one of 3 modes, or something)
* This kind of funky stuff IS actually very stable, and can even detect the
browser it's being viewed in and turn itself off.
* Most people CAN run it without problems.
For the Somalians without Dell Dimensions, (interesting example!) there's
always the normal Wikipedia (before turning on these options), CDs, DVDs and
If lack of developers and money is the only problem then why not be more
WIKI about it? Call to the Wikimedian community for volunteer coders to help
improve MediaWiki. Of course this is a lot more complex than I make it
sound, but the point is that somewhere out there will be a professional AJAX
coder willing to code free for Wikimedia. I know that if I knew the
language, I'd do it.
Why is MediaWiki so low-tech?
I understand the imperitive for maximal accessibility, but is it not also
true that, these days, fewer and fewer people are using browsers that can't
handle advanced features? The fact of the matter is that a website's
*usability* is improved by taking advantage of the higher-tech architecture
that modern browsers allow you to use. Can't MediaWiki default to its
current state, but offer a per-user preference to turn on advanced options?
Look at a site like Facebook, (http://www.facebook.com), for example, which
is possibly one of the most beautifully constructed websites I have ever
encountered. It is simple in layout and ridiculously easy to use on account
of very good design, and the use of advanced code generating popups,
immediate editing, etc. Furthermore their code is pristine; I have never
seen an error, even in the advanced features, on any browser.
The kind of MediaWiki advanced features I'm talking about could be something
like instant editing. Think about if you're reading a long section of an
article, and midway down there's a spelling error. There are so many reasons
to not fix it: you'd have to scroll up to click the edit link on that
section, you'd have to wait for it to load, you'd have to find the place
again in the edit box, you'd have to wait for it to load again, and all this
time you won't be able to continue reading your article, and you'll have
lost your place. What if you could just click next to the relevant
paragraph, turning it into an edit box on the same page - no loading - edit
it, save it, and never once have to switch page. Something similar to the
way you can edit posts in vBulletin without having to change pages. I know
for sure that a feature like this would double the speed at which (and the
likelihood of which) articles are improved.
Obviously once you accept the usage of advanced elements like this there's
no stopping how much easier you can make the site, and how user friendly. If
the only grounds to not include this kind of feature are accessibility, just
put each feature on a switch in user preferences.
> I've translated it in french so more people can read, it wouldn't be
> bad to translate this email in the more language we can and spred it
> on village pump.
Why not making a new issue of Quarto with this letter, the financial
report, the draft of the provisional budget for 2007