Some folks at UNICEF asked me to help them articulate a process for how to make their research projects (usually "is this program we want to do a feasible one?" or "what was the impact of this program we did?" into open content ones. Here's what I wrote them back.
There are some pretty basic things that a researcher can do to make their work into an open content project. Here are a few.

1. Radical realtime transparency. Release all work in an editable format under a creative commons license as soon as it's made. I'll elaborate on each of those points in a bit more detail:

1a. Release all work. This means not just the finished/polished products, the incoherent notes, and the random scribblings as well. You can put disclaimers of "these are the rough things" at the top, and you don't need to do announcements of the release of all your low-level work (except in weekly summaries) but they will let other people dig as far as they could possibly want to go on your activity in the space.

1b. In an editable format. No pdfs -- wiki pages, plaintext in a version control repository, something Word (or better yet, .odt) files are marginally acceptable, but force you to become a merging bottleneck; it's best to get as close as possible to people being able to edit not just the material, but also each other's edits, themselves.

1c. Under a creative commons license. Use the same license as the final paper. I noticed you chose the CC-BY-SA license, which is good; the key point is to avoid the "noncommercial" and "no derivatives" restrictions, which are the non-open creative commons license variants. Remixability for all purposes is vital.

1d. As soon as it's made. This means what it sounds like; push it as you do it, not after the fact as "background material" accompanying the finished paper. If you want people to help you along your journey, they need to know as accurately as possible where you are right now.

2. Make work findable. Have a central place where people can easily read the current status of the project in 1 minute or less, and where they can quickly navigate to all the materials you've created for it. The specific structure/format isn't as important as having a clear structure to begin with; pick a schema and stick with it.

3. Make participation as low-barrier as possible. Whenever possible, don't require logins or account creation. If you must use authentication of some sort, think about what accounts the people you want as collaborators are already likely to have (facebook? twitter/identi.ca? wikipedia? github?) and what platforms they're already likely to be familiar with (do they know version control? word processing? English?) and in general try to make it possible for someone to go from "stumbled across your project" to "made a contribution" in as few seconds and clicks as possible.

4. Update in a regular rhythm. Weekly is usually good, but for some projects it may make sense to cycle more quickly or slowly. For those who need a rule of thumb, I'll semi-arbitrarily say that you should have at least 5 updates throughout the life of your project, so a 2-month project might have weekly updates, a 2-week project would have daily updates, a 1-day project might have hourly updates, but a 1-year project might have bimonthly updates (though weekly updates will drive more participation). Pick a schedule, announce it, and stick to it; this is something that should be on the front of your "participation" homepage (from #2, "make work findable") so that new people coming in know when the "next thing" is coming up that they can jump in on.

5. Reach out in backchannel to bring people to the public space. Email, go to conferences, tweet/dent, blog, sit down at coffee shops, go to marketplaces... go where the people are, and engage with them in their spaces as long as it takes for you to help them feel comfortable coming to yours. Basically, private conversations are necessary, but they're necessary as a means towards the end of bringing people into a public and collaborative space. It's like opening a new physical location for something like a bar or a library; you want everyone to end up in your space interacting with each other, so you go out and have individual conversations with them aimed towards getting them there.

Hopefully these are useful as general rules/constructs to follow -- glad to help with specific implementation questions as things come up. If the first few projects doing this go well, we can go back over them as case studies and figure out a v.2.0 of the approach based on those experiences, which would be exciting.

One thing I haven't addressed here (and don't know the UNICEF practices around) is IRB -- since you're dealing with human subjects, particularly during interviews and site visits/observations, how do you get consent from those people to publish their data (and since so many of the people you work with are children, how do you get consent from their legal guardians as well)? Do you have an internal IRB, or work with IRBs from other institutions? This is much less of a consideration when you're doing fieldwork only for private/personal knowledge and to inform a project, but if we're making data public on the internet, that constitutes a form of publishing, and we need to make sure we're doing the right thing in terms of consent and privacy and making sure people know what that means.