Interface language selection

Language setting in user preferences

On each MediaWiki website, users who create an account can select the language of the software interface. That means, for example, that you can read Wikipedia articles in Italian, but with the interface in French. This feature is particularly useful for Wikipedia participants who are familiar with the interface in their mother tongue.

The default language for MediaWiki messages is English. The localization of MediaWiki has been made possible with the translatewiki.net platform (former “betawiki”) and the hundreds of volunteer translators who try to keep up with the ever changing MediaWiki messages. And they’re doing a terrific job.

This language setting, though, only works for registered users. If you’re only a reader and you don’t have a user account, you’re stuck with the default language specified for the website. Usually, the default interface language is the same as the content language, and most readers are content with that.

The problem comes with multilingual wikis, i.e. wikis that contain content in several languages. For example, Wikimedia Commons, Wikimedia Meta-Wiki and the Wikimedia Foundation website are multilingual wikis; they are central places for Wikimedians from all projects in all languages. Only one interface language can be used as the default, and it’s generally English. If you can’t read English and you’re looking for media files on Wikimedia Commons, you’re going to have a hard time navigating the site.

The uselang parameter

A workaround is to use the uselang parameter to specifically ask MediaWiki to render the interface in a given language.[1] An example of its use is the “Commons” template, used on some Wikimedia projects to provide a visible link to the Commons page or category about a specific topic. If you’re reading the Catalonia article on the German-language Wikipedia, and scroll to the bottom, you’ll find a link to Commons directing you to the Catalonia category on Commons, but with the interface in German.

This method has obvious drawbacks: first, you need to actually know it exists, and how to use it. You also need to know the ISO 639 code of the language, but if you know the uselang parameter exists, I’ll assume you know that language code as well.

More importantly, the uselang parameter isn’t persistent, i.e. it will go away as soon as you leave the page you were viewing. There’s an open bug to preserve the uselang parameter during sessions (bug 4125). But for now, if you land on a page rendered in a specific language using uselang, it’ll revert to the default language as soon as you move away from that page.

LanguageSelector extension for MediaWiki

Going a bit further, Daniel Kinzler developed an extension for MediaWiki called LanguageSelector. The first feature it provides is to automatically detect the browser language[2] of unregistered readers and defaults the interface to their language.

Such an automatic system would be desirable for some Wikimedia websites, especially Commons, but it requires scalability improvements: it would fragment the cache, on which we rely heavily for performance. Nonetheless, it’s an issue that’ll have to be addressed in any case.

The LanguageSelector extension also provides a drop-down selector that can be included in pages. This setting seems to follow the user at least during the session. You can see an example of it used on the home page of translatewiki.net.

Content language selection on monolingual wikis

Wikipedia.org portal

Wikipedia and most other Wikimedia websites are available in many different languages — over 250 at the time of writing. And that’s just existing Wikipedia editions; several thousand languages are spoken across the world population.

On monolingual wikis (i.e. wikis whose content is in only one language), there are two occasions where you may want to select a language: the first is when you choose what site you want to visit, e.g. Wikipedia in English or Wikipedia in Spanish. The second occasion is when you want to navigate from one language edition to another, e.g. from Wikipedia in English to Wikipedia in Spanish.

On Wikipedia, the first choice happens on the multilingual wikipedia.org portal, if you ever happen to go there.

On this (manually curated) portal, each language is displayed in the language’s language:[3] English is displayed as “English,” German as “Deutsch,” French as “Français,” etc. The sorting order is based on the size of each language edition, measured in number of articles. In a word, the bigger the Wikipedia, the more prominent the place. “Small” Wikipedia editions are at the very end of the list.

In most cases, though, you don’t have to make this choice; your search engine conveniently directs you to the language edition of Wikipedia in your language. Once you are on a specific language edition of Wikipedia, though, you can still navigate to related articles in other languages, using interlanguage links.

Interlanguage links

Interlanguage links are a specific subset of interwiki links; they allow users to navigate between different language versions of the same page. Links and their order are curated by humans or “bots,” i.e. external programs that interact with the software as humans would, but are not part of the MediaWiki software

The sorting order differs from a Wikipedia to another; they have different standards. That means interlanguage links will be sorted in a different order, whether you’re reading an article on the Polish Wikipedia, the Finnish Wikipedia, or the Serbian Wikipedia. Convenient, eh?

The default behavior for interlanguage links is to display all the available links. For the most common topics, the list can grow quite long. The main page, for example, is the page all language editions are sure to have in common. The interlanguage list for the main page is usually truncated by Javascript in order to avoid having 250 links there.

Content language selection on multilingual wikis

JavaScript language select tool

For a few years, meta has been experimenting with the Language select tool. Language select is a JavaScript hack[4] that basically hides the text that isn’t in the language you’ve selected.

There too, you have to know the ISO language code, and the user interface isn’t very intuitive, but it was a start. The newer JavaScript method detects the language of your browser automatically.

A similar system is also available on Commons, through the `Multilingual description <http://commons.wikimedia.org/wiki/Template:Multilingual_description>`__ template. As far as I know, though, this template is very rarely used; instead, individual language templates are the standard way of labeling (and sometimes, choosing) content in different languages.

Language templates

Language templates are used to specify the language of a specific part of a content’s page, for example descriptions of a picture on Commons. They also allow registered users to hide content they don’t understand, by specifying a “blacklist” of languages they don’t want to display. It’s particularly useful for Featured pictures, or Pictures of the Day, that contain many translations for the caption.

Conclusion

There is a multitude of cases where a user may want or come to select a language while navigating a Wikimedia site. They may want to choose in what language the website interface will be displayed, or select the language of the content.

For multilingual Wikimedia wikis like Commons and meta, language selection is a regular issue, because they intrinsically target a multilingual audience. Some ad-hoc systems have been developed over time to try and work around the technical limitations of MediaWiki, but they can’t replace a built-in language management system.

Current language selection solutions also don’t cater for the needs or unregistered readers, who are the majority of the people visiting Wikimedia projects. That issue will have to be addressed at some point if we want to reach a truly global audience.

Another challenge with language selection is the interface you provide the user with to make their choice, i.e. the actual “selector.” It is not obvious what design is the best and allows the user to select the language they want in the most efficient manner. This will be the topic of my next article, about language selectors.

Content and community growth

There has been much interest in the academic world about “Who writes Wikipedia?” and whether most of the content is contributed by an elite group of participants or by occasional visitors.[1][2] Roth et al. studied the factors influencing wiki viability and noted a “dynamical intertwinement of population and content growth;”[3] they had earlier suggested that a wiki’s success was linked to “a virtuous demographic path with content and contributors co-evolving.”[4]

In a media repository like Wikimedia Commons, however, the focus of activity is on contributing new media files, rather than improving the existing ones. Once a file has been uploaded, improvements are mostly limited to metadata and peripheral information (description of the media file, copyright information, general topics, location, etc.); the files themselves are rarely edited. As a consequence, it is particularly interesting to study the dynamics of population & content in this special case. For this purpose, I studied the temporal evolution of the Files-to-active Participants ratio (F:P) and compared it to the Articles-to-active Participants (A:P) ratio on the English Wikipedia (Fig. 1, below). All the data come from stats.wikimedia.org.

While the articles-to-participants ratio has remained stable on Wikipedia after the first few years of existence, the files-to-participants ratio has been steadily increasing since the creation of Wikimedia Commons. F:P has exceeded A:P since then and is now ten times higher than A:P. This demonstrates that Wikimedia Commons, despite being successful in terms of content, does not follow the usual model of “viable” or “successful” wikis, and requires new metrics and new models.

Content inflow management

Because of the fundamental difference between a text-based encyclopedia and a media repository, a more interesting approach is to compare the capacity of the community of participants to “absorb” the inflow of new content contributed to the platform. Thus, I studied the temporal evolution of the ratio of persistent new media files uploaded each month, per very active participants on Wikimedia Commons (Fig. 2).

I compared it to the ratio of persistent new articles per very active participants on the English-language Wikipedia. “Persistent” means that I only counted media files and articles that were not deleted during the patrolling process; the actual number of files uploaded and articles created is higher. I chose to consider only very active participants (more than 100 edits per month) since they are the more likely participants to engage into patrolling activities, such as checking newly uploaded files or newly created pages.

The ratio of persistent new media files per very active participants has doubled since the creation of Wikimedia Commons and still continues to increase. This ratio is now more than ten times higher than the one for articles on the English-language Wikipedia. Because of this imbalance between the growth of the content and the growth of the community, Wikimedia Commons faces a peculiar challenge.

Using appropriate tools

Some may argue that comparing uploads and the creation of new pages is like comparing apples and oranges; I agree to some extent. For this reason, I have also studied the evolution of the number of edits on the English Wikipedia, which may be a better indicator of the inflow the community has to absorb. This will be the subject of an upcoming article.

The MediaWiki software provides various maintenance and patrolling tools that allow participants to check newly contributed content; one of these tools is the “watchlist”, a personal page listing the recent changes made to pages of interest selected by each participant. Watchlists are appropriate for text-based wikis like Wikipedia where participants want to check new edits to existing pages, rather than new pages.

However, maintenance activities on Wikimedia Commons mainly consist of checking new files (especially their copyright status) and classifying them appropriately. For this purpose, the usefulness of the watchlist is limited. Some ad-hoc tools have been developed by power participants, but MediaWiki does not provide dedicated features to help the limited community of participants absorb the inflow of new media files. This is where the Multimedia Usability project can step in.

Software lifecycle & Project management

Right now, there is little project management of the technical activities at the Foundation. When someone does manage projects, they often use personal desktop applications that don’t allow collaborative work. There isn’t any real development roadmap or product requirements. If we want to be serious about structuring our activities, we need a project management strategy & the appropriate associated tools that allow us to manage things such as project scope, schedule, budget & financial resources, quality assurance, human resources, communications, risks & opportunities, procurement and coordination.

I asked around to see what the needs of the various members of the team were. Naoko Komura, who has been project-managing the Wikipedia Usability Initiative, and is now overseeing all UX programs, is particularly interested in the integration of the Project management platform with calendars & issue tracking. Operations staff members also said they were interested in Project management features such as time and task tracking.

I think it is way past time to have a more organized development process & software lifecycle management. The recent hiring of a new Chief Technical Officer is a step towards a more structured organization of technological activities. Of course, changing our bug tracker alone won’t automatically structure our activities, but it is a step in this direction.

Recommendation: Use tools that allow a better management of, and integration between, the different stages in our product(s) lifecycle.

Requirements

A few months ago, I asked Priyanka Dhanda (our new Code maintenance engineer) to explore open-source collaborative project management platforms that could be easily integrated with bugzilla (or that included a bug tracking system of their own). The Wikimedia tech community was invited to list requirements of such a tool, as well as possible solutions.

From the feedback we received, we can summarize what the required features for an issue tracker are: integration with our Version control system, being FLOSS, multiple projects support and ability to separate between “tasks” and other items such as bugs and feature requests. Additional, “nice to have” features include: ability to import data from existing Bugzilla instance and fined-grained e-mail subscription options

Similarly, the required features for a Project management tool are: being web-based to facilitate collaboration, multiple projects support, calendar/scheduling and roadmap, assignments & resource management and time tracking per task/user/project. Additional, “nice to have” features include: Gantt charts, public/private projects, fine-grained access to projects by user, basic accounting & budget management and requirements management.

Redmine

I haven’t found many Project management softwares that can be easily integrated with Bugzilla. However, I have discovered alternatives to Bugzilla that include project management features like those we’re looking for. Redmine seems to be a good project management software and provides an advanced issue tracking system as well. It supports multiple projects, public/private projects, calendars & Gantt chart, and a lot of other neat stuff.

It also offers the ability to distinguish between features/improvements and bugs; this would be particularly useful to prioritize development efforts. We are now considering using Redmine as project management software and taking this opportunity to move our Bugzilla setup to Redmine. Initial research shows that a lot of people seem to praise Redmine compared to Bugzilla; there are migration scripts to import an existing Bugzilla setup into a new Redmine one.

Major projects such as TYPO3 are using Redmine. The software seems to benefit from a dynamic community of developers and it is also possible to sponsor custom development. There are many plug-ins to extend the default core features; popular plug-ins are usually included into the core software at some point.

Priyanka set up a local test instance of Redmine to let us play with it a bit; a public test platform was later made available for wider testing and the Wikimedia Tech community was invited to pitch in. So far, I personally like it and it fits my needs perfectly. Wider testing is now necessary to see if it fits the needs of the tech community.

Because the time I can devote to this change is limited, I haven’t reviewed other alternatives than Redmine, and don’t plan to unless another major alternative is suggested.

Recommendation: Move from Bugzilla to Redmine after careful preparation, especially regarding the organization of the platform.

Product management & Design

In the Software development world, Product managers and Designers are the most common bridges between users and engineers. Product managers identify the needs of users and prioritize features & improvements; their goal is to translate the users’ experience and feedback into explicit requirements to meet the users’ expectations. It is then the role of the designers to create innovative, well-thought solutions to address these issues and meet the requirements. Finally, developers provide feedback about the technical feasibility of these solutions, and implement them the best way possible. This is of course a simplistic summary, but it helps get the point across.

“Designer” can have a lot of different meanings. A lot of people think that “design” is just making things pretty. When I talk about designers, I think mainly of Interaction Designers, i.e. people who design solutions to improve the user experience and the way the product interacts with the user.

The community of MediaWiki users is amazingly large, partly because they include participants from all Wikimedia Websites. Similarly, MediaWiki also benefits from a large base of volunteer developers. Product managers and designers have been the missing piece in this picture; their bridging role is critical, simply because there aren’t any volunteers to take up this task. Admittedly, some users are also developers, and some developers keep themselves informed of the users’ wishes. But without product managers, clear requirements & prioritization are missing. And without designers, the technical solutions created by the developers don’t meet the users’ expectations and mental model.

In my experience, developers prefer to focus on the actual development and rarely enjoy meta-activities related to it. They usually dislike project management and writing product specifications, and rightly so: it is not their job. However, a successful software product strategy cannot rely only on development.

We benefit from a large community of volunteer developers, but we lack management & design resources; it is the role of the Foundation to supplement this lack. It doesn’t mean we shouldn’t expand our development team: our number of paid core developers is ridiculously small. It only means we should also invest where the weakness lies.

Recommendation: Recruit Product managers and Designers to strengthen the development cycle of our technological platform

Research team

The Multimedia usability project has relied heavily on initial research in order to gather as much information as possible about users and their goals. A lot of useful information was already available, but a lot of specific metrics were also missing; collecting and analyzing them took a lot of time and it will still take months to get all the metrics we need.

Research is critical in order to make the right decisions, especially about design. Research is the only way know our users in order to make the best design & management decisions. Good research is the best basis on which product managers, designers and developers can then respectively specify, design and build awesome solutions.

Right now the only researcher we have is Erik Zachte as Data analyst, but his job seems to essentially focus on providing operational metrics. While this work is much needed, we also need some more specific data on a case by case basis. I see at least three other positions needed:

• A UX research specialist, who would conduct regular in-house low-cost usability testing, and generally manage UX studies

• A Metrics engineer, who would develop integrated metrics in the software and be able to extract specific information from the database on a case by case basis.

• A Community specialist, with a good knowledge of social psychology and online interaction, who would especially focus on improving the interaction between participants by identifying the community issues and proposing ways to fix them.

Recommendation: Build a Research team to guide design & strategic decisions about our technological platform

Volunteer developers

We benefit from a fantastic community of volunteer developers, but we underestimate their potential; I think we are not doing enough to support their work and engage them into our activities. In 2007, the Foundation hired Cary Bass to try and coordinate the large pool of volunteers willing to help us with meta activities.

Similarly, we need a Developer community manager to care for our volunteer developers. We need someone who knows the developer community very well, and knows their strengths and weaknesses in order to find the right person for each job. We need someone who can help orient new volunteers, organize real-life meet-ups and manage projects such as the Google Summer of Code.

Recommendation: Recruit a Community manager to coordinate the efforts of volunteer developers.

UX should be a systematic approach

The Wikipedia and Multimedia Usability projects have tried to address the most pressing concerns resulting from the hiatus between the software and the users’ expectations. For all these reasons, I am really happy to see the Wikimedia Foundation investing further in User Experience (UX). However, I see little added value in having a UX department separate from the main development cycle.

A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; good, usable design needs to happen before the actual implementation of any feature, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it.

A separate group made sense when these UX programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate UX programs from the “regular” development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.

Everything is UX

More generally, all the activities of our Technology department are about User experience; everything we do is UX. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users’ needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually provide a user experience.

As a consequence, I recommend to make UX a systematic part of the product or component development cycle, not a separate parallel group.

Tool-agnostic naming

Right now, the bug tracker we use is based on Bugzilla and located at bugzilla.wikimedia.org. Many major free projects use a generic “bugs” or “issues” prefix or suffix in their URL: bugs.kde.org, bugs.gentoo.org, issues.apache.org, www.debian.org/Bugs. Some projects use the “bugzilla” prefix like we currently do, like bugzilla.gnome.org. The latter is an example of a choice based on the implementation model: the name reflects the technical implementation of the bug tracker, not its actual purpose. A better name would be closer to the user model and describe the actual goal of the platform: to report and manage bugs and issues related to a specific project. If we do change our tracker, the current name will have to change too, because it is specific to a given tool.

Recommendation: Use a generic descriptive prefix rather than one based on the tool we use.

Wikimedia & MediaWiki

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki). A good example of this confusion is the number of MediaWiki users who join the #wikimedia IRC channel instead of #mediawiki to ask for software support. The confusion is even worsened by the fact that we have a unique bug tracker located at bugzilla.wikimedia.org, dealing with issues related to both Wikimedia websites and the MediaWiki software.

There are obviously strong ties between Wikimedia projects and MediaWiki: all Wikimedia projects use the MediaWiki software, and the MediaWiki software is primarily developed with Wikimedia projects in mind. However, there is also a growing community of MediaWiki users who are not Wikimedia users and we should provide them with tools relevant to them. This might be for instance a support forum dedicated to MediaWiki users.

Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such: as a consequence, the separation between bugs in the MediaWiki software, and Wikimedia-specific operations & configuration requests should be made more explicit. Obviously, we would prefer to have a unique back-end to support both sites, particularly to be able to move bugs and requests from one platform to another, but this is easily configurable. Possible names could be dev.mediawiki.org and tech.wikimedia.org; both are currently unused. They are pretty wide prefixes, because we may host a real project management platform there, rather than just bug trackers.

Recommendation: Offer two different public-facing platforms for MediaWiki- and Wikimedia-related issue tracking.

Browsing & reusing

1. Automatic localization: Websites such as Wikimedia Commons and meta-wiki host content in various languages and have a multilingual audience. These multilingual wikis should automagically detect the locale of the user’s browser and use it as language of the interface, especially for unregistered users. As for users with an account, their browser’s locale should be set as the default language in their preferences.

2. Usage-centric page layout: It’s all very nice to know that such image is a “retouched picture” or that such diagram was “made using Inkscape.” But I think what most of the users want to know is: how to use the picture (in Wikimedia projects or elsewhere) and how to download it (using the best resolution available). Many people use the right-click-save-as method to save pictures from the Internet. If they do that on Commons, they will only save the low-resolution preview. There should be a big button « Download high-res », as well as snippets of code to embed a file with proper attribution.

Metadata

Full metadata support is the cornerstone of many other features. EXIF is probably the most known type of metadata, but there are also others such as IPTC or XMP.

3. Pull metadata from files on upload: this idea is not a new one, yet it hasn’t been implemented. A fair amount of photographers add a lot of metadata to their files: author, description, copyright information, geotags, keywords, etc. and it is extremely cumbersome to have to redo all the work by hand during the upload.

4. Store metadata in a database to make search and attribution easier, especially: description, license, media type (photo, diagram, map, etc.). It should be connected to the MediaWiki API to allow for easy extraction of these data.

5. Push metadata to files on download: In the field of publishing, storing credit information directly into the file’s metadata is strongly recommended and is a standard practice to avoid losing track of it.

Editing

6. Built-in basic editing features (lossless rotate, crop) and ability to save under another name (i.e. for crops). Similarly, a built-in geocoding feature using OpenStreetMap. Geocoding images means attaching geographic information about the place where the work was made. This may be made easier by the current initiative to integrate OpenStreetMap with Wikimedia projects. And of course it should save the coordinates as metadata.

Rating

7. Some sort of community-managed rating feature; as someone said elsewhere, “Commons is a depository, and depositories are expected to host lots of junk.” A rating feature would allow the best of Commons to be presented first during the search, and junk to be presented last.

Searching

With currently more than 4.6 million files (and counting), it is becoming increasingly important to improve the search features of Wikimedia Commons.

8. An “advanced search” feature similar to flickr’s. It should be possible to search by media type, by license, and to add toggles such as “safe mode” (explicit content) or “personality rights.”

9. Multilingual search: Files on Commons are ordered in hierarchical categories, using English as lingua franca. If you want to find a file, you have to search in English. I imagine it is possible to use some dictionary (coupled to the language detection) to give good results for a search in any language.

10. Google-Images-friendliness. A lot of people use Google Images to find pictures, but images from Wikimedia Commons rarely appear in these results (unless they are used on a Wikipedia page).

1. Do your research

You can’t just improvise fundraising. You’re asking people their money: you have to do your research and behave professionally.

Raising funds is like drawing: it’s not a matter of innate talent. Some rare people are naturally good at it, but most people have to learn and practice regularly in order to be really good at it. The good news is that you don’t need to learn a lot to be good enough to see a noticeable change in your income; it may not follow the Pareto principle, but it’s still good news.

There are many books about fundraising out there. Here’s a list of books I own and I have read. They’re short and very good to begin with.

• Fund Raising Realities Every Board Member Must Face: A 1-Hour Crash Course on Raising Major Gifts for Nonprofit Organizations. David Lansdowne, Emerson & Church, 2007.

• How to Write Fundraising Materials That Raise More Money: The Art, the Science, the Secrets. Tom Ahern, Emerson & Church, 2007.

• The Zen of Fundraising: 89 Timeless Ideas to Strengthen and Develop Your Donor Relationships. Ken Burnett, Jossey-Bass, 2006.

If you follow their principles, I guarantee you’ll raise more funds. I recommend you read them in this order. Experiment your newly-acquired knowledge during a few months, adapt it to your organization, and keep learning. I’d be happy to provide more links if needed.

2. Apply what you’ve learned

Learning is the first step; it’s mandatory but useless if you don’t apply what you’ve learned to your specific organization, your mission and your message. These books provide you with a variety of tools and with food for thought, but I suggest to take each principle or piece of advice and see 1. if it applies to you (most do) and 2. how you can apply it.

I’ve found the following modus operandi to be very effective: While you’re reading the books, ideas and thoughts about your own organization will pop up in your head. Write them down as you would brainstorm: write everything even if it looks stupid. But focus on discovering and learning and don’t try to apply it right then. When you’ve read several books, your perspective will have changed and you’ll be more knowledgeable about fundraising already. Read the books again, but this time focus on how you can apply what you’re reading to your own organization and mission. During the first pass, you’re in the learning phase; during the second pass, you’re in the thinking/applying phase, and the books are merely reminders.

3. Understand the importance of raising funds

Don’t try to raise funds because you “should” or because “it’s nice.” Raise funds because you need money. You can never be as convincing when you ask as when you’re passionate about a project you know you can’t accomplish unless you collect the needed amount of money.

You may see fundraising as a difficult activity that doesn’t bring in a lot of money. You may consider other means to collect money (such as selling goodies) because you see them as easier ways to earn money. Considering alternate means is good, but selling T-shirts won’t (and shouldn’t) be your primary source of money. Ever.

You’re nonprofits; that means you should rely on donations and grants. If you don’t learn about fundraising, you may not fully understand its potential. During the Wikimedia Conference in Berlin, Liam Wyatt likened the Wikimedia movement to a “Red cross for knowledge”: people will donate to you if you ask the right way.

4. Cherish your donors

Thanking your donors one year after they donated is completely unacceptable. If you do only one thing, thank your donors and stay in touch. You can’t afford to lose them. When you’ve read a bit about donor relationship management, you’ll understand how foolish this is.

Also, try to walk in your donors shoes (“donor-centric approach”). Why should I give to these Wikimedia folks?

5. Spend your money

The best way to raise funds is to spend your money. Donors don’t give you money so it lingers on your bank account. They give you money so you do things; they want you to accomplish things to make the world better on their behalf. There is no such thing as “waiting for more money before spending it.” If your projects require more money, then raise more money. If you don’t have any projects to spend your money on, you’re in big trouble. Fortunately, my next article will be about just that: how to spend your money.