ODK TSC 1 Call - 2020-02-19

These calls bring together the Technical Steering Committee for the ODK suite (@TSC-1) to discuss roadmaps, working groups, and other issues of technical governance. Everyone is welcome to come to these calls, but only TSC members may talk.

The calls are held every two weeks in our UberConference room. We put the agenda, audio, and transcript of every call in this document.

Our next call will be Wed, Feb 19. The meeting time should be shown in your timezone above.

The agenda is tentatively as follows:

  • TSC1/TSC2 call followup discussion
  • ODK Collect (and others?) client remote/server-side configuration options
  • Streamlining ODK spec changes
  • ODK Collect UI change review process

The agenda can also be seen in the agenda document

If there are topics you would like to add to the TSC's agenda, please comment below. :point_down:

1 Like

Shaking the tree for agenda items...

  • any interest (and volunteers?) for further discussion on how to move forward with longitudinal surveys?
  • perhaps a quick update from likes of @martijnr, @ln (or @Xiphware?) as to decision and rationale to introduce ODK spec versioning going forward, aka odk:xforms-version (instead of tool-specific odk:generated-by)?
  • any other current pressing technical issues needing TSC eyes?

If there's some time and y'all are up for it, some discussion around configuring clients from servers would be much appreciated. This would be exploring alternatives to the rejected matchExactly proposal. I've had to put this on the back burner but plan to devote some time to it over the next couple of weeks. It would be good to get some feedback on:

  • What client configuration options exist in the ecosystem. e.g. I'm pretty sure I've seen a side drawer in Enketo with some options but I can't seem to get to it anymore.
  • Given the information above and some of the discussion in the prior thread, how important is it for servers to provide settings that are standard across clients?
  • Given that server URI and credentials can currently be set when offline in Collect, when should the settings exchange happen? e.g. should we consider client polling or server pushing?

I'll try to get a more concrete proposal or two and some guiding questions together during my day tomorrow.

1 Like

Added to agenda. I take it this means yer showing up again.... ?! :roll_eyes:

[Ya know, the ODK Governance does state, and I quote:

The TSC may add additional members by a TSC motion.

and it doesn't state whether the individual in question actually has the right to refuse... :grin: ]

Looking forward to your continued presence! :slight_smile:

1 Like

I could use some time to talk and ask about streamlining the spec update process.

2 Likes

Perfect. The configuration API is the trigger for this conversation because I believe there have never been additions to the communication protocols in the ODK/OpenRosa ecosystem.

Somewhat related to the spec process discussion is one about evolving the Collect user experience. As many of you have probably noticed, @seadowg has been leading making changes towards alignment with Material Design Guidelines. Most of those have been to code structure with deliberately limited user-visible changes. We've tried to be very conservative because historically the folks who have Collect in their hands are the most vulnerable users with low tech literacy and low resilience to change. The high-level questions I'd like input on are:

  • How much TSC feedback should we seek for user-visible changes
  • Should we aim for incremental changes or try to do one big redesign with a major version bump
  • To look at something concrete, is removing the app "title" and tagline a significant change?

If there's time a quick check-in on those questions would be much appreciated.

:smile: I'm open to it! I think there may be an election cycle coming up? Again, my main concern is that I can't be on a call before 8am PDT.

Thanks for another very productive hour!

We didn't get to a high-level discussion about the Collect UI evolution. I realize that will probably be more helpful to have when there's a concrete process proposal in place including how we leverage user interviews and field research to validate changes and how we communicate about an upcoming new user experience with users.

In the mean time, the change we're looking at for this coming release is to remove the app title and tagline:

I don't think this is controversial (can you even remember what was there?) but do speak up if you think it could confuse users or otherwise detract from the user experience.

1 Like

Yes, "Data collection made easier...". Aren't you worried that users who have come to depend on this text will think we are going to be make data collection harder? :grin: