Installing Dependencies and Completing a Learning Exercise Are Separate Milestones

When a learner completes a ROS 2 exercise and marks the milestone as done, there is a quiet assumption that the environment is settled and the learning evidence is captured. In practice, two very different kinds of completion are being conflated: the resolution of external dependencies and the demonstration of application-level understanding. One tells you that the system can find what it needs; the other tells you that the learner can reason about what the system is doing. Treating them as interchangeable produces progress notes that look clean but answer the wrong question.

What Dependency Resolution Actually Confirms

Dependency management tools operate at the level of package manifests and platform mappings. rosdep is a meta-package manager that uses its own knowledge of the system to find appropriate packages for installation on a particular platform. The dependencies declared in package.xml files are referred to as "rosdep keys." rosdep identifies and installs dependencies to build or install a package, but this process confirms that dependencies were located and installation was attempted, not that runtime behavior was verified. A progress note that records only "dependencies resolved" has documented a procurement step, not a behavioural outcome.

The ROS 2 installation documentation distinguishes binary packages from building from source and describes platform considerations. This article draws an editorial distinction between completing an installation step and demonstrating an application-level learning goal. The documentation’s installation choices do not decide whether a learner met a particular course objective. A progress note should name the goal and record the observation used to assess it.

Why Application-Level Evidence Requires Its Own Record

Application-level learning evidence is behavioural. It answers whether the learner can configure, invoke, observe, and interpret a running system. This kind of evidence is not produced by a successful install command; it is produced by a sequence of actions whose outcomes can be inspected. A hypothetical learner progress note might read: "Configured a launch file, observed topic output, and identified a mismatch between expected and actual message structure." That note contains a claim about what was seen and what was concluded. Both installation and application claims can be checked, but they require different observations.

If a learner returns to an exercise and encounters a problem, a note that records both environment work and observed behaviour can give the next review a clearer starting point. It will not automatically identify the cause. While reading this site’s technical articles, keep procedural descriptions separate from evidence that an individual exercise was completed. That same separation can be reflected in a learner’s own progress fields.

The Misconception of the Green Check Mark

A common misconception is that a green check mark next to a dependency list constitutes proof that the system is ready to learn from. The check mark confirms that a resolver ran and produced output. It does not confirm that the output was exercised in the context of the exercise. For example, a package may declare a dependency that is only invoked under specific configuration conditions. If the exercise never triggers those conditions, the dependency is present but unverified. The progress note records a satisfied manifest, not a tested capability.

A successful run is an observation at a particular point in a learning activity. Whether it establishes the intended competence depends on the stated goal and the explanation the learner can give. The article archive is a source of related reading, not a collection of verified student outcomes. A useful note can record what was observed, what the learner inferred and what remains uncertain, without claiming that one execution proves lasting mastery.

Designing a Progress Note That Separates the Two

A useful progress note distinguishes three layers: environment state, action taken, and observation recorded. The environment state layer may note that dependency resolution completed, which is useful for reproducibility. The action layer describes what the learner configured or invoked. The observation layer records what was seen and what was concluded. Keeping these separate allows a reader to ask distinct questions: Was the environment adequate? Was the action appropriate? Was the interpretation sound?

In a hypothetical scenario, a learner working through a ROS 2 discovery exercise might write: "Environment: rosdep identified all declared dependencies for the target platform. Action: launched nodes with specific configuration parameters. Observation: expected behavior did not occur; configuration review indicated a parameter mismatch." This note separates the dependency claim from the behavioural observation. It also flags an open question rather than closing the milestone prematurely. The note is less satisfying as a completion marker but more useful as a learning record.

Questions to Ask Before Closing a Milestone

Before marking a milestone complete, it helps to ask whether the evidence present is environmental or behavioural. Was a dependency resolved, or was a runtime path exercised? Was a command run, or was its output interpreted? Was a configuration written, or was its effect observed? These questions do not add bureaucracy; they prevent the accumulation of milestones that look complete but cannot support later reasoning.

It also helps to ask what would need to be true for this milestone to be considered failed. If the only failure condition is "dependency not found," the milestone is environmental. If the failure condition includes "learner cannot explain the observed output," the milestone is behavioural. Dependency resolution is a prerequisite, not a substitute for demonstrating understanding.

The Editorial Function of a Progress Note

A progress note is not a log file. A log file records what happened; a progress note records what was learned and what remains uncertain. The distinction between dependency resolution and application-level evidence is, at root, a distinction between two kinds of claims. One claim is about the state of the system; the other is about the state of the learner's understanding. Conflating them produces notes that may be accurate about the system but incomplete about the learner.

Editorial discipline in writing these notes means resisting the temptation to let a successful install stand in for a successful exercise. It means recording what was seen, what was expected, and where the two diverged. It means treating a resolved dependency as the beginning of a learning record, not the end of one. The result is a set of milestones that can be read months later and still answer the question that matters: not just whether the system was ready, but whether the learner was.