What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
Fixed multiple defects and some feature work in Collect and Briefcase, some issue triage and support via community channels.

How do you believe your contributions have benefited ODK?
External app support in Collect become more generally useful (can internationalize external app labels from the form, for example), Briefcase contributions made large-scale data collection feasible and found and fixed defects in fundamental Briefcase functionality maintaining its core purpose (backup of forms and their submissions are portable).

What do you believe the top priorities for ODK are?
Offline, server-less, fault-tolerant, technically accessible, technically sound

How will you help the ODK community accomplish those priorities?
I have worked in environments that have required these traits and leveraged them successfully in ways where few other tools could have been (easily) used. I believe I can be a strong advocate for maintaining traits that may not be viewed as important outside many developing-world countries.

How many hours a week can you commit to participating on the TSC?
It would depend on timing of activities, but around 4-8 hours weekly.

What other mobile data collection projects, social good projects, or open source projects are you involved with?
I contribute to a number of projects, but predominantly I work on a campaign information management tool (called CIMS) for significant malaria control efforts and eventually mass vaccination and elimination efforts on Bioko island, Equatorial Guinea.

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

Hi @Batkinson! Thanks for applying for the TSC and extra thanks for the thoughtful PRs you've sent in over the last year.

You've worked on Open X Data, an open source data collection project that had a great run, but eventually had to shut down. What, if any, are the lessons learned that you'd bring to your role on the TSC?

On a more technical note, Briefcase was built to provide backups/portability and decryption of forms, but a server like Aggregate could probably do that work and we'd have one less tool to maintain. I'm curious if you agree, and if you do, what would your approach be to get from where we are today to that ideal?

I learned a lot working with the OpenXData project(s). Most of the big
lessons were non-technical. Here's a quick list off the top of my head:

There is little point to strong technical leadership without strong
project management

Making good decisions can sometimes be difficult, but waiting to
make everyone happy makes them impossible

Be realistic, and honest about your status - for example, seeking
outside help and not telling the rest of the group you think you're in
trouble -> mega problems

Make your goals painfully clear (and concise), publicly refer to
them, sanity check them, and mercilessly change them to ensure the vision
and effort are well-aligned (for member and for others stopping by - they
may choose to help based on it)

How you build the community around the project matters and a community
that lasts makes the rules for membership clear, consistent and aligns them
to the desired outcomes.

Meritocracy is about earning it, and that means everyone

People quickly figure out what the real community rules - so be
aware of the informal rules you establish - the official rules
have to mean
something or you should ditch them

Don't waste time catering to forks, make the mainline fast and
consistent direction

Velocity on core technology pulls contributors and contributions
into the fold

Developers that are already full-privileged members have to be
careful to "put on their community hats" even if it means their funded
project has to wait

Because of the above, you need to introduce people you trust to
have this type of discipline (and make it clear what it's important)

As for the more technical question aobut moving Briefcase's functionality
into Aggregate:

Briefcase is far simpler than Aggregate, something I believe people
underestimate when it comes to value (deployment is nearly a non-issue)

Its power is that simplicity - forms and form instances, that's it -
no database (aside from instance tracking, which is really residual data),
no web server required, no internet required (maybe LAN though)

Aggregate in contrast, is a lumbering beast whose technology was once
trendy and well-supported but it didn't age well (GWT, AppEngine)

Aggregate is riddled with complex run-on code, and the decision to use
AppEngine for its primary deployment limits its sanity (storage
limitations, invisible but drastic influence on what would be idiomatic
code otherwise)

If I were to move forward with either of these tools, I would probably
start closer to Briefcase's model of things than Aggregate's. I would
consider storing the forms and form instances as unstructured documents. I
would not attempt to deconstruct the forms into relational tables, but may
provide abilities to generate fast views on them. I would try to maximize
flexibility by allowing interpreting different, but overlapping form
schemas (in other words take advantage of XML and JSON-type ad-hoc schemas
rather than relational-like structural rules). I would probably try to turn
Aggregate more into an extremely light-weight API and less a web
application. I would favor OAuth rather than HTTP Digest. I would also
probably design the internals of Aggregate to be usable outside of an
HTTP-context, regardless. If Aggregate was designed more this way, I
believe I would support something like getting rid of briefcase. The
encryption/export piece doesn't seem like core technology to me, it seems
like a yet another (albeit important) bulk-oriented API client function.
Based on existing protocols, I expect encryption may require revisiting an
improving existing protocols to allows for more powerful usage scenarios.