Survey on Management Structure of ODK Project

Please help us plan for Open Data Kit’s management transition from UW-CSE to a community led open-source project by taking a short survey about how the ODK project should evolve. The short survey is only 8 to 11 questions and should take less than 10 minutes to complete (not including time to review 2 short Concept Notes).

The ODK Project Management Committee (PMC) is seeking feedback from the ODK community to assist the PMC in deciding which of the ideas presented in the two new ODK Concept Notes should be implemented. We are also open to new ideas as well.

The two new concept notes are based on the feedback gathered from various sources during the past 6 months including: the 'ODK Management Transition Survey', 'Exploratory ODK Concept Notes Survey', the ODK Convening in June 2017, and discussions on the ODK Forum.

Responses to the survey will help inform the structure of the management transition of ODK from the University of Washington’s Department of Computer Science and Engineering (UW-CSE) towards a community led open-source project. More information can be found here.

Please help the PMC by reading and providing feedback about the two new Concept Notes (less than 2 pages) via discussions on the forum and/or via the survey by 8/31/17.

URL for the short survey:

CONCEPT G – Top Level Governance But No Dedicated Organizational Structure

CONCEPT H – Top Level Governance And Transition Evaluation and Decision on Long-Term Dedicated Organizational Structure


I wrote some rambling comments in response to the question about TSC membership and structure. Since one of the ideas I mentioned was biasing towards having discussions in the open, I thought it might have some value to share here. Perhaps it will give others ideas to suggest!

I think the first step is to define the role of the TSC members and some of the logistics around that, especially projected time commitment. For now, I think road mapping is the major activity to focus on as the concept notes describe. Although the committee is called "technical", I do think having some pure implementors involved would be helpful. Could it be simply a "Steering Committee?" I'm thinking of a few people who would be really great participants in roadmapping conversations even if their contributions won't primarily be code-related. I also think these committees will need to come up with processes for their respective projects. For example, I like the simple RFP process described at

I think 12 people is about the maximum that makes sense for productive conversations to happen (and I think it will be hard to get close to that number initially). The ideal is to have an odd number so ties don't happen. Eventually it would be beneficial for TSC members to be elected but given that the participatory culture is still building up I think it would be ok for the first group to simply volunteer or as the concept notes describe, be appointed by the transition board. I assume that transition board members will also be on one or both of the steering committees. On one hand, having a nomination and voting process even if few people participate could mean the committee is taken more seriously. On the other, I worry about burning out the folks who are engaged with too many procedural questions. There's a sweet spot between "asking for community input on every decision" and "doing everything in private" and I think we're still working on what works for us. I tend to prefer biasing for having conversations in the open, even if they only involve a few people at first.

I think the ideal would be to have annual elections for the TSC with some kind of term limit. I like the term limits being more about consecutive years than total years -- a limit of 3 consecutive years sounds good to me but I don't have any real backing for that!

I like the structure of the Hyperledger TSC meetings -

This is not directly related but I also like the idea of SIGs and Working Groups as defined by Kubernetes -