Feedback on Draft of ODK's Mission and Values

@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