Wikimedia Foundation elections/Board elections/2009/Candidates/Questions/2
Foundation Endowment
edit
What are your thoughts about the establishment of an endowment for the Foundation? More specifically: (i) How should establishment of an endowment be traded off against shorter-term objectives? (ii) What size endowment should be targetted? (iii) What operations should be supported by distributions from the endowment, and why? Jeremy Tobacman 21:59, 29 July 2009 (UTC)
Also, we're still quite agile organization, which may scale down certain projects in case of financial problems. We are in somewhat uncharted lands, and endowment would commit us to certain way of financial planning way too early.
Of course, we may consider endowment as restricted funding option - if any grant makers are ready to switch from institutional funding to endowment building.An unfortunate but true side-effect of having a large endowment (no giggling, children) is that the WMF may be criticized for having one, or too large of one. Annual giving could erode if too many potential donors begin to view the endowment as alleviating the need for more funds. Smaller non-profits (like Wikimedia) are often criticized for not spending the lion's share of funds on current needs. Grant-making organizations might even pass over an organization that already has significant endowment capital.
Apologies for sounding like a broken record, but the Wikimedia Foundation needs to stop practices like underspending the Technology budget by 65%, and dealing Stanton Fund gift money directly to the privately-held company (Wikia, Inc.) of the Foundation's founding trustee, before it even dares consider launching an endowment fund campaign!An another intermediary step that can be taken right now, is to regularize the handling of the current financial cushioning strategy. It clearly was impossible in the previous term or the one before that, and it won't be implementable in the current accounting term either, because of the explosive growth of the size of our operations in terms of staff and office space. But once the move to an alternative location in SF is out of the way in terms of one time financial outlay; I think it only prudent that there is a clear strategy on how the cushion is handled. This would be prudent in itself, and since hopefully it would be a strategy that can be publicly expressed, as a completely serendipitous bonus, it should alleviate all the unnecessary foaming of the mouth from our more excitable critics :-) If that is ever possible :-/
To be clear, my feeling is that an endowment is useful if and only if the amount of money coming in as donations is an order of magnitude larger than currently. Specifically it would be useful if there was a sudden donation of an order of magnitude beyond our current revenues. It is conceivable that we might be able to grow in easy stages into a size where our revenues are even several orders of magnitude larger than currently before an endowment would be near inescapable. I have to say that in terms of future planning, when and if our revenues continue growing, it would be wise to begin the endowment sooner than it is absolutely indispensible, to give it time to grow.
It will be a glorious day when we are in a situation where all the money to run the servers can be scraped off the interest on the endowment. May I live to see that day!I'll share a few thoughts on why. First of all, the main reason for an endowment is to increase stability (and the impression of stability). We don't require an endowment to assure people that we will be around for the long term; instead we make it possible for someone with the available resources to take everything we have and start over. If we for some reason ran out of money, the project wouldn't die out.
We're also not attracting the sorts of gifts that would fund an endowment. Our large gifts are mainly from foundations who are giving funds expecting it to be spent, not from individuals, and I don't expect this to change. Wikimedia does not get many major individual donors (the exceptions are very much appreciated). We don't have gala events or naming opportunities (no, no one is interested in naming rights to servers; people just look at us funny). Major donors do not routinely get board seats. No one yet has left an estate to Wikimedia. Building up the kind of fundraising strategy to build an endowment would be very different than what we are doing now.
If we were to be getting individual gifts of large sums of money at once, then I would say we should be working on this. It is a thought to keep in mind and something to talk about with potential major donors, but for now it is not a priority for me.Yes, we need an endowment fund, and should set one up now, even before we have planned a fundraiser for it (see i.). An endowment is essential to safeguard the future of any long-lived institution. Our annual budget is now many times our basic operating expenses, with over $8M a year in recurring expenses in the current 2009-2010 financial plan (for comparison, $8M is roughly the annual upkeep of the Clinton Presidential Library). Moreover, the plan calls for Foundation spending next year to grow faster than revenue - this is short-term planning. We must prepare for the long term at the same time.
- (i) - Some donors, particularly larger individual donors, may give to an endowment what they would not to a general fund. The endowment should be supported through careful outreach to large donors, and through policies allocating a portion of major unrestricted gifts to the endowment. The greatest investment required to set up an endowment is the definition of what it would support, something that we must do regardless as part of strategic planning. (Some people have questioned whether grantors would give money to an organization with an endowment. Most grants are project based, and not for general planning or support - Universities and other entities with large endowments receive some of the largest grants in the world.)
- (ii) - This is a topic for discussion with the Foundation's finance team. The endowment should be large enough to sustainably support the basic operation of the Projects (see iii. below), able to grow with inflation while supporting any needed central server farms and technical support with its interest, and of a size that we can raise. An initial target of $10M would match current expenses. One of the goals supported by the endowment would be to reduce the future maintenance cost of core services, so the endowment would not need to grow as rapidly as the projects. (While expenses have grown geometrically in years past, there has been no focus on separating core services from research, experiments, and other expenses.)
- (iii) - First we need to work together to definine a core set of services that define our mission. I would include:
- Reliable read/write access to the projects through the Wikimedia domains, and the hardware and bandwidth this requires;
- Reliable access to dumps and statistics
- Reliable backups of private and public data
- These services should be supported as robustly as possible : making it easier for third parties to help support them in-kind with their own time, money, and hardware; having someone keeping the infrastructure involved up and running - either with a dedicated team or with some other effective supporting network; maintaining and improving ways to find and access dumps, from a fileserver and mirrors to actively-seeded torrents of large files; and regularly generating statistics from available sources while protecting private data [which makes this a difficult task to let others share].
- Distributions from the endowment should support all of this, as well as efforts to reduce the future cost of maintaining them.
"Office actions" and BLP issues
edit
As a member of the Board of Trustees you would apparently have the power to take "office actions" with respect to content. Current policy states that "office actions" are edits intended "to prevent legal trouble or personal harm and should not be undone by any user." Jimbo Wales has stated that WP:OFFICE may be used in "cases involving a threat of legal action, but in other cases it may be simply as a courtesy". Would you support restricting this power to WMF's General Counsel? If not, do you see any conflict between satisfying an article subject who is complaining of "harm" and maintaining a neutral POV? How high a priority to you is "personal harm" avoidance?Bdell555 03:02, 30 July 2009 (UTC)
As a completely unrelated to the question above, but intimately entangled with the rationale I offer why consolidating the OFFICE power back into single hands would not be a good idea, I note as a sidebar that the reason that having a single Executive Director is not in violation of this doctrine is precisely because the staff is thoroughly insulated from having any influence on editing activity, apart from situations where legal matters are not in play. And that insulation should be further enhanced rather than creating a breach across it directly connected to the General Counsel.
On the separate issue of "harm"...
While I haven't had to participate in OFFICE actions, and I suspect there are very few office actions that are operated on any but some of the largest language projects, but have had to witness a few cases where there have been "complaints" of harm, libel and the like (the most bizarre perhaps being the case of a lady Video Jockey who made a complaint to the police so they could see if it was illegal to edit her article in a way that made her feel "uncomfortable"; specifically quoting catty words she had uttered in a major newspaper against another female political candidate in a race she was running in etc.) My attitude is that we should be skeptical about one-sided claims of harm. Investigating the issues behind such ought to be done with a huge amount of diligence, as interfering with the normal procedures of a project is something that shouldn't ever be lightly done, and never never never with fear or favor.Asking for a hard, bright-line rules on this is understandable but bound to lead to dissatisfaction; it's intended for exceptional situations which tend to present challenges to bright-line rules. (If Mike is out of town and unreachable, can no action be taken? No, that would be nonsensical.)
That said, of course there are competing concerns: if it were so easy to make these judgment calls, this wouldn't be a question. But they're not unique to the office; everyone who deals with articles on these topics should be aware of them. I think there are some cases in which it is appropriate for the office to act, and yes, risk personal harm is one. My opinion on what the office should do depends largely on how action by Wikimedia affects the outcome of the situation, but I trust their judgment.Wikimedia's Counsel may request such an action, but would not need to do so through the Board. Thankfully this is rarely done - it is generally an ineffective way to get things done, and an unnecessary imposition on community processes.
Yes, there is a central conflict between satisfying an article subject who is complaining of harm and maintaining a neutral POV; and it is one that community editors and OTRS respondents must cope with every day - independent of whether or not the Foundation feels an additional legal reason to respond to such a complaint.Should someone enforce Board resolutions?
edit(Should be a quick side-question.) Licensing policy is an example of policy which affects all projects. It states: «By March 23, 2008, all existing files under an unacceptable license as per the above must either be accepted under an EDP, or shall be deleted». We have a number of small projects where sysops don't know this policy and need "coaching", but some simply don't care, even when advised. Should someone delete such images? Who? --Nemo 08:56, 1 August 2009 (UTC)
- In some cases the problem is that we do not disseminate these decisions very widely, or in very many languages. To begin with, we should define an organized way to share these rare project-wide decisions with small projects in their local language.
- I would like to see a community-selected group whose role is to help small projects carry out these tasks. Stewards can do this if needed, but that is not really their role. There has been some discussion of creating a small-wiki-admin flag for such editors, and asking smaller projects to opt into this policy, similar to the opt-in global bot policy. Communities that don't opt into this could identify a place where one should post notice of new global policies, or requests for implementation.
Developers-community relationship?
editIt is my impression that the relationship between the Mediawiki developers, the system administrators and wiki communities is rather dysfunctional. It is extremely difficult for a wiki community to request even minor changes in the software, setup or locally installed extensions. Proposals that require technical changes are dead in the water. Many developers appear outright hostile towards the community and especially the English Wikipedia. Do you think there is a problem, and if so what do you want to do about it? --Apoc2400 09:43, 2 August 2009 (UTC)
Emotions aside, we try to put more and more resources to actively handling request queues, and making as easy as possible to file technical requests (ever tried bugzilla?).
Of course, the top goal for any organization is having all expectations managed and delivered, and WMF isn't anywhere close that path. It is amazing (and scary, considering what they are aiming for), that very same people who say that Foundation is a bloat, and doesn't need people to work in it, are suggesting close deadlines, and expulsions of volunteers and staff. As someone, who has been trained in ITIL (thats the "best practice for service organizations"), I sure see how we differ from the 'Real Service', but on the other hand, that has allowed us to be where we are now.
We could involve ten different managers to do triage of requests, rebuild our IT strategy over and over, so that hundreds of engineers and managers would have something to gnaw on, but we wouldn't be anywhere close to our current achievements. There always are tradeoffs - more people in staff is way more difficult to manage, and more procedures based decision making is also way less agile.
Developers have to deal with multiple communities - sometimes efficient dealing with requests has caused community uproar (some said it was consensus, some said it wasn't), sometimes telling 'no' is considered to be more hostile, than 'not saying yes', sometimes it is less hostile. The request queue that is in there has quite a lot of vague spots and problem areas - certain improvements for some people can be regressions for others - and that has to be always considered.
Our environment at the moment is the absolutely most permissive around, no any web shop is giving that much power into hands of their users - part of that because simply there is no way to do that with in-house development resources - thus leading to constant 'arms race' where developers try to keep pace with how community is using those features and resources given. Certain changes require way way more thought, than is usually included in initial discussions, and technology issues are quite often thought to be not important ("thats development issue").
So, does this problem exist? Of course, in certain cases there may be miscommunications, leading to wrong expectations. Overall, development process hasn't stalled, plenty of community requests get fulfilled, new stuff gets developed, old is still up and running. One can just look at our bugs/features tracker, and see that it isn't "dead in the water", nor "difficult to request". Foundation should always ensure, that it does best job to handle those needs, and adjust resources it has for that - but as that costs money and requires time (no sudden engineering team growths bring the desired outcome too fast), we have to assume good faith instead of hostility.This is ludicrous. Flagged revisions should have been mandated by the Board in 2007 or so, and implemented within 60 days of the Board's decree. Any paid developer who dragged their feet on such an important improvement to Wikimedia projects should have been fired, and any non-paid developer who delayed implementation should have been shunned.
I hope that I have made myself clear enough, without it sounding like a rant. Without trying to point blame at any developers, it is painfully obvious to me that they have not been professionally-enough guided by senior management. I don't blame "the community" for this dysfunction.- "Many developers appear outright hostile towards the community and especially the English Wikipedia." - I point blank refuse to acknowledge this as an accurate representation of reality, without some evidence. This is certainly not something I have experienced.
- "It is extremely difficult for a wiki community to request even minor changes in the software, setup or locally installed extensions." - Again, I would have to question the accuracy of this statement. My experience has been quite different.
- "Do you think there is a problem, and if so what do you want to do about it?" - Well it is definitely a problem that you have an impression of dysfunctionality. I think I would like to know more about what led you to that impression, to get a better handle on whether there is any reality basis for your impressions.
- One very very very *important* thing is that people who wish for the developers or "system administrators" to act as _imposing_ a solution where the community has failed to internally reach a consensus, is something that is quite dangerous, and if your perception of developers being "hasty" or "hostile" is due to this feature of their way of acting, it is in fact important to note that developers forcing things through is never a good idea, except when there are real dangers to the integrity of the site.
As the Foundation employs core Mediawiki developers and helps guide its roadmap of most essential features, it should actively clarify that it is not creating bottlenecks to independent community work. Developers in every community should feel they have support to develop tools to meet their own needs. The availability of toolservers has been a good step in this direction. The rest of the issue you raise is something for the community to address, but I am happy to share my thoughts.
There is often a communication breakdown between identifying a problem, proposing a technical solution, and seeing it to completion. I would like to see
- good models for organizing local priorities and improving them over time.
- a mechanism simpler and more general than bugzilla for defining technical needs and drawing attention to them (with one or more bugzilla tickets opened for each such need; but sometimes it is not clear what the specific ticket should look like, and widespread discussion and clustering of these discussions is essential)
- community facilitators who can find issues that local groups (editors and developers) think are important, help move them to a resolution, and raise awareness about them when needed (I support something like this on the English Wikipedia).
Worst mistake made by WMF?
editIn your estimation, over the past 24 months, what has been the most urgent or catastrophic error, mistake, or miscalculation that you feel the Wikimedia Foundation has committed? This may apply to the Board, the Staff, or both. Feel free to briefly list all of the mistakes that may come to your mind, but please focus the most attention on what you perceive to be the worst of the batch. -- Thekohser 17:17, 4 August 2009 (UTC)
Another awesome feature of our workings is how resiliently even that plan was adapted to deal with the facts on the ground. Things were slowed down and there was after the fact consultation. There is a great and wonderful self-correcting nature to this whole thing we are involved with.
The results of that restructuring are still not clear, but I have abiding faith that the structure can be ever adjusted to deal with any percieved shortcomings.
I could write a lot about what I thought was the deeper backround of the decision, that caused it to be such a spectacular flop, but it genuinely serves no purpose to dwell on the past. We must concentrate on what to fix in the future.Charitable status
editAt least one of the candidates has tried to use legal means to have the Foundation's charitable status rescinded. What is your view of the Foundation's charitable status - should it continue, or should the Foundation become a for-profit organisation capitalising on the strength of the brands it controls? JzG 08:39, 8 August 2009 (UTC)
Should everyone have a say in the guidelines or not?
editAt present, the overwhelming majority of people have never stated their opinions on the ever changing wikipedia guidelines, which are now totally different than what they were in the early years of wikipedia, and are often used as excuse to mass delete long held articles. Would you support a general election to determine the rules of notability, and what type of articles should be kept or deleted? According to the rules, simply being on the bestsellers list doesn't make a book notable, and sometimes they are erased, while at other times people say ignore the rules and keep them. Some believe in wiping out all character articles, episodes that had millions of viewers but didn't get reviewed in mainstream media, and many other things, and usually succeed in deleting them, depending on who is around at the time to participate in the AFD, and the opinions of the closing administrator. The exact same types of articles are kept or deleted, based on who shows up to argue, it all random. The constant debates raging on the AFDs could be eliminated by a general vote, and a specific set of rules. The current system has all guidelines pages edited by whoever camps there and argues constantly, to get their way, knowing most people aren't going to spend every day in constant conflict, and will just give up and let them have their way. Dream Focus 14:51, 8 August 2009 (UTC)
There are two different approaches in this question. The first is to implement a regid rule for everything. The positive side of this is you can avoid a lot of conflicts just by pointing to the rules. The negative side is that rules are something that is very unflexible, sometimes a situation happens where a rule doesn't acquire that good, or is even contradictory to our mission. So in such cases you have either to avoid the rule, which makes rules quite useless if it happens too often or to amend the rules, to make them more precise, but also more complicated, so that at the end you have so heavy a set of rules that only a professional jurist know every detail of it. The second approach is to search for consensus through community discussions. The positive of this approach is that it is in our tradition, it is with the basics of our philosophy. The drawbacks are what you pointed out, it can be quite abitrary, and discussing the same point again and again can be very tiresome.
In general every of our projects had evolved in their history its own approaches, mostly a combination of the two solutions illustrated above. The problem must be solved in the community, it cannot be ordered from above, from the board.
Personally, as a normal community member, I usually advocate in discussions about this question for the second approach. At first I think we are community driven projects and the community, everyone in the community should have the chance to take part in discussions and decision makings. I also admit that I have personnally an aversion against very regid, unflexible rules. While our projects evolve, old rules can become less suitable. But as all these things it is always difficult to change an old rule, even if everyone see that it is outdated. And thus they tend to become some ugly conservative ideology that prevent the projects develop further.
Can one be a candidate for the WMF if they have a checkered editing history?
editA late question for the candidates, but how do each of you feel about a WMF candidate who was recently blocked on enWiki for edit warring? Can someone with such a recent block for disruptive editing be a viable candidate? 76.178.200.245 13:34, 9 August 2009 (UTC)