The Assignment

The assignment consists of two phases, each graded separately:

Phase 1: Students choose a topic related to history that either doesn’t have a substantial article already written about it, or a topic that is listed on the history stubs page on Wikipedia. Then, they research the topic and contribute ~500 words to the article. The article must include footnotes, and reference at least two published books, two external websites, and link to at least two other Wikipedia pages. Students must use proper formatting for footnotes, headings, lists, links and other content per Wikipedia formatting guidelines. They must also create a user account, and log in with that user account when editing. If an article’s history doesn’t include the user name they sent to me at the beginning of the semester, they don’t get credit. No exceptions.

Phase 2: After publishing, students must watch the article, see if anyone contributes or changes their article, and if so connect with these users. The goal here is to improve the article, either with others users or individually. If their article is flagged for deletion, students must work to make sure the article isn’t deleted. But, regardless of outcome, students must write a ~500 word reflection on what happened to their article, and how their ideas about Wikipedia had changed as a result of the article.

Notes on Process

Topics

Choosing a topic is fairly straight-forward. I always encourage students to find a topic that interests them, that’s relevant to their major, their job, or even hobbies. Students have written about various historical topics related to psychology, sociology, engineering, sports, art, and theater, to name a few. If students can’t come up with a topic, point them to the stubs page. There are thousands of stub articles to choose from, including United States history, history of science, and military history. All topics have to be approved by me before continuing the assignment. I usually require topics related to U.S. history because that’s my primary field of study, and will approve topics if I think there’s enough secondary and tertiary sources available to allow for an adequate article.

Research

The research process is, more or less, the same kind of research process you’d expect when assigning a short term paper. We discuss how to find resources on particular topics, how to brainstorm, create outlines, et cetera. I introduce students to the librarian on staff who’s relevant to their field of study or topic. (Often, this is the first time students are introduced to these very valuable folks.) Wikipedia also has policies about citation, so I make sure students read the policy on citing sources and verifiability. Additionally, I discuss uses of different kinds of sources, and Wikipedia’s preference for secondary and tertiary sources over primary sources. Students articles must not be original research.

Writing and Formatting

Probably the trickiest part of the assignment is showing students how to write for Wikipedia, particularly the way Wikipedia articles are formatted. We take one class period and review “How to Edit a Wikipedia Article,” particularly the formatting section. There’s a great tutorial and sandbox where students can practice formatting before working on their articles. I demonstrate on-screen how to do different kinds of formatting: footnotes, headings, unordred lists, ordered lists, internal and external links, and inserting an image. There is a useful cheatsheet that details formatting methods for specific content elements.

Publishing and Participating

Like I said earlier, the assignment doesn’t end once the article is published. After they publish the article, they must watch and participate in any change that takes place to their article, for good or ill. I show them specifically two sections of their article to watch:

• History page – I encourage students not to revert things immediately, but to take the time to look at changes, determine if they help or hurt the article, and take the appropriate action.
• Talk page – This is where community members talk about the article in question, offering suggestions for improvement or declaring reasons that the article is irrelevant and show be deleted. Its here that students have to defend their articles, or learn from other Wikipedians about how to improve their articles.

Not infrequently, someone’s article will be recommended for deletion, or their changes reverted. In these cases I show students how to interact with Wikipedia admins, review their deletion policy and the process by which they do deletion review. I’ve had several students’ articles get recommended for deletion, and the students justified their articles well enough to save them.

Why Assign a Wikipedia Article?

I have several reasons why I ask students to write an article for Wikipedia:

• Learn how to do research: A no-brainer here. The assignment involves some basic research and writing skills, a modest but substantial amount for a 100-level survey course.
• Demystify Wikipedia: Most people have preconceptions about Wikipedia, but very little experience actually reading AND writing an Wikipedia article. Fewer people have experience communicating with other Wikipedia users, particularly admins and editors. This, in turn, influences how they interact with others on various social sites and services. Moreover, students learn that not just anything can be published on Wikipedia, there are rules and policies in place for the content that gets to stay on Wikipedia.
• Learn the difference between fact-only writing and analytical writing: Most of my students have a difficult time understanding how to make an argument, how to differentiate between fact-based “reporting” and analysis. By actually being forced to write a “just the facts” report, they have been able to see the difference between the two.

As I said earlier, this assignment is consistently one of my most successful assignments. Students find a topic they’re interested in, research it, learn how to write for different audiences, learn how to use Wikipedia more efficiently, and understand when its good to use Wikipedia and when its not. Furthermore, they get experience with community and collaborative writing, and can take those skills with them and use them long after the course is finished. It does take a bit of work on my part, to make sure students understand the assignment and the technology involved, but in my opinion its completely worth the effort. Its certainly much more meaningful to have students contribute to a larger, more public body of knowledge than to write a term paper for me that will get thrown away at the end of the semester. If this assignment can produce some good articles on Wikipedia, and gets students talking to others and learning outside of class, I consider it a success.

I would advise that in this phase, you try to answer the following:

• What is the site?
• What content will be on the site?
• Who is the audience? How will we want them to use the site? How will they use the site in other ways?
• What specific components are needed on the site? What technologies? Static HTML? Need dynamic content? Need a CMS? Need a custom web application or interactive features?
• What is the timeframe for completing specific phases of the project? What is the timeframe for completing the entire project? What other projects are vying for time?
• Who is on the project team? What are their responsibilities? How much of their time do we have, or can get?

Questions

What is the site?

If you can’t answer this, it will be very difficult for everyone on the team to actually build it. Its OK for the definition or description of the site to evolve over time. In fact, you should probably expect this, as your user base grows or you get new content. The project team does need to hash out, in a paragraph or two, what exactly the site is about, what it offers that other sites do not, and why it is important. If you can’t justify building the project, you should consider whether you should build it at all.

What content will be on the site?

It is very helpful to everyone on the team to have a discusion of what kinds of content will be on the site. This isn’t saying that the content needs to be done at this point; only that a good idea about what content and how much will be on the site. Is is primarily images? Text? Video? Some combination thereof? Is the content something the team is preparing, or something collected from the public? Is it a “web translation” of a physical exhibit or a book? Is it web-native? The kinds of content, its origins, and the expected interaction between users and the content, will influence answers about who the target audience is and what technologies are needed for the site.

Who is the audience?

The answer to this question has important consequences for the development of the site. Even if you have a solid answer for what the site is, and what content will be on the site, the audience for your site greatly affection how you present that content on the site. A teaching site on the history of the Spanish-American war may look and be organized differently if the primary audience is elementary or high school students instead of teachers. The language used on the site, the content for the site, and the design are all affected by the target audiences.

Needed technologies?

From the very beginning, before one line of code is written or one pixel moved in Photoshop, the team needs to decide what kinds of technologies will be needed for the website. Answers to this question depend on answers regarding what the site is about.

Do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help.

The development team specifically needs to help answer this question. Following Tom Watson’s advice, the project team should come together to discuss problems to solve, and what technologies will best solve those problems. You do not, for example, need to use a robust content management system like Drupal if your project consists of only a dozen static HTML pages.You do not need AJAX simply becuase other sites have AJAX; You do not need a blog because other sites have a blog. In other words, do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help. Have a reason for everything!

I would say that the development team needs to be the lead on answering this question. They will (or should) have the most experience with determining which technologies will solve specific problems. But its generally good to talk about the problems first, so the development team can decide on which techology solution will best solve those problems.

Timeframes?

All of the previous answers can be fantastic and full of possibility until you talk about the most important aspect of a project: time. Time can be a harsh master. It is a very a good idea to set deadlines and milestones, to keep the project moving forward and give everyone a sense of how long things will take and when they’ll be done. In some cases, work by each team member can continue simultaneously. In others, one team member must complete a requirement before another team member can start or finish her/his requirements.

In some cases, deadlines are set by grants: “We promised a fully-function site to collect public reflections by May 2009,” for example. Those absolutely should be met. Others can be a little more flexible, but not so flexible that the project never gets finished. Here’s a quick process for setting milestones and criteria:

1. Figure out what milestones are needed (content complete, CMS installed, wireframes completed, etc)
2. Set deadlines for each milestone, for specific phases of the project
3. Associate specific criteria for completing milestones by the deadline
4. If those requirements aren’t met, decide whether to move the deadline for the milestone up to allow for completing the criteria or to remove specific criteria as unnecessary.

In other words, deadlines should be stable enough to provide direction and purpose for the team, but flexible enough to account for unexpected contingencies. If you’ve reached the deadline for a milestone, but do not have all the criteria done for the milestone, consider whether those criteria are necessary to move on. Its OK to say that some criteria are, in the end, unnecessary to consider a milestone complete, and to move those criteria to other milestones and deadlines.

Having milestones, set criteria for meeting those milestones, and deadlines for milestones help keep the project on track, and prevent “feature-creep” or “scope-creep.” By this I mean the tendency for a project to take on new features or new scopes that were not set in the beginning of the process, and cause deadlines to be missed. Its fine to add new features, or change the scope of the project, so long as everyone on the team understands that the timeframe and deadlines may have to shift because of those new requirements.

Team Members

Everyone on the team should be introduced to each other, with a brief discussion of each person’s specific skills and responsibilities for the project. This not only helps build camaraderie, it also lets someone know who to contact for specific questions or issues. Having trouble finding or using the project logo? Ask the designer. Having a problem with a specific aspect of the CMS? Ask a developer. Not sure where the content is for a specific section? As a content lead or project manager.

Management Hubs

This is a lot of information to manage, a lot of tasks to track, and a lot of people to potentially know and talk to. You shouldn’t even try to manage it all on paper, or in your head. The project team needs a central location to go retrieve information about the project, manage tasks, and learn more about other phases of the project. In comes a management hub.

Screenshot of CHNM Basecamp page.

At CHNM, we use Basecamp, a service created and offered by 37 signals. We manage dozens of projects on our Basecamp account, with each project having a homepage, Messages, To-Dos, Milestones, Writeboards, and a place for file uploads. There is a list of everyone involved with the project, with roles and contact information. You can associate a specific to-do list to a milestone, and can thus determine if you can “complete” a milestone if you have completed all the tasks in the associated to-do list. You can assign to-dos to a specific person. We use Writeboards for meeting agendas, notes, and any other documentation we want to keep (styleguides, ideas, etc), and we tend to use the Messages feature more than email to send correspondence concerning a project, that way everyone has an archived copy of the message in Basecamp. As CHNM has grown, Basecamp has become indispensable for managing all our projects.

Alternatively, you could easily use a wiki to manage your projects in much the same way as Basecamp. Free wiki services abound on the web (PBWiki is great, for instance). While not as feature-rich as Basecamp, wikis can fulfill all the needs for project management, with a little work and devotion to organization. You could set up a PBWiki with the following pages:

• Homepage—The “dashboard” with the description of the project, the goals for a project, and list of team members with responsibilities. Links to other sections:Timeframe, To-Dos, and Notes.
• To-Dos—divided by person or aspect of a project, marked off as they’re completed.
• Notes—any meeting notes, archived discussions, or ideas you want to archive.
• Timeframe—a running list of milestones, with criteria listed for successful completion of each milestone.

In any case, the hubs should at least contain the following:

Description of the project

A paragraph or two stating what the purpose of the project is, what it encompasses, who its target audience is, and what the site will offer.

Goals for the project

A well-defined list of goals or deliverables for the successful completion of the project. This helps keep everyone on target, and ensures that any decisions made during the development of a project should only contribute to, and not add or detract from, the goals.

Project team members

I recommend devoting an entire page, or section on the main page, for listing team members, with their roles or list of primary responsibilities listed and contact information. Perhaps even a link to personal webpages or profiles.

Timeframe

Deadlines, criteria for completion of the project, and major milestones.

To-Do lists

Pretty straight-forward: lists of things that need to get done for a project. This can be divided by person, by team (design team, development team, content team) or by sections of the site. its helpful to have these in once place, so that everyone on the project has a sense of the amount of work everyone is facing. Good especially if someone asks for new features not part of the original description or goals for the project.

Meeting notes, various content pages, links as needed

Good to keep in one central location for all team members to contribute to and refer to throughout the project.

You should totally feel free to set up a wiki however you want, but you goals should be: keep everyone informed, archive project progress, and keep the scope of the project clear and visible.

All Alone?

If you’re your own project manager, have this meeting with yourself. Before you type one line of code or color one pixel in Photoshop, go through this process. Set up a project hub. Take meeting notes. Create a timetable. Make to-dos. Some of it may be meaningless (like list of team members), but it helps to formalize the development of a project. And, if you end up getting a grant or someone volunteers to help you with the project, you’ll easily be able to orient them and integrate them into the workflow for the project. If it helps, have someone else around to talk through ideas and get things down more concretely, or pretend you’re explaining the project to someone else.

What’s Next?

After doing all of this, either in one meeting or several, you should be set to move into the next phase of development: Information Architecture. I’ll cover this next week!

1. 1 See Kelly Goto and Emily Cotler, Web ReDesign 2.0: Workflow that Works, Berkeley, CA: Peachpit Press, 2005, 40.
2. 2 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 23.