diff --git a/README.md b/README.md
index bc0f2bf095..44fe174851 100644
--- a/README.md
+++ b/README.md
@@ -137,6 +137,9 @@ pull request (PR) mechanism.
* [CONTRIBUTING](CONTRIBUTING.md) has detailed instructions about the
development process.
+* [ROADMAP](docs/ROADMAP.md) is a high-level overview of the current
+ development priorities for the next annual release, expected in September,
+ 2024.
* [RELEASING](RELEASING.md) explains our policies and procedures for making
releases. We have a major, possibly-compatibility-breaking, release annually
in September/October, and minor bug fix and safe feature addition release at
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
new file mode 100644
index 0000000000..62db51a2a7
--- /dev/null
+++ b/docs/ROADMAP.md
@@ -0,0 +1,102 @@
+
+
+
+# OpenImageIO Roadmap
+
+This describes the major tasks we hope to accomplish on the road to
+OpenImageIO 3.0, which should be released circa September 2024. Where there
+are links to issue, please read the issue for more extensive description and
+discussion about the modifications required.
+
+OpenImageIO is fairly mature and one could argue that its being used
+extensively in production for 15 years puts an empirical limit on the
+criticality of any "missing" feature. So while we welcome new features, those
+that don't break old APIs can be added in any release, so there are no "must
+have features" that are required to be completed for this release.
+
+However, 2.x -> 3.0 is one of the rare opportunities for things that might
+break backward compatibility, i.e., that might require actual source code
+changes to software that calls OIIO. Since this happens only every 5 years or
+so, this means that for many such changes (including removing previously
+deprecated API calls), it is a matter of doing in now or waiting several
+years.
+
+
+
+## Dependency modernization ([project](https://github.com/orgs/AcademySoftwareFoundation/projects/28))
+
+We would like to pull forward a whole lot of other dependencies so that their
+minimums are somewhere in the "released 3-5 years ago" range. The full list of
+our dependencies [can be found
+here](https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4151).
+
+See the [Dependency proposal wiki page](https://github.com/AcademySoftwareFoundation/OpenImageIO/discussions/4151)
+
+* [ ] Big required upgrades with potentially widespread impact on the code base
+ - [ ] C++17 [#4155](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4155)
+ - [ ] Python 3.7 [#4157](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4157)
+ - [ ] OpenEXR/Imath 3.1 [#4156](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4156)
+
+* [ ] Miscellaneous optional upgrades whose changes will be very localized
+
+ This isn't a complete list, nor do we need to do all of these, but the
+ highest priorities are:
+
+ - [ ] CMake 3.18 (from 3.15). Or possibly newer if there's a good reason? (3.19 or 3.20 are also reasonable.)
+ - [ ] OpenColorIO 2.0, or possibly 2.1 (from 1.1). Open for debate: should it be a required dependency rather than optional?
+ - [ ] fmt 8.0 (from 7.0), which has many improvements.
+ - [ ] GIFlib 5.0 (from 4.0), which adds thread safety.
+ - [ ] libheif 1.11 (from 1.3), which supports many additional features of that format.
+ - [ ] WebP 1.2 (from 0.6) which lets us use their exported CMake configs and retire FindWebP.cmake.
+ - [ ] pybind11 2.6 or 2.7 (from 2.4).
+
+
+- [ ] [#4156](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4156) Eliminate the last few places where we use Boost and eliminate it as a dependency.
+
+
+
+
+## API Modernization
+
+- [ ] [#4159](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4159) Using span and string_view instead of raw pointers
+
+ Scrub the APIs to find where we have API calls that take a pointer and size
+ (or worse -- just a pointer and an assumption about the size), and instead
+ use `span` / `cspan` for things that are like arrays, and
+ `string_view` for things that are like strings.
+
+- [ ] [#4160](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4160)
+ Using named keyword/value lists more extensively in imagebufalgo.h
+
+- [ ] Deprecate as much as possible of the old printf-style string formatting we use internally, instead using the fmt/std::format style everywhere. This includes changing Strutil::format to alias to Strutil::fmt::format (currently it aliases to Strutil::old::format, which uses printf style).
+
+- [ ] Remove deprecated API elements
+
+ Hunt for things marked DEPRECATED and try to get rid of them where possible.
+ If we can't remove them, at least make sure they are marked as
+ `OIIO_DEPRECATED` (or `[[deprecated]]` in modern C++).
+
+
+## The rest
+
+Other initiatives we hope to have completed by the time of this next
+major release:
+
+- [ ] [#4164](https://github.com/AcademySoftwareFoundation/OpenImageIO/issues/4164) Better color management
+
+ Regardless of OCIO availability, version, or contents of any configs, have universal support for the [canonical color spaces](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#color-spaces-and-color-management-systems) that seem to be the common consensus of ACES, MaterialX, and USD.
+- [ ] Preliminary Rust bindings for most of the OpenImageIO APIs.
+- [ ] Python wheel construction so `pip install openimageio` will be an easy way
+ for users to install the whole banana.
+
+If there is something you think should be on the roadmap for the next major
+release but is not, please open an issue or discussion to propose it, or
+bring it up at a TSC meeting, or on the mail list or Slack channel.
+
+
+## Parking
+
+Here is where we will put things that definitely should be on the roadmap, but
+that need not be completed in time for the fall 2024 release of OIIO 3.0.
+
+...