Request for proposals: 1.0

Download this RfP as a PDF

About Wiki Education Foundation

We’re a nonprofit that brings together the worlds of Wikipedia and academia. Our main project currently is the Classroom Program, which helps university professors to run effective Wikipedia editing assignments in their courses. The basic concept is that professors assign students to improve Wikipedia articles instead of writing traditional term papers. The students get a unique opportunity to do work that has an audience and makes a difference, the professors can improve public understanding of their specialties, and Wikipedia becomes better and more comprehensive. The Classroom Program includes online training for professors and students who are new to Wikipedia, model assignments and best practices, teaching materials, (fairly basic) software on Wikipedia for keeping track of class activity, and a volunteer corp of “Wikipedia Ambassadors” who help professors and students learn the ropes.

In the most recent academic term, our Classroom Program supported 65 courses and more than 1700 students — who edited almost 3000 Wikipedia articles, which have been viewed nearly 100 million times in the last three months. Many more professors are eager to participate, but before we can scale up, we need to provide better support for designing great Wikipedia-savvy assignments and for monitoring class activity.

As an organization, we recently spun off from Wikimedia Foundation (the nonprofit that runs Wikipedia), and our staff (6, and growing) is mostly made up of experienced Wikimedians. The spin-off will enable us to take advantage of development opportunities outside of MediaWiki, and this RFP represents the first steps of that.

What we want to do

Our goal is to provide a set of digital services on for our program participants — professors, university staff, university students, and Wikipedia editors — to help them do great work on Wikipedia and prevent common problems. Those services include:

On launch (by November 2014)
  • Sign on using Wikipedia accounts (via OAuth)
  • An “assignment design wizard” that lets a professor choose from among the common types of recommended Wikipedia assignments, customize the timeline and details to fit their course, and post the course plan to Wikipedia.
    Why? – Over the the last few years, we’ve gained — and documented — a lot of knowledge about what works and what doesn’t for Wikipedia writing assignments. But it’s not easy for professors who are just getting started with Wikipedia to benefit from that knowledge, and even if they want to follow one of our model assignment designs closely, it is tedious to customize it. For a professor, turning a wall of boilerplate wikitext into an assignment plan that fits your course is not a fun way to spend your day. But a solid assignment plan that incorporates best practices and subject-specific Wikipedia resources is the biggest factor in running a successful Wikipedia assignment.

Down the road (2015 and beyond)
  • Dashboard for instructors and other stakeholder groups to view information about ongoing and past courses
    Why? – The more we can highlight important class activity on Wikipedia, the earlier problems will be corrected and the more chance professors and students will have for collaboration.
    • Article view statistics for the articles worked on by the students
    • Articles created
    • Articles edited
    • Total article views
    • Number of active student editors
    • Total edits
  • Wikipedia knowledge quizzes, with results accessible to course instructors
    Why? – Our training for students provides an overview of the Wikipedia basics, but quizzes would give students a chance to reinforce the training content and make it easy for instructors to see which of their students completed the training assignment.
  • Program-wide dashboard, aggregating stats for multiple groups of editors, and showing which groups have started editing
    Why? – With a high-level overview of course activity, our volunteer corp and Wiki Ed staff can find out courses would benefit from some extra help.
  • Plagiarism checking of student edits by connecting to a commercial plagiarism checker, such as iThenticate/Turnitin
    Why? – Wikipedia has strict rules against plagiarism and copyright violation. Student editors tend to copy and paste content into Wikipedia at around the same rate as other newcomers &mdash a little less, actually — but when students do add plagiarism, it can be extremely disruptive to the Wikipedia community, and the necessary cleanup work doesn’t make anyone happy. We want to catch copy-and-paste issues early on, and point students in the right direction while they still have time to fix the problems.
    • Initially, on-demand plagiarism checks for individual groups
    • Later, continuous automated checks for all students edits
    • Minimizing false positives will be a critical requirement for this service.
  • email reports that summarize recent group activity
    Why? – The easier it is to learn about what a class is up to, the more collaboration will happen and the earlier problems can be fixed.
  • A tool to help professors identify sets of articles that will be good for students to work on
    Why? – Wikipedia assignments work really well when students focus on topics that are poorly developed on Wikipedia, but that have plenty of good sources available. It’s hard to know where Wikipedia’s holes are in a topic area.
  • A matchmaking system to connect professors with volunteers, based on discipline and/or location
    Why? – When experienced Wikipedia editors collaborate with professors who share their topic interests, and when they can meet in person, cool things tend to happen.
  • An achievement system for program participants based on Wikipedia editing and related program participation milestones
    Why? – The longer participants are involved with Wikipedia, the better their courses go. We want to recognize the people who’ve kept at it, and encourage people to do great work.

In short, these services revolve around posting data to and pulling data from Wikipedia and other platforms, storing, manipulating, and presenting that data, and using that data to trigger communication with users. They also involve major user experience components: we need intuitive tools that cut through the complexity of Wikipedia — technical and otherwise — and make it easy to dive into Wikipedia quickly and effectively.

Our current website

We run WordPress on as our primary CMS. We expect to stick with WordPress for our blogging and general CMS needs. The development projects described in this RFP will also run on, but they need not be integrated into WordPress.

What we’re looking for from a web development company

Our initial goals are modest, but we want to continue developing this digital services platform over the long term. We’re looking for experienced developers who can build a solid long-term foundation for a system that plays nicely with Wikipedia and other platforms, and ideally, a company we can partner with for the next phases of development. Our product manager will be based in Seattle, WA, and will expect to work closely with the development team on a day-to-day basis (whether as an on-site customer with a Seattle-based organization, or remotely) to provide information, clarify requirements, and work through designs. We have a broad and deep understanding of the Wikipedia/MediaWiki ecosystem and a set of concrete problems to solve; we’re looking for a company that brings outstanding design chops and dedicated design/UX expertise, has experience building great-looking and easy-to-use tools on top of open data, and (ideally) shares our passion for free knowledge.

We’re looking for a development team that can deliver:

  • design mockups / wireframes
  • well-designed architecture that others can build on and re-use
  • a great user experience
  • maintenance, refinement and quick bug-fixes based on user feedback

Wiki Education Foundation is committed to building free software; source code for all our digital services will be published as it is developed, under an appropriate free license. Coming from the MediaWiki world, we’re most familiar with PHP, but we aren’t committed to any particular programming language (as long as we can run it on an open source stack).

Scope of this RFP

For the first wave of development covered by this RFP, we want to launch in November 2014, with additional features and related work complete by Febuary 2015. Because we work with universities, our work is bound by the academic calendar, meaning the November 1, 2014, deadline is hard: In order to be useful for the term that begins in January, we need to have a functioning platform by November 1.

We need to launch by November 1 with (at minimum) these key features:

  • Wikipedia editors can log in to using their Wikipedia accounts, via OAuth.
  • An “assignment design wizard” walks users through the key decisions and parameters in crafting a Wikipedia editing assignment for a university course. (The logic and content should be easily changeable by Wiki Education Foundation staff.)
  • After completing the wizard, users can post the resulting assignment plan directly to Wikipedia as wikitext, via OAuth and the MediaWiki API.

Creating a great user experience for the “assignment design wizard” is our top priority. We have a few ideas about how it might be done, but we’re not committed to any particular concept. We have detailed model assignments that will form the basis of the wizard; we want to transform these model assignments from walls of boilerplate text into an interactive customization experience.

At launch, or as soon as possible afterwards, we also want to begin adding analytics features for courses. In particular:

  • Users have access to a course dashboard, which pulls data from Wikipedia and related services and presents it in an attractive and useful way.

The final item within the scope of this RFP is a feasibility study for plagiarism checking of student edits. We’re interested in a system that automatically checks students’ new Wikipedia contributions for copied content, such as by sending their edits through iThenticate/Turnitin, and then notifies professors and other users about potential cases of plagiarism. You will work with our product manager to explore the potential for such a system and complete a feasibility study by February 1, 2015.

Proposal requirements

  1. Tell us about your company. How big are you? Where are you based? What kind of background do you have? What kind of projects do you usually do?
  2. Give us some examples of your work. Show us a few outstanding interactive designs you’ve created.
  3. Point us to some recommendations. Who can we talk to about work you’ve done?
  4. Show us some code. If you’ve done open source work before, we’d like to see it.
  5. Talk about your plans. In broad strokes, how would you approach development of this project? Which language(s) would you use?
  6. Provide an estimate. How much will it cost to build this? How far along would you get by the November launch date?

Send your proposals by August 1, 2014, to:

Sage Ross, Product Manager  –

If there are any questions we can answer or you’d like to chat about the project, please get in touch.


  • July 3 – RFP published, begin talking with potential bidders
  • August 1 – Proposals due
  • August 15 – Select development company and begin work
  • November 1 – Launch “1.0” version, begin work on additional feature and plagiarism checking feasibility study
  • February 1 – All features, as well as plagiarism checking feasibility study, are complete. (Work continues, outside the scope of this initial RFP.)


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.