Feedback on Draft of ODK's Mission and Values

I've incorporated the suggestions. There's on outstanding side-conversation currently about some particular wording.

I added @yanokwa and @LN as editors --- I would have added @tomsmyth, @Matthew_White, and @W_Brunette as editors, but I couldn't figure out how. (GDocs won't autocomplete you even though you've contributed to the docs with your Google login, and it doesn't show me your google username.... ugh).

1 Like

Thanks, Adam! I've added Tom, Matt, and Waylon's accounts!

1 Like

I've added my comments and edits to @adammichaelwood's document.

Great work -- I like the direct and simply format this has evolved into.

Is the intent that this is the mission? I think it is to the point and works, though it could resonate with me more.

I'm thinking about some of the things it enables:

  • Much of the data was either not collected before or we trapped in paper and not analyzed
  • A variety of low cost devices can be usd
  • Users really can be in charge of their own data without being locked into a vendor.

Any thought on also thinking about the vision? What is the world we want where ODK has accomplished its mission?

1 Like

I think it might be worth adding something about equity to the values.

2 Likes

It's not necessarily if I want them, I think it should be more if the values of interest to the community.

Value concepts/ideas that (at least to me) appear to be dropped:

  • Global community of contributors
  • We believe in making consensus-based community decisions that involve multiple stakeholders
  • Tools are Deployment Domain Independent/Agnostic
  • What does resource-constrained mean? (people can have different interpretation, one driving part of ODK historically has been disconnected operation)

Also the old tagline got dropped "Aspires to magnify human resources" just noting as I do not think it is that big of deal.

Sorry I'm a bit late to the party here.

(Besides that, I'm confused how ODK lets one "use" data on a mobile device.)
(Also, I think "use" the wrong verb to describe ODK's relationship to data.)

I wanted to defend "use data", or at least some word with a similar active meaning. I like the addition of "managing" in Adam's current draft, but I don't think this fully captures it. For example, you can preload .csv files into Collect and use that data to make decisions. I believe you can preload geopoints and display them in a map widget. There are also medical surveys in which enumerators make treatment decisions on the phone, such as IMCI (see this example form) or hypertension screening (see this example form). ODK 2 also makes extensive use of previously collected data. Many of the organizations I have interacted with highly prioritize making use of their data in the field moving forward. It seems to me that obtaining actionable data that can be used immediately or after aggregation is part of ODK's mission, both historically and into the future.


I like @wonderchook's idea of thinking about what a "victory" for ODK would be. To me this seems like a world where anyone, regardless of training or domain, can leverage modern technology to gather data quickly, cheaply, and easily. I think the second paragraph touches on this a bit. I know @yanokwa is suggesting we remove that paragraph as it stands now, but I wonder if we could refocus it in this direction (but not the wording I used above). So the first line is what we do and the second is where we want to be. Then we get into the detailed lists of how we do it.


I agree with @W_Brunette that it would be a good idea to expand on resource constraints. I think these, more than anything else, drive the design of the ODK tools and explain the choices that are made. As @W_Brunette pointed out: disconnected operation is probably chief among the resource constraints we account for, and it has major repercussions on the design of the tools, including the local storage, the server API and protocol, and even the user interface. Another constraint is support for older, cheaper devices, which encourages us to target the oldest Android versions we can and forgo the bleeding edge features. We might consider cost to be a resource constraint, which influences which technologies we integrate with and ties into the cheaper devices.

I don't think we should include all of these repercussions, but I do think it is useful to enumerate the constraints we account for. This list may change in the future, but if a new constraint is added the ramifications on the tools will likely be large enough to warrant a mission update.

I've edited the Google doc taking into account the suggestions made there.


re: enumerating specific constraints (rather than simply stating "resource constrained"

I disagree. I think:

  1. A mission statement is, by nature, somewhat lofty and poetic. It serves as inspiration and introduction as much as anything else, not technical specification. It shouldn't need to be weighed down with the oddly specific.
  2. "Resource-constrained" seems to cover the things that it needs to cover --- low powered devices, slow/no internet --- What else would it mean in the context of software?
  3. The list of resources that might be constrained is endless. As a side note, @Jeff_Beorse mentions cost. Training or familiarity with technology could also be included. Personnel and labor capacity is another. Time is another. It seems to me that ODK takes all of these, and more, into account, and strives to make software that does as much as possible with as little as possible.

This is the one thing missing that I think really needs to get back in.
(I'm going to see if I can find a good place for it.)

This adds a lot of context for resource constraints, as well as other things like ease of use, lack of technical capacity. It also implies several important needs, like language internationalization and the way we communicate as a community.

@adammichaelwood thank you for your reply about “disconnected operation” because it helps to highlight the possible misunderstanding I am concerned about. My apologies for not effectively communicating in my previous post (or even in the original draft of the mission and values, the draft did not do an effective job to begin with). My suggestion was focused on specifically including the values that guide the organization to help people understand the common vision. (http://www.diycommitteeguide.org/resource/vision-mission-and-values). The mission and values concept can be sort of weird as it relates to an open source project as the project’s vision is about tech because that is the artifact it produces. I agree we do not want the statement to turn into a design doc so it can be difficult to tell what to include and what not to in terms of tech features (which I do not think we want), design principles, etc.

Historically, the ODK project has significantly valued “disconnected operation” and this is not reflected in the current draft of values. Whether or not “disconnected operation” is important anymore is open for discussion but it has been one of the core values of ODK’s design. Enabling “disconnected operation” was a similar core value to ODK being “open-source”. Most design/engineering decisions were historically run through the test “will this implementation work disconnected” which led to ODK accommodating arbitrary long periods of disconnected operation. While disconnected operation may seem obvious now, historically it was ODK’s focus on disconnected operation that helped set ODK (and other tools like CommCare, etc) apart. Many years ago people would ask why not use online tools like Google Forms or Survey Monkey as you are just re-inventing the wheel.

Designing a system like ODK is about trade-offs and personally I think enumerating what are the guiding values that drive decisions helps people understand the vision and why certain decisions are made about the ODK Project. As a example, ODK would look different if historically we had valued security over disconnected operation. The security design and technology chosen was limited by ODK’s guiding value of operating in a disconnected environment. If security is considered a value in the current statement then I find it weird that disconnected operation is not. Maybe neither should be values?

The term “resource constrained” has historically included at least the following: availability of connectivity, cost of connectivity, types of connectivity, availability of money, availability of bandwidth, availability of technical expertise, availability and cost of equipment, availability of power, availability of surrounding technical infrastructure/ecosystem. I think we both agree we do not need to list all the resource constraints; however, listing project guiding values that are are highly weighted in project decisions makes sense to me. A guiding value of the ODK project has been “disconnected operation” as it drove many decisions making the project what it is today. This is not a deal breaker for me but it feels like we should have consistency and consensus on why to include some things and not others that are core/guiding values. If the community no longer values disconnected operation that is okay too, but we currently have two peer-to-peer communication projects underway so it seems like it’s still valued.

@W_Brunette It seems that "resource-constrained" captures "disconnected operation" nicely and there aren't strong opinions against enumerating the type of resource constraints and which ones. That feels like lazy consensus to me!

I think you make good points about data security and privacy and the early design decisions and I've dropped that language. I think data ownership is important but it's heavily implied in open so I've dropped it too. I think the document reads pretty simple and clear (which is in the list of values) and it gets us closer to a final document.

@adammichaelwood I've added some language about a global community of contributors. We lost "welcoming" in the change, but I think people who participate will see that immediately. Also, thank you for adding @Jeff_Beorse's language about using data (I think it was you).

@Jeff_Beorse I hear you and @wonderchook's point about what victory for ODK would be. It's a great point and I propose that comes in a second PR (as it were). I think we can do this in a fun way where we add it as a question we pose to regular contributors over the next few months (maybe in interviews, maybe in TSC applications) and then someone can go through and summarize. Could even end becoming a catchphrase or tagline. Does that sound reasonable?

2 Likes

@yanokwa I like the idea of opening up the question of what victory looks like to a broader set of perspectives. I imagine we will get some pretty interesting answers. +1 from me.

3 Likes

@yanokwa I generally agree and like the changes. I think we are getting closer to a final document and have included most concepts in some generic fashion.

Two ideas/concepts that appear to have been dropped from the document that I think are worthy to be brought up for discussion/bring to peoples attention before the document is called final.

  • The concept of an ecosystem of complementary tools got dropped. I believe this was important to some community members as demonstrated in website discussions.
  • The concept of data ownership got added early in the rewrite and I think it resonated with people (including me). I think data ownership is more of a value than other software design points that were removed and might help to communicate some of the other software design points that were removed like privacy.

Here is possible text to be added, it was created by bringing back text from an earlier revision and adding the ecosystem concept (of course open for revision):
"We believe users should have ownership of their data, control of their devices, and the flexibility to select suitable components from an ecosystem of complementary tools."

We can also not add these concepts to the final draft, but it seems like it would be good to confirm/understand the community's opinion since they were important at some point to some community members.

Do people think these concepts should be included or not? Do they resonate with you?

2 Likes

I agree that data ownership could be called out more! I've added most of that language to the current revision. I've dropped device control because it's often the case that the organization, not the enumerator, who has that control. Does anyone have violent opposition?

I agree that picking and choosing components is an important thing to call out. I've dropped some of the more generic software language and included your language. It fits beautifully as a user-focused/deployment-centric bullet. I've also tossed in a wee bit about iteration.

I'm resonating with this draft. Anyone else resonating?

1 Like

I agree this current version is resonating :grin: I think we have incorporated most of the ideas in a more elegant way (of course assuming no further changes).

Anyone else resonating?

1 Like

+1 from me on the current version

1 Like

The document works for me!

1 Like

+1 from me on the current version too. If my engagement has reflected some of the community, I have mostly been passively agreeing to the edits thus far. Thank you for the transparency in the process.

1 Like

I've been following along quietly. I like what y'all have gotten to.

1 Like

Thank you everyone for your participation and insightful comments on the Mission and Values! :heart:

Since their seems to be consensus around the current draft the PMC decided at today's meeting to move the current draft to the next step and make it a Pull Request: https://github.com/opendatakit/governance/pull/11

The pull request will be available for at least 5 days for any final comments/concerns. The final adoption will likely occur at the next PMC meeting (currently scheduled for May 18, 2018).

4 Likes