The PMC, TSCs, lead devs, and a few active contributors will be holding a technical convening from October 11-13th, 2019 in Seattle. The goal of the convening will be to discuss governance, specifications, plans, and other topics important to the future of the project. We are grateful to the Gates Foundation for supporting this effort.
There have been about 45 people invited to the convening. Attendees were selected by the PMC and TSCs based on their active contributions and how critical they are to making progress on tentative outcomes.
Although we were limited in who we could invite, we want to make sure as much of the community can participate! If there are important topics that you’d like to be discussed, please comment below so we can add it to the agenda.
Over the next few weeks, we’ll be publishing our detailed agenda and getting input. Please watch the convening-2019 tag to get more updates on the convening.
Very much looking forward to this! Big kudos to BMGF for the impetus.
Topics I'd like to see
I can probably think of a lot more, but here are some off the top of my head.
Collaborator support/onboarding
The support provided on Slack and the forums is really great. However, I'm wondering about a systematic way to onboard or ease aspiring new collaborators. Perhaps some "how to contribute" documentation, more 'good first issue' labeling, perhaps codebase walkthroughs (like for "scary" JavaRosa) over voice chat; some sort of talk/plans about that would be nice.
PyXform
Seems like a lot of open issues and PRs. Don't know if anyone is interesting in discussing that.
Auxiliary ODK Tools
Info sharing of auxiliary 3rd party ODK compatible tools. PMA has developed several, and would be happy to share if any interest. Perhaps attendees work on/with other tools that could be shared?
XformTest: Tool for running XLSForm/XForm test cases.
I would be interested in seeing if case management could be brought to ODK somehow. Case management is a way to assign an survey taker to do a specific questionnaire and possibly pre-fill some data. The survey taker would see a list of surveys in the app for specific people / targets. These assignments could be made from central data management through the server, or they could be generated from the data / results of another survey.
For example, in PMA's use case, we do a household survey, and based on eligibility criteria (answers to questions within the household survey), specific follow up surveys could be generated and pre-populated with data.
I do agree with @jpringle, Case management is one of the best way to reduce time and also reduce risk of error in data which will be collected by Data Collector.
Few more thing which, I would like to tell: Tools which was created by @jpringle and @Joseph_E_Flack_IV like PPP, ODK2Stata, these do will reduce a lot of time of Data Managers, and odk2stata is far better then odkmeta.
I will recommend that these tools should be discussed so our community will take more benefits of these open-source software
@jpringle Longitudinal data collection is something we will most certainly discuss and assignment is a part of that. We'll reach out in a few days directly to get more detailed information about your current workflow so we can have that as input to the longitudinal data discussions.
@Joseph_E_Flack_IV This might be surprising, but pyxform isn't officially an ODK tool! We are working towards that though. We now have tool governance that guides acceptance of tools into the ODK Suite. Perhaps we can do a lighting talk session demoing auxiliary tools?
As to onboarding, I hear you, but I struggle with what improvements we can make. Can you take the lead and draft a Google Doc with the headers of the sections you want filled out or the information you wish you had? That'd be good input into the session and @KeynesYouDigIt would be a good person to collaborate with.
Hi all,
looking forward to discussing ODK in person!
I'm interested in:
Case management and longitudinal studies:
Story "tagging a turtle nest":
enumerator sticks a post with a label next to a turtle nest
ranger comes back with fencing to prevent trampling
researcher counts egg shells after nest has hatched
Story "marine wildlife incident":
someone with wildlife incident app reports a stranded/injured turtle
ranger gets alerted to rescue/remove stranded animal (push notifications from ODK Central on new submissions?)
our vet gets notified about an incoming case
case wrap-up gets reported to district manager and as "thank you/follow-up" to initial reporter
Story "asset management":
Ranger 1 notices a bench in a national park needs re-painting
Ranger 2 gets sent with paint bucket and needs to locate bench, then report as "painted"
Related: tasking field workers to fulfill a general task within a defined region. This might not need to happen within ODK but might be solved by:
following, offline capable map
dynamically generated and synced vector layer of points and polygons (from previous ODK surveys, e.g. layer of benches requiring painting, polygons of areas requiring week killing if weeds sighted)
separate ODK form to report completed tasks
Story "turtle tagging":
Enumerator 1 tags a turtle after nesting, records tag "WB1234".
Next night, enumerator 2 tags another turtle, notices tag "WB1235". Wants to know: when was this turtle seen last? Same beach? Neighbouring beach?
Complications: need to sync while out of reception
As a team leader, I want to review longitudinal case history (including all records collected but not yet uploaded) to detect and amend typos (WB1234 vs WB1235). Memory of enumerators fades after few hours, therefore best to review and reconstruct right after a tagging night.
Wishlist for hardware integration:
For turtle tagging, I want to scan PIT tags ideally directly from an android device, or via tethered bluetooth PIT tag scanner. This would be a revolution in data quality if we wouldn't need to type in 10 digit PIT tag IDs being sweaty and tired (or wreck night vision with flashlight to scan barcodes).
To survey for furry critters in trees (spotlighting surveys for Western Ringtail Possum) or Dolphins at sea, I want to bluetooth-tether a laser rangefinder to capture distance, bearing and elevation with one trigger pull.
I might need to turn off devices to conserve power, and whip them out (and re-establish BT tether) quickly on demand.
@paul_macharia and others in Seattle who might want to attend. Unfortunately this convening isn't open to all, but please send me a PM with your contact information so we can meet up for the after convening dinners!
As promised, I've updated the top of this topic with the link to the convening agenda.
Over the next few days, I'll also be sharing detailed descriptions of the various sessions and materials that attendees should review to make the most of their time.
YES seconded! share the doc if you have it, I'd love to work on this. Eventually I would like to make some videos that cover the full ecosystem and how each piece connects.
AFA non-"oficiall" tools, I feel like pyxforms is widely used no? Plus stuff like ODK2Stata is super cool. I wonder if we could make a small static site that serves as a guide to the eco system. might be worth a talk if we have time at the convene
@KeynesYouDigIt
nope, that's just my ODK "classic" thinking coming through, in which ever new encounter with an entity (possibly already previously encountered) forms a new record.
I wanted to do a quick debrief of the convening and share some of the outcomes that affect the broader community.
Our high-level goals for the convening were to enable the TSCs that lead ODK and ODK-X to meet in person and make progress on tool suite priorities. Another goal we had was to reach consensus on governance that the PMC uses to lead the overall project.
For the TSC responsible for the ODK Suite, the key outcomes were:
We learned that we need to be more transparent about who is funding development, who does the work, and what systemic risks exist with that pairing (see slides and notes).
We have reached consensus at the TSC that structural changes will be needed to ensure greater sustainability of the tools and there is desire within the TSC to make those changes.
We gained greater clarity into the popularity of the various tools and discussed a rough strategy for the next few years (see slides and notes).
We spent quite a bit of time defining a minimal viable product for supporting longitudinal data collection in the ODK suite (see notes). We also built a list of features for map-centric data collection (see notes) and discussed with ODK-X's TSC how we could work together to make the docs easier to contribute to (see notes).
ODK-X Suite
For the TSC responsible for the ODK-X Suite, the key outcomes were:
Created a prioritized a backlog of issues that will feed upcoming year's roadmap (see notes).
Generated a plan to overhaul ODK-X's documentation with a focus on learning pathways of different types of readers (e.g, field workers, developers)
Discussed how to improve the usability and flexibility of the ODK-X architecture by upgrading certain features (e.g., async_assign, synchronization protocol) (see notes).
Overall
One of the exciting outcomes is that we’ve reached consensus on a governance structure that we believe will work for the overall project. We'll share detail on in the coming weeks, but until then, our convening facilitators that helped us reach consensus have prepared a detailed report that shares their perspective of the preparation, event activities, and outcomes achieved. You can find that report below.
A big thank you to everyone who participated in the convening! And to those who we did not have space for this year, I fully expect that we’ll do another convening in about a year. The best way to be secure a spot to the next convening is to participate in the project. Quick ways to contribute is a great place to start!
