Note existing work on visibility of design efforts

Also note that we want to explicitly meet both
 * community members (who may not want and perhaps should not visit issue
   tracker for the "source" of truth at a larger scale)
 * project members (for whom the issue tracker may also be too fine-grained, in
   some cases)

Author: Mark-Simulacrum

text/0000-roadmap-2020.md

@@ -190,6 +190,24 @@ status.  Things like the Inside Rust blog are helpful here, and we
 should look for other ways to incorporate lightweight status updates
 into our workflows.
 
+There are a number of possible sources for this information today, such as
+feature gate labels and tracking implementation history in tracking issues. Most
+of these have not been formally introduced to all teams nor have they been
+described in any particular nature; this experimentation has yielded mostly
+positive results. However, it does not do a good job of targeting end-users who
+have never visited the Rust issue tracker. We want to actively target community
+members who are not actively involved in the teams. In doing so, we should also
+avoid increasing the busywork factor on teams.
+
+It has been noted by multiple team members that even those who are *very*
+involved in the project (core team members, for example) frequently note that
+they also do not have a good sense of the current project goals and priorities.
+So we are also not meeting the needs for team members to stay up to date with
+current initiatives.
+
+There is clearly room to innovate on both fronts, and existing experimentation
+should also not be overlooked.
+
 ### Increase mentoring, leadership, and organizational bandwidth
 
 One common challenge for us is that we seem to lack enough people to