Except how it picked the one:

const firstAutoProceededWithPlot = flowNodes.find(
  (n) =>
    n.type === "question" &&
    isAutoincrementEnabled(n.id) &&
    !!getAnswer(iterationCount, n.id)?.trim() &&
    /(plot)/i.test(`${n.name ?? ""} ${n.content?.text ?? ""}`),
);

The banner only renders if one of your pinned questions contains the literal string “plot” in its label or text. If it does, you get a header that reads “Your current plot.” If it doesn’t, the banner silently disappears.

I get the instinct. You look at the test experiments on your desk and half the questions are “Plot number”, “Plot ID”, “plot”; the UX team wants to declutter the banner; you ship the regex and move on.

The problem is that openJII isn’t a JII-only app. It’s a platform. And platforms don’t get to decide what their users call things.

The data, briefly

Reviewing the PR, my first reaction was a hunch: “what if they call it plant, or leaf, or translate it into anything else?” Hunches are cheap. They’re also not particularly persuasive on their own.

The next step would normally be expensive: go get numbers. Except the numbers were already sitting in a notebook nearby. A few weeks earlier I’d run a semantic analysis on 45,451 free-text questions across 19,658 PhotosynQ projects. PhotosynQ is the commercial plant-science measurement platform some of JII’s members helped build over the last decade. openJII is the open-source platform we run today, with feature parity and more, and JII retained ownership of the data, which is why this analysis was open to us in the first place.

The analysis answered a different research question (what metadata concepts do plant-science teams actually use?), but the answer also addressed the PR.

After three layers of cleanup (rule-based concept tagging across 22 concepts and 182 multilingual terms, fuzzy clustering on the top 500 normalised forms, and character-n-gram TF-IDF clustering on the long tail), here’s the cross-experiment ranking. Number of distinct projects that use each identifier concept:

Plot is sixth.

Not universal. Not even dominant. It sits behind treatment, rep, plant, leaf, and genotype, all ordinary enough that any “cleaner UX” argument that applies to plot applies equally to each of them.

And that’s just the English variants. The 1,729 projects that do use a plot concept use 291 distinct spellings: Plot, N PLOT, Plot no, Plot#, plot number, nplot. Spanish parcela and parcelas. French parcelle. German Parzelle. Portuguese parcela. Chinese xiao qu (小区). Russian Cyrillic. The hardcoded /plot/i match catches some of the English variants and literally none of the others.

Even when the keyword rules are widened to cover Spanish, French, German, Portuguese, and Chinese (as the full analysis does), only 62.8% of labels match any keyword concept at all. The remaining 37% are conversational (“Which treatment was applied?”, “¿Cuál es la variedad?”, “测量条件是什么?”), domain-specific (DAS, DAP, Cultivar, NDVI), or experiment-local. No regex on “plot” reaches them.

The platform lesson

The data makes a point more firmly than any gut check could: if you hardcode “plot” into your platform UI (whether it’s a regex, a conditional, or a string), you are deciding on behalf of every tenant that their experiments revolve around plots. A decade of PhotosynQ’s history shows the majority don’t. They revolve around treatments, replicates, plants, leaves, genotypes, whatever the scientist is actually measuring.

A platform doesn’t get to make that call.

The right fix isn’t to stretch the regex. It’s to move the semantics out of free text:

1. Typed question identifiers. Give the platform a concept of “this question is the plot identifier” (or the treatment identifier, or the replicate counter) as a property of the question itself, not a substring of its label. A researcher designing an experiment opts in explicitly.
2. A “show in summary” flag on the question. The same mechanism works for anyone’s workflow: treatment, rep, genotype, or something the platform authors never anticipated. You tell the platform which question matters; the platform doesn’t guess.
3. Internationalised banner copy. “Your current plot” becomes “Your current {label}”, sourced from the question’s actual name, in the researcher’s language.

These are easy decisions to skip in the name of shipping a small UX fix. They’re exactly the decisions that compound when you’re building a platform meant to serve teams beyond your own four walls.

Why I like this story

The PR review comment rewrote itself. Instead of “I think this is fragile”, I could paste a concrete ranking table and a chart. The discussion moved from “convince me” to “okay, what do we actually want to build?” in one round.

That’s the part I keep coming back to. Most of what a platform team decides never gets a clean public case study. Decisions get made in Slack, in a whiteboard session, under a deadline. The ones informed by real data are the exceptions.

When you’re building an open platform for science, the pressure to hardcode domain vocabulary into your UI is constant. And the cost shows up, quietly, in every experiment your platform fails to serve.

The case for a data-driven approach

When used effectively, data can catalyse informed decision-making, improve efficiency, allocate resources better, and accelerate project delivery. Honing in on key performance metrics (project timelines, bug rates, customer satisfaction) uncovers valuable insights into a process’s actual effectiveness. Adopting frameworks like DORA (DevOps Research and Assessment) provides a holistic perspective on a project’s health.

What you actually get from it

1. Cost reduction and improved efficiency. Data-driven decisions help identify inefficiencies, streamline processes, and eradicate unnecessary costs. The result is better resource utilisation, faster project delivery, and increased productivity.
2. Enhanced project management. Data analysis makes potential bottlenecks and risks visible, allowing the team to address them proactively. Better project planning, higher success rates.
3. Personalised customer experiences. Understanding customer behaviours and preferences via data analytics lets you tailor your services, enhancing satisfaction and fostering loyalty.

The common concerns

Despite the benefits, there are real concerns around privacy, data security, and bias. They’re manageable:

1. Privacy. Implement robust protocols to protect sensitive data; use anonymisation techniques to ensure individual privacy.
2. Bias in data analysis. Use diverse and representative datasets. Monitor regularly to identify and rectify bias as it arises.
3. Data security. Establish strict security protocols to prevent breaches; conduct regular audits to maintain data integrity.

Charting your course

1. Data analysis and metrics definition. Begin with a thorough analysis of your project timelines, bug rates, customer satisfaction levels, and any other relevant metrics. Define specific metrics that align with your organisation’s goals.
2. Implementation and integration. Develop data collection mechanisms and integrate data analysis tools into your existing infrastructure. Train your team to ensure a smooth transition.
3. Monitoring and continuous improvement. Watch the data, analyse it regularly, use the insights to inform decisions and improve where necessary.

Wrap-up

Adopting a data-driven approach can do wonders to make your software development process more efficient and customer-centric. By harnessing data analytics, you equip your team to make more informed decisions and elevate customer satisfaction.

This transformation isn’t a solo endeavour; it requires a collaborative effort, thorough training, and ongoing monitoring. Addressing potential concerns like privacy, security, and bias is essential to keep the approach ethical and effective.

In the midst of digital transformation, embracing data can unlock an organisation’s full potential, supercharge the customer experience, and drive business growth.

I cowrote the official reflection on the openJII blog with Jacky To. This is the more personal note: what stuck with me from the trainer side of the room, and what surprised me about the platform underneath.

Collaborative, not competitive

Most hackathons run on adrenaline and ranking. This one didn’t. Five interdisciplinary teams worked on shared field datasets (cowpea from Nigeria, barley from the Netherlands and Ethiopia, common bean and potato from the Netherlands) and presented progress to each other every day. Common obstacles got resolved in a corridor, not at a final-day judging panel. By day three, teams were openly comparing notes on the same dataset rather than guarding lines of attack, and that’s when the more interesting findings started to emerge.

The design choice paid off. Convergent findings across independent teams (different methods, different crops) carry much more weight than any single team’s result, and that convergence is what most of the participants will be co-authoring in the months after the event.

What teams actually found

Two threads stood out. First, several teams independently demonstrated that the temporal structure of photosynthesis measurements distinguishes genotypes more cleanly than canonical single-point parameters do. Looking at the trace itself, not just the extracted summaries, recovered genetic signal that standard analysis pipelines were quietly discarding. Second, multiple teams converged on previously underexplored portions of the fluorescence measurement (particularly later sections of the trace that no extraction pipeline currently uses) as the parts carrying the most heritable, breeding-relevant information.

The methodological corollary is uncomfortable for the field: the convention of compressing a rich time-resolved trace down to a handful of named scalar parameters is leaving a meaningful chunk of the genetic signal on the table. The hackathon didn’t prove this in a way that closes the question (that work is what the follow-on papers are for), but five teams independently arriving at variants of the same observation is hard to explain away.

Training plant breeders is humbling

The thing nobody tells you about being a trainer at an event like this: the participants are usually smarter than you are about the domain. Plant breeders, crop physiologists, statisticians, data scientists; they all came in with deep field expertise and reasonable expectations of what the data should look like. My job wasn’t to lecture; it was to help them get unstuck on tooling, on dataset shapes, on the mechanics of an analysis pipeline they wanted to build, and on the messy real-world details of working with field measurement data. The good moments were when a participant asked a question I couldn’t answer immediately, and we worked it out at a whiteboard together.

That’s a useful pattern for anyone running training inside a research community. The framing isn’t teach the experts; it’s be the friction-reducer the experts need to do their best work. Bring the tools, the structure, and the willingness to be wrong out loud, and let the domain depth come from the room.

What the platform did quietly

The piece I’m proudest of, with my technical-program-manager hat on, is what didn’t happen at the start of the event. Every multi-team data hackathon I’ve been near has lost its first day or two to the dull friction of access: whose laptop sees which file, whose Python install can read which format, whose VPN is talking to whose data lake. We didn’t. Datasets were curated and delivered through openJII running on Databricks, and 35 people walked into a shared, zero-setup analytical environment from the first morning.

That’s not glamorous. It is, however, exactly the kind of platform-level work that compounds. The same lakehouse pattern that runs openJII’s silver and gold layers in production was the substrate for the event, which means the analytical workflows the teams built during the week aren’t throwaway. They live on the same infrastructure that will receive the next round of field data. The hackathon didn’t end on Friday so much as graduate.

This is the through-line for me, professionally. The data-platform practice I launched at INFO grew up around Databricks; an agritech digital-transformation engagement adopted it on my recommendation; openJII runs on it now; and an event like this is what it looks like when that decision is paying off in the room rather than on a slide.

What it meant for openJII

For openJII specifically, the event was an early proof of concept for what the platform exists to do: take field datasets across geographies and crops, give people sensible primitives to work on them, and step out of the way. The follow-on plans (co-authored documentation, regional African sensor hubs, dataset sharing through the open-science platform) are the things that turn a one-off hackathon into community infrastructure.

It’s an unusual way to start a job. But the week made clear what good would look like: the questions the participants were already asking are the questions the platform needs to be ready for.

The trouble with Git hooks and Husky

You know the drill: you’re cranking out code, you’re in the zone, you want to save your progress, and you commit. Then a cascade of linting errors and failed tests slaps you in the face. So much for a smooth flow.

When you’re knee-deep in development it’s normal to commit code at various stages, and it’s not always going to be picture-perfect. Git hooks and Husky aren’t so forgiving; they block commits for the slightest transgression.

The kicker: those rules are easier to dodge than they look. git commit --no-verify skips them entirely. So we end up with a system that’s both painful to deal with and trivial to bypass, a worst-of-both-worlds for code quality.

Branch protection and PR-level checks

The alternative is to move enforcement to where it matters most: branch protection and PR-level checks.

With this approach you can commit code at any stage without being stonewalled by prematurely applied checks. The real scrutiny happens where it counts: when the code is about to enter the main codebase. And there’s no --no-verify escape hatch. Checks at the PR level are applied uniformly, keeping the codebase consistently clean and developer flow uninterrupted.

Final thoughts

I welcomed Git hooks and Husky as gatekeepers of code quality. After seeing them in action, I think we’re better off without them.

Enforce rules at the PR level. Let coding be about innovating and solving problems, not jumping through hoops on the way to a save point.