docs/technical: add git submodule roadmap

Present a roadmap that allows us to incrementally roll out Git submodule
functionality (instead of having to boil the ocean).

docs/technical/git-submodules.md

@@ -61,6 +61,66 @@ pointing to `<superproject-git-directory>/modules/<submodule-name>`. The latter
 is sometimes called the "absorbed form", and is Git's preferred mode of
 operation.
 
+## Roadmap
+
+Git submodules should be implemented in an order that supports an increasing set
+of workflows, with the goal of getting feedback early and often. When support is
+incomplete, jj should not crash, but instead provide fallback behavior and warn
+the user where needed.
+
+Colocated repositories will be supported where they are convenient, but they are
+not a high priority.
+
+This section should be treated as a set of guidelines, not a strict order of
+work.
+
+### Phase 1: Readonly submodules
+
+This includes work that inspects submodule contents but does not create new
+objects in the submodule. This requires a way to store submodules in a jj
+repository that supports readonly operations.
+
+#### Outcomes
+
+- Submodules can be cloned anew
+- New submodule commits can be fetched
+- Submodule history and branches can be viewed
+- Submodule contents are populated in the working copy
+- Superproject gitlink can be updated to an existing submodule commit
+- Conflicts in the superproject gitlink can be resolved to an existing submodule
+  commit
+
+### Phase 2: Snapshotting new changes
+
+This allows a user to write new contents to a submodule and its remote.
+
+#### Outcomes
+
+- Changes in the working copy can be recorded in a submodule commit
+- Submodule branches can be modified
+- Submodules and their branches can be pushed to their remote
+
+### Phase 3: Merging/rebasing/conflicts
+
+This allows merging and rebasing of superproject commits in a content-aware way
+(in contrast to Git, where only the gitlink commit ids are compared), as well as
+workflows that make resolving conflicts easy and sensible.
+
+This can be done in tandem with Phase 2, but will likely require a significant
+amount of design work on its own.
+
+#### Outcomes
+
+- Merged/rebased submodules result in merged/rebased working copy content
+- Merged/rebased working copy content can be committed, possibly by creating
+  sensible merged/rebased submodule commits
+- Merge/rebase between submodule and non-submodule gives a sensible result
+- Merge/rebase between submodule A and submodule B gives a sensible result
+
+### Phase ?: Possible, but unprioritized work
+
+- Rewriting submodule commits and updating superproject gitlinks accordingly
+
 ## Design
 
 ### Guiding principles