@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.