Aurelio Di Pasquale TSC Application - 2017-11-27

Name
Aurelio Di Pasquale (@aurdipas)

Organization
Swiss Tropical and Public Health Institute (Swiss TPH)

What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
tech support to projects using ODK (around 65 in 36 counties). ODK workshops within the D4H initiative, ODK teaching to students at University of Basel (master in Epidemiology)

How do you believe your contributions have benefited ODK?
Increasing the community of users, lot of feedback from many country settings

What do you believe the top priorities for ODK are?
Evolve looking at feedback user, compatibility with previous versions, not too many release but more stable, simplify the use of new features instead of adding more complex ones

How will you help the ODK community accomplish those priorities?
Using, teaching and implementing on many settings I can provide feedback. Providing documentation/slides used for teaching to facilitating new users to enter in the ODK family

How many hours a week can you commit to participating on the TSC?
1-2

What other mobile data collection projects, social good projects, or open source projects are you involved with?
OpenHDS, Almanach (https://www.swisstph.ch/de/projects/project-detail/project/implementation-of-almanach-in-the-icrc/), ODK WHO VA instrument

Please share any links to public resources (e.g., resume, blog, Github) that help support your application.

@aurdipas You've done a lot of ODK deployments and teaching about ODK and so thank you for those contributions!

Given your depth of experience, I'm curious if you think the ODK docs at https://docs.opendatakit.org covers everything that one should know before deploying ODK. If not, what gaps do you think are missing?

You mentioned in your application that we should simplify the use of new features instead of adding more complex ones. Are there particular features that have shipped that you thought were too complex? How would you simplify them?

Dear @yanokwa ,
thanks for your question.
I personally find the https://docs.opendatakit.org/ a very useful documentation repository and much more organised than the docs on the old opendatakit website.
It needs of course constant maintenance and updates on versions for installation.
I think it will be useful to specify the versions not only of the various component to install but also for the environment OS (e.g. Ubuntu 16.04 LTS or 14.04) as some of the installation procedures can change according to that.
I think it would good to expand a bit more the guide for the Briefcase CLI as many users would like the possibility to extract data with filters and this is not working in Aggregate.
I'm looking forward on the option for the GUI to "override if exists" (https://github.com/opendatakit/briefcase/issues/202), but indicating in the CLI guide how to use the various options will be very useful.
In my personal experience on the field many users also like video tutorial and various are easy to find on youtube(https://www.google.ch/search?q=ODK+Aggregate+installation+tutorial+video&source=lnms&tbm=vid&sa=X&ved=0ahUKEwiF9qWjs5PYAhXO_qQKHWR6C48Q_AUICigB&biw=1680&bih=929)
Maybe one two video tutorial would be nice to have.
Another comment on the ODK docs:
-It would be maybe a good initiative to ask to participant of the forum if someone can help with translations (French, Portuguese and Spanish would be great to have)

I think for a "non programmer" sometimes when it comes to implement a bit more complex things (e.g. Preload csv, external selects,cascading selects, appearances, changing styles, formulas etc) more examples (easy or less easy) excel file to look at are appreciated.
Something like https://github.com/opendatakit/sample-forms but with xls and not xml.

I'd like to highlight another thing I mentioned in my application: the fact to have less releases.
The rational for this is that at least for Demographic surveillance and some other longitudinal studies attached to that, a round of data collection can run from 3 to 6 months.
If in the middle of the round we have 2-3 releases we must be sure about compatibility with old ones and avoid to confuse the fieldworker that see changes in the look and feel or usability for example. This force Project leaders to disable the auto-update functionality of the devices now.
Why not collect a certain number of changes/features and work with a more "relaxed" release plan?