admin: Add a ROADMAP document (AcademySoftwareFoundation#4161)

Signed-off-by: Larry Gritz <lg@larrygritz.com>

Author: lgritz

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

docs/ROADMAP.md

@@ -0,0 +1,102 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenImageIO Project. -->
+
+# 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.
+
+<br>
+
+
+## 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<T>` / `cspan<T>` 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.
+
+...