Guillermo Gutiérrez TSC Application - 2018-07-16

Community
1

Name
Guillermo Gutiérrez (@ggalmazor)

Organization
Nafundi

What contributions (e.g., issue triage, tech support, documentation, bug fixes) have you made to the ODK community?
I've been contributing to Briefcase, Aggregate, and JavaRosa for the last ten months. During this time, I've been engaged with users in the forums giving support and receiving feedback, I've created and triaged issues, I've maintained docs, and worked on the code bug fixing and adding new features, generally.

I'm also currently involved in Outreachy by mentoring an internship project for Briefcase.

How do you believe your contributions have benefited ODK?
In Aggregate, apart from bug fixing and some new features since version 1.4.15, I've modernized the development stack lowering the onboarding effort for new contributors. I've also improved Aggregate's build process to offer new deployment options such as VMs and Docker containers.

In Briefcase, apart from bug fixing and new features since version 1.9.0, I've updated the codebase to Java8, which makes the codebase more appealing for contributors, and I've made changes aimed to improve the code design, support testing, simplify work with UI components, and lower the complexity of the codebase, generally.

My involvement in JavaRosa hasn't been as important in comparison so far, but I'm helping to improve low-level testing and outside-in testing.

What do you believe the top priorities for ODK are?
First and foremost, as a platform, it needs to offer easy, reliable and secure data collection, aggregation, and interchange.

As an Open Source Software project, it needs to be appealing to new contributors and have an easy onboarding process.

As a Software project, it needs to have an automated, solid and reliable release cycle. It also needs to have a strategy to maintain complexity under control.

How will you help the ODK community accomplish those priorities?
I have a professional background in big data analytics, including among others the intake, normalization & ETLs, that would come handy when discussing options for improving ODK's analytic capabilities.

As a recent member of ODK's community, I have also a fresh notion of a newcomer's experience, which places me in a good position for discussing options to make the onboarding process easier.

I also have a professional background automatizing software release processes using continuous integration software such as Jenkins or CircleCI, which would let me be useful when discussing ODK's various release needs.

Ultimately, I've been involved with big codebases for many years, and I've experienced what bad design and lack of architecture can do to a software project: as time passes, complexity rises which makes introducing changes progressively harder. This also takes a toll on all people involved, increasing their burnout and frustration, which is not good. I know about common design flaws and I can work around them by defining strategies to reduce complexity.

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

What other mobile data collection projects, social good projects, or open source projects are you involved with?
I've worked on small projects for the wilderness protection agencies Greenpeace and MarViva.

I've been CTO of VoxCivica, a citizen initiative which seeks to activate civil society and provide it with the tools and knowledge it requires to play a leading, responsible, conscious and critical role based on a firm commitment to both its own future and that of future generations.

I've participated in the redaction of a 2016's report on illegal fishing along the west coast of Africa, which had a huge impact, including policy changes and coverage from over 200 media outlets.

I'm acknowledged by the author of the book "Data Activism and Social Change" for helping to make sense of data and producing metrics and data analysis results for the book.

I'm a co-author of the paper "Funds for Sustainability: Questions about climate finance from the bottom up", which questions micro and macro data about how global climate adaptation and mitigation projects get financed.

I also participate in the local development community by organizing free seminars and workshops.

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

2

Could we fix my name to "Guillermo Gutiérrez"? :slight_smile:

2 Likes
3

Guillermo, can you say a bit more about your vision for an easier onboarding process for ODK?

1 Like
4

Hi Guillermo.

You have been doing a very great job in the last months with helping with Briefcase, Aggregate and Javarosa.
I see you very committed, present and working hard on fixing bug or developing new features.

Do you think getting involved even in the TSC wouldn’t be too much?

Do you think that be an active dev and be in the committee discussing the specs is a good choice? What could be the key advantage to have you in the TSC?

Aurelio

5

Hi Guillermo, thanks for applying! I like what you say about the bad design decisions > complexity > frustration cycle - could you give an example of a strategy for reducing codebase complexity?

6

can you say a bit more about your vision for an easier onboarding process for ODK?

First, I think I need to clarify that I'm referring to the onboarding process for new collaborators, especially those who want to help with code contributions.

I wouldn't say that I have a particular vision, but the experience with things that affect the onboarding process:

  • Sometimes there's no clear separation of the different workflows involved (testing and building, for example)
    • Maybe there's a list of steps that can be taken or a description of commands that can be executed, but there's no "narrative" about the bigger-picture purpose they serve
  • Sometimes there's a workflow defined but it doesn't cover the whole process from discussing the idea, to releasing a new feature and passing through implementation, reviews, testing, etc.
  • Sometimes the tools involved have become old and resources for learning them are scarce
  • Sometimes the tools are used in a non-standard fashion
  • Sometimes there are many tools involved, and it's not clear what "amount of knowledge" is required for each of them to follow the workflow (should I be an expert of tool X to even start working on this?)

These are some examples of things that make for a harder onboarding process, which I think they could be addressed by making the workflow simpler (fewer steps) or narrower (fewer options/less variation), continuously improving the documentation, or reducing the number of tools involved (or wrapping them inside a self-maintained thin layer).

I'd be glad to expand on any of these topics. Thanks for your question, @tomsmyth!

7

Do you think getting involved even in the TSC wouldn’t be too much?

I would have to make some adjustments, naturally, but I don't think that it would be too much.

Do you think that be an active dev and be in the committee discussing the specs is a good choice?

I believe that there is no separation of roles in software development. Ideally, discussing specs and implementing them are activities that should be done by every team member, and that's why I think that what the TSC does it's at the core of software development. Ultimately, being part of the TSC would give me have a wider perspective that would let me be more useful while writing code.

What could be the key advantage to have you in the TSC?

Being in close contact with the codebases gives me a good perspective that could be useful when estimating the effort for building new features and sequencing them.

Thanks for your questions, @aurdipas!

1 Like
8

could you give an example of a strategy for reducing codebase complexity?

Instead of making up a hypothetic example, I think a high-level description of what we're doing in Briefcase could work:

  • At a low-level, we're favoring immutable state and explicit side-effects.
    • At this level, complexity is materialized especially on a difficulty for understanding what's going on. Code that abuses mutation of local (or worse, global) state, or that performs non-explicit side-effects is hard to follow and changing it can have confusing, unexpected effects.
  • At mid-level, we are replacing (abused) class inheritance with object composition.
    • At this level, complexity often shows as a dissonance between code components and the business domain. Instead of having components that tell us about what the software does, we have components that tell us about how the software works.
    • Inheritance is supposed to be used to implement polymorphism, not for code reuse. Abusing inheritance produces code that is harder to change due to unwanted consequences in class hierarchies.
    • Composition, on the other hand, lets us be more specific about our intentions by producing smaller components that are better bound to Briefcase's domain, and that are easier to test too.
  • At a high-level:
    • At this level, we see complexity in the form of a highly-coupled mesh of components. The software is hard to evolve because changing one part of it can have consequences in many other parts.
    • We're building vertical slices of code for business use cases like pulling, pushing and exporting forms.
    • We're building horizontal slices of code for utility code and infrastructure services that are reused across verticals.
    • This lets us enforce healthy dependency relations between the different components of our architecture
    • We've also refactored all UI components to decouple any business logic present in them, often moving code coupled to vendor libraries (Swing) to vanilla Java alternatives that are more up-to-date, and easier to test and change.
      • Our next big goal in this front is to review all the messaging requirements of Briefcase and implement a vanilla Java events bus. This will also enable us to implement a more up-to-date concurrency model and to control background processes more effectively.

Thanks for your question, @adam.butler!

1 Like