diff --git a/text/0000-roadmap-2017.md b/text/0000-roadmap-2017.md
new file mode 100644
index 00000000000..e39a835404e
--- /dev/null
+++ b/text/0000-roadmap-2017.md
@@ -0,0 +1,594 @@
+- Feature Name: N/A
+- Start Date: 2016-10-04
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+This RFC proposes the *2017 Rust Roadmap*, in accordance with [RFC 1728](https://github.com/rust-lang/rfcs/pull/1728). The goal of the roadmap is to lay out a vision for where the Rust project should be in a year's time. **This year's focus is improving Rust's *productivity*, while retaining its emphasis on fast, reliable code**. At a high level, by the end of 2017:
+
+* Rust should have a lower learning curve
+* Rust should have a pleasant edit-compile-debug cycle
+* Rust should provide a solid, but basic IDE experience
+* Rust should provide easy access to high quality crates
+* Rust should be well-equipped for writing robust, high-scale servers
+* Rust should have 1.0-level crates for essential tasks
+* Rust should integrate easily into large build systems
+* Rust's community should provide mentoring at all levels
+
+In addition, we should make significant strides in *exploring* two areas where
+we're not quite ready to set out specific goals:
+
+* Integration with other languages, running the gamut from C to JavaScript
+* Usage in resource-constrained environments
+
+The proposal is based on the [2016 survey], systematic outreach, direct conversations with individual Rust users, and an extensive [internals thread]. Thanks to everyone who helped with this effort!
+
+[2016 survey]: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html
+[internals thread]: https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/
+
+# Motivation
+[motivation]: #motivation
+
+There's no end of possible improvements to Rust—so what do we use to guide our
+thinking?
+
+The core team has tended to view our strategy not in terms of particular features or
+aesthetic goals, but instead in terms of **making Rust successful while staying
+true to its core values**. This basic sentiment underlies much of the proposed
+roadmap, so let's unpack it a bit.
+
+## Making Rust successful
+
+### The measure of success
+
+What does it mean for Rust to be successful? There are a lot of good answers to
+this question, a lot of different things that draw people to use or contribute
+to Rust. But regardless of our *personal* values, there's at least one clear
+measure for Rust's broad success: **people should be using Rust in
+production and reaping clear benefits from doing so**.
+
+- Production use matters for the obvious reason: it grows the set of
+  stakeholders with potential to invest in the language and ecosystem. To
+  deliver on that potential, Rust needs to be part of the backbone of some major
+  products.
+
+- Production use measures our *design* success; it's the ultimate reality
+  check. Rust takes a unique stance on a number of tradeoffs, which we believe
+  to position it well for writing fast and reliable software. The real test of
+  those beliefs is people using Rust to build large, production systems, on
+  which they're betting time and money.
+
+- The *kind* of production use matters. For Rust to truly be a success, there
+  should be clear-cut reasons people are employing it rather than another
+  language. Rust needs to provide crisp, standout benefits to the organizations
+  using it.
+
+The idea here is *not* about "taking over the world" with Rust; it's not about
+market share for the sake of market share. But if Rust is truly delivering a
+valuable new way of programming, we should be seeing that benefit in "the real
+world", in production uses that are significant enough to help sustain Rust's
+development.
+
+That's not to say we should expect to see this usage *immediately*; there's a
+long pipeline for technology adoption, so the effects of our work can take a
+while to appear. The framing here is about our long-term aims. We should be
+making investments in Rust today that will position it well for this kind of
+success in the future.
+
+### The obstacles to success
+
+At this point, we have a fair amount of data about how Rust is reaching its
+audience, through the [2016 survey], informal conversations, and explicit
+outreach to (pre-)production shops (writeup coming soon). The data from the
+survey is generally corroborated by these other venues, so let's focus on that.
+
+[2016 survey]: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html
+
+We asked both current and potential users what most stands in the way of their
+using Rust, and got some pretty clear answers:
+
+- 1 in 4: learning curve
+- 1 in 7: lack of libraries
+- 1 in 9: general “maturity” concerns
+- 1 in 19: lack of IDEs (1 in 4 non-users)
+- 1 in 20: compiler performance
+
+None of these obstacles is directly about the core language or `std`; people are
+generally happy with what the language offers today. Instead, the connecting
+theme is *productivity*—how quickly can I start writing real code? bring up a
+team? prototype and iterate? debug my code? And so on.
+
+In other words, our primary challenge isn't making Rust "better" in the
+abstract; it's making people *productive* with Rust. The need is most pronounced
+in the early stages of Rust learning, where we risk losing a large pool of
+interested people if we can't get them over the hump. Evidence from the survey
+and elsewhere suggests that once people do get over the initial learning curve,
+they tend to stick around.
+
+So how do we pull it off?
+
+### Core values
+
+Part of what makes Rust so exciting is that it attempts to eliminate some
+seemingly fundamental tradeoffs. The central such tradeoff is between safety
+and speed. Rust strives for
+
+- uncompromising reliability
+- uncompromising performance
+
+and delivers on this goal largely thanks to its fundamental concept of
+ownership.
+
+But there's a problem: at first glance, "productivity" and "learnability" may
+seem at odds with Rust's core goals. It's common to hear the refrain that
+"fighting with the borrow checker" is a rite of passage for Rustaceans. Or that
+removing papercuts would mean glossing over safety holes or performance cliffs.
+
+To be sure, there are tradeoffs here. But as above, if there's one thing the
+Rust community knows how to do, it's bending the curve around tradeoffs—memory
+safety without garbage collection, concurrency without data races, and all the
+rest. We have many examples in the language where we've managed to make a
+feature pleasant to use, while also providing maximum performance and
+safety—closures are a particularly good example, but there are
+[others](https://internals.rust-lang.org/t/roadmap-2017-productivity-learning-curve-and-expressiveness/4097).
+
+And of course, beyond the core language, "productivity" also depends a lot on
+tooling and the ecosystem. Cargo is one example where Rust's tooling provides a
+huge productivity boost, and we've been working hard on other aspects of
+tooling, like the
+[compiler's error messages](https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html),
+that likewise have a big impact on productivity. There's so much more we can be
+doing in this space.
+
+In short, **productivity should be a core value of Rust**. By the end of 2017,
+let's try to earn the slogan:
+
+- Rust: fast, reliable, productive—pick three.
+
+# Detailed design
+[design]: #detailed-design
+
+## Overall strategy
+
+In the abstract, reaching the kind of adoption we need means bringing
+people along a series of distinct steps:
+
+- Public perception of Rust
+- First contact
+- Early play, toy projects
+- Public projects
+- Personal investment
+- Professional investment
+
+We need to (1) provide "drivers", i.e. strong motivation to continue through the
+stages and (2) avoid "blockers" that prevent people from progressing.
+
+At the moment, our most immediate adoption obstacles are mostly about blockers,
+rather than a lack of drivers: there are people who see potential value in Rust,
+but worry about issues like productivity, tooling, and maturity standing in the
+way of use at scale. The roadmap proposes a set of goals largely angled at
+reducing these blockers.
+
+However, for Rust to make sense to use in a significant way in production, it
+also needs to have a "complete story" for one or more domains of use. The goals
+call out a specific domain where we are already seeing promising production use,
+and where we have a relatively clear path toward a more complete story.
+
+Almost all of the goals focus squarely on "productivity" of one kind or another.
+
+## Goals
+
+Now to the meat of the roadmap: the goals. Each is phrased in terms of a
+*qualitative vision*, trying to carve out what the *experience* of Rust should
+be in one year's time. The details mention some possible avenues toward a
+solution, but this shouldn't be taken as prescriptive.
+
+These goals are partly informed from the [internals thread] about the
+roadmap. That thread also posed a number of possible additional goals. Of
+course, part of the work of the roadmap is to allocate our limited resources,
+which fundamentally means not including some possible goals. Some of the most
+promising suggestions that didn't make it into the roadmap proposal itself are
+included in the Alternatives section.
+
+### Rust should have a lower learning curve
+
+Rust offers a unique value proposition in part because it offers a unique
+feature: its ownership model. Because the concept is not (yet!) a widespread one
+in other languages, it is something most people have to learn from scratch
+before hitting their stride with Rust. And that often comes on top of other
+aspects of Rust that may be less familiar. A common refrain is "the first couple
+of weeks are tough, but it's oh so worth it." How many people are bouncing off
+of Rust in those first couple of weeks? How many team leads are reluctant to
+introduce Rust because of the training needed? (1 in 4 survey respondents
+mentioned the learning curve.)
+
+Here are some strategies we might take to lower the learning curve:
+
+- **Improved docs**. While the existing Rust book has been successful, we've
+  learned a lot about teaching Rust, and there's a
+  [rewrite](http://words.steveklabnik.com/whats-new-with-the-rust-programming-language)
+  in the works. The effort is laser-focused on the key areas that trip people up
+  today (ownership, modules, strings, errors).
+
+- **Gathering cookbooks, examples, and patterns**. One way to quickly get
+  productive in a language is to work from a large set of examples and
+  known-good patterns that can guide your early work. As a community, we could
+  push crates to include more substantial example code snippets, and organize
+  efforts around design patterns and cookbooks. (See
+  [the commentary on the RFC thread](https://github.com/rust-lang/rfcs/pull/1774#issuecomment-269359228)
+  for much more detail.)
+
+- **Improved errors**. We've already made some
+  [big strides](https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html)
+  here, particularly for ownership-related errors, but there's surely more room
+  for improvement.
+
+- **Improved language features**. There are a couple of ways that the language
+  design itself can be oriented toward learnability. First, we can introduce new
+  features with an explicit eye toward
+  [how they will be taught](https://github.com/rust-lang/rfcs/pull/1636). Second,
+  we can improve existing features to make them easier to understand and use --
+  things like non-lexical lifetimes being a major example. There's already been
+  [some discussion on internals](https://internals.rust-lang.org/t/roadmap-2017-productivity-learning-curve-and-expressiveness/4097/)
+
+- **IDEs and other tooling**. IDEs provide a good opportunity for deeper
+  teaching. An IDE can visualize errors, for example *showing* you the lifetime
+  of a borrow. They can also provide deeper inspection of what's going on with
+  things like method dispatch, type inference, and so on.
+
+### Rust should have a pleasant edit-compile-debug cycle
+
+The edit-compile-debug cycle in Rust takes too long, and it's one of the
+complaints we hear most often from production users. We've laid down a good
+foundation with [MIR] (now turned on by default) and [incremental compilation]
+(which recently hit alpha). But we need to continue pushing hard to actually
+deliver the improvements. And to fully address the problem, **the improvement
+needs to apply to large Rust projects, not just small or mid-sized benchmarks**.
+
+To get this done, we're also going to need further improvements to the
+performance monitoring infrastructure, including more benchmarks. Note, though,
+that the goal is stated *qualitatively*, and we need to be careful with what we
+measure to ensure we don't lose sight of that goal.
+
+While the most obvious routes are direct improvements like incremental
+compilation, since the focus here is primarily on development (including
+debugging), another promising avenue is more usable debug builds. Production
+users often say "debug binaries are too slow to run, but release binaries are
+too slow to build". There may be a lot of room in the middle.
+
+Depending on how far we want to take IDE support (see below), pushing
+incremental compilation up through the earliest stages of the compiler may also
+be important.
+
+[MIR]: https://blog.rust-lang.org/2016/04/19/MIR.html
+[incremental compilation]: https://blog.rust-lang.org/2016/09/08/incremental.html
+
+### Rust should provide a solid, but basic IDE experience
+
+For many people—even whole organizations—IDEs are an essential part of the
+programming workflow. In the survey, 1 in 4 respondents mentioned requiring IDE
+support before using Rust seriously. Tools like [Racer] and the [IntelliJ] Rust
+plugin have made great progress this year, but [compiler integration] in its
+infancy, which limits the kinds of tools that general IDE plugins can provide.
+
+The problem statement here says "solid, but basic" rather than "world-class" IDE
+support to set realistic expectations for what we can get done this year. Of
+course, the precise contours will need to be driven by implementation work, but
+we can enumerate some basic constraints for such an IDE here:
+
+- It should be **reliable**: it shouldn't crash, destroy work, or give inaccurate
+  results in situations that demand precision (like refactorings).
+- It should be **responsive**: the interface should never hang waiting on the
+  compiler or other computation. In places where waiting is required, the
+  interface should update as smoothly as possible, while providing
+  responsiveness throughout.
+- It should provide **basic functionality**. At a minimum, that's: syntax
+  highlighting, basic code navigation (e.g. go-to-definition), code completion,
+  build support (with Cargo integration), error integration, and code
+  formatting.
+
+Note that while some of this functionality is available in existing IDE/plugin
+efforts, a key part of this initiative is to (1) lay the foundation for plugins
+based on compiler integration (2) pull together existing tools into a single
+service that can integrate with multiple IDEs.
+
+[Racer]: https://github.com/phildawes/racer
+[IntelliJ]: https://intellij-rust.github.io/
+[compiler integration]: https://internals.rust-lang.org/t/introducing-rust-language-server-source-release/4209/
+
+### Rust should provide easy access to high quality crates
+
+Another major message from the survey and elsewhere is that Rust's ecosystem,
+while growing, is still immature (1 in 9 survey respondents mentioned
+this). Maturity is not something we can rush. But there are steps we can take
+across the ecosystem to help improve the quality and discoverability of crates,
+both of which will help increase the overall sense of maturity.
+
+Some avenues for quality improvement:
+
+- Provide stable, extensible test/bench frameworks.
+- Provide more push-button CI setup, e.g. have `cargo new` set up Travis/Appveyor.
+- Restart the [API guidelines](http://aturon.github.io/) project.
+- Use badges on crates.io to signal various quality metrics.
+- Perform API reviews on important crates.
+
+Some avenues for discoverability improvement:
+
+- Adding categories to crates.io, making it possible to browse lists like
+  "crates for parsing".
+- More sophisticated ranking and/or curation.
+
+A number of ideas along these lines were discussed in the [Rust Platform thread].
+
+[Rust Platform thread]: https://internals.rust-lang.org/t/proposal-the-rust-platform/3745
+
+### Rust should be well-equipped for writing robust, high-scale servers
+
+The biggest area we've seen with interest in production Rust so far is the
+server, particularly in cases where high-scale performance, control, and/or
+reliability are paramount. At the moment, our ecosystem in this space is
+nascent, and production users are having to build a lot from scratch.
+
+Of the specific domains we might target for having a more complete story, Rust
+on the server is the place with the clearest direction and momentum. In a year's
+time, it's within reach to drastically improve Rust's server ecosystem and the
+overall experience of writing server code. The relevant pieces here include
+foundations for async IO, language improvements for async code ergonomics,
+shared infrastructure for writing services (including abstractions for
+implementing protocols and middleware), and endless interfaces to existing
+services/protocols.
+
+There are two reasons to focus on the robust, high-scale case. Most importantly,
+it's the place where Rust has the clearest value proposition relative to other
+languages, and hence the place where we're likeliest to achieve significant,
+quality production usage (as discussed earlier in the RFC). More generally, the
+overall server space is *huge*, so choosing a particular niche provides
+essential focus for our efforts.
+
+### Rust should have 1.0-level crates for essential tasks
+
+Rust has taken a decidedly lean approach to its standard library, preferring for
+much of the typical "batteries included" functionality to live externally in the
+crates.io ecosystem. While there are a lot of benefits to that approach, it's
+important that we do in fact provide the batteries somewhere: we need 1.0-level
+functionality for essential tasks. To pick just one example, the `rand` crate
+has suffered from a lack of vision and has effectively stalled before reaching
+1.0 maturity, despite its central importance for a non-trivial part of the
+ecosystem.
+
+There are two basic strategies we might take to close these gaps.
+
+The first is to identify a broad set of "essential tasks" by, for example,
+finding the commonalities between large "batteries included" standard libraries,
+and focus community efforts on bolstering crates in these areas. With sustained
+and systematic effort, we can probably help push a number of these crates to 1.0
+maturity this year.
+
+A second strategy is to focus specifically on tasks that play to Rust's
+strengths. For example, Rust's potential for [fearless concurrency] across a
+range of paradigms is one of the most unique and exciting aspects of the
+language. But we aren't fully delivering on this potential, due to the
+immaturity of libraries in the space. The response to work in this space, like
+the recent [futures library announcement], suggests that there is a lot of
+pent-up demand and excitement, and that this kind of work can open a lot of
+doors for Rust. So concurrency/asynchrony/parallelism is one segment of the
+ecosystem that likely deserves particular focus (and feeds into the high-scale
+server goal as well); there are likely others.
+
+[fearless concurrency]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html
+[futures library announcement]: http://aturon.github.io/blog/2016/08/11/futures/
+
+### Rust should integrate easily into large build systems
+
+When working with larger organizations interested in using Rust, one of the
+first hurdles we tend to run into is fitting into an existing build
+system. We've been exploring a number of different approaches, each of which
+ends up using Cargo (and sometimes `rustc`) in different ways, with different
+stories about how to incorporate crates from the broader crates.io ecosystem.
+Part of the issue seems to be a perceived overlap between functionality in Cargo
+(and its notion of compilation unit) and in ambient build systems, but we have
+yet to truly get to the bottom of the issues—and it may be that the problem is
+one of communication, rather than of some technical gap.
+
+By the end of 2017, this kind of integration should be *easy*: as a community,
+we should have a strong understanding of best practices, and potentially build
+tooling in support of those practices. And of course, we want to approach this
+goal with Rust's values in mind, ensuring that first-class access to the
+crates.io ecosystem is a cornerstone of our eventual story.
+
+### Rust's community should provide mentoring at all levels
+
+The Rust community is awesome, in large part because of how welcoming it is. But
+we could do a lot more to help grow people into roles in the project, including
+pulling together important work items at all level of expertise to direct people
+to, providing mentoring, and having a clearer on-ramp to the various official
+Rust teams. Outreach and mentoring is also one of the best avenues for
+increasing diversity in the project, which, as the survey demonstrates, has a
+lot of room for improvement.
+
+While there's work here for *all* the teams, the community team in particular
+will continue to focus on early-stage outreach, while other teams will focus on
+leadership onboarding.
+
+## Areas of exploration
+
+The goals above represent the steps we think are most essential to Rust's
+success in 2017, and where we are in a position to lay out a fairly concrete vision.
+
+Beyond those goals, however, there are a number of areas with strong potential
+for Rust that are in a more exploratory phase, with subcommunities already
+exploring the frontiers. Some of these areas are important enough that we want
+to call them out explicitly, and will expect ongoing progress over the course of
+the year. In particular, the subteams are expected to proactively help organize
+and/or carry out explorations in these areas, and by the end of the year we
+expect to have greater clarity around Rust's story for these areas, putting us
+in a position to give more concrete goals in subsequent roadmaps.
+
+Here are the two proposed Areas of Exploration.
+
+### Integration with other languages
+
+Other languages here includes "low-level" cases like C/C++, and "high-level"
+cases like JavaScript, Ruby, Python, Java and C#. Rust adoption often depends on
+being able to start using it *incrementally*, and language integration is often
+a key to doing so -- an intuition substantiated by data from the survey and
+commercial outreach.
+
+Rust's core support for interfacing with C is fairly strong, but wrapping a C
+library still involves tedious work mirroring declarations and writing C shims
+or other glue code. Moreover, many projects that are ripe for Rust integration
+are currently using C++, and interfacing with those effectively requires
+maintaining an alternative C wrapper for the C++ APIs. This is a problem both
+for Rust code that wants to employ existing libraries and for those who want to
+integrate Rust into existing C/C++ codebases.
+
+For interfacing with "high-level" languages, there is the additional barrier of
+working with a runtime system, which often involves integration with a garbage
+collector and object system. There are ongoing projects on these fronts, but
+it's early days and there are still a lot of open questions.
+
+Some potential avenues of exploration include:
+
+- Continuing work on bindgen, with focus on seamless C and eventually C++
+  support. This may involve some FFI-related language extensions (like richer
+  `repr`).
+- Other routes for C/C++ integration.
+- Continued expansion of existing projects like
+  [Helix](https://github.com/rustbridge/helix) and
+  [Neon](https://github.com/dherman/neon), which may require some language
+  enhancements.
+- Continued work on [GC integration hooks](http://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/)
+- Investigation of object system integrations, including DOM and
+  [GObject](https://internals.rust-lang.org/t/rust-and-gnome-meeting-notes/4339).
+
+### Usage in resource-constrained environments
+
+Rust is a natural fit for programming resource-constrained devices, and
+there are some [ongoing efforts](https://github.com/rust-embedded/) to better
+organize work in this area, as well as a
+[thread](https://internals.rust-lang.org/t/roadmap-2017-needs-of-no-std-embedded-developers/4096)
+on the current significant problems in the domain. Embedded devices likewise
+came up repeatedly in the internals thread. It's also a potentially huge
+market. At the moment, though, it's far from clear what it will take to achieve
+significant production use in the embedded space. It would behoove us to try to
+get a clearer picture of this space in 2017.
+
+Some potential avenues of exploration include:
+
+- Continuing work on [rustup](https://github.com/rust-lang-nursery/rustup.rs/),
+  [xargo](https://github.com/japaric/xargo) and similar tools for easing
+  embedded development.
+- Land ["std-aware Cargo"](https://github.com/rust-lang/rfcs/pull/1133), making
+  it easier to experiment with ports of the standard library to new platforms.
+- Work on
+  [scenarios](https://internals.rust-lang.org/t/fleshing-out-libstd-scenarios/4206)
+  or other techniques for cutting down `std` in various ways, depending on
+  platform capabilities.
+- Develop a story for failable allocation in `std` (i.e., without aborting when
+  out of memory).
+
+## Non-goals
+
+Finally, it's important that the roadmap "have teeth": we should be focusing on
+the goals, and avoid getting distracted by other improvements that, whatever
+their appeal, could sap bandwidth and our ability to ship what we believe is
+most important in 2017.
+
+To that end, it's worth making some explicit *non*-goals, to set expectations
+and short-circuit discussions:
+
+- No major new language features, except in service of one of the goals. Cases
+  that have a very strong impact on the "areas of support" may be considered
+  case-by-case.
+
+- No major expansions to `std`, except in service of one of the goals. Cases
+  that have a very strong impact on the "areas of support" may be considered
+  case-by-case.
+
+- No Rust 2.0. In particular, no changes to the language or `std` that could be
+  perceived as "major breaking changes". We need to be doing everything we can
+  to foster maturity in Rust, both in reality and in perception, and ongoing
+  stability is an important part of that story.
+
+# Drawbacks and alternatives
+[drawbacks]: #drawbacks
+
+It's a bit difficult to enumerate the full design space here, given how much
+there is we could potentially be doing. Instead, we'll take a look at some
+alternative high-level strategies, and some additional goals from the internals
+thread.
+
+## Overall strategy
+
+At a high level, though, the biggest alternatives (and potential for drawbacks)
+are probably at the strategic level. This roadmap proposal takes the approach of
+(1) focusing on reducing clear blockers to Rust adoption, particularly connected
+with productivity and (2) choosing one particular "driver" for adoption to
+invest in, namely high-scale servers. The balance between blocker/driver focus
+could be shifted—it might be the case that by providing more incentive to use
+Rust in a particular domain, people are willing to overlook some of its
+shortcomings.
+
+Another possible blind spot is the conservative take on language expansion,
+particularly when it comes to productivity. For example, we could put much
+greater emphasis on "metaprogramming", and try to complete Plugins 2.0
+in 2017. That kind of investment *could* pay dividends, since libraries can do
+amazing things with plugins that could draw people to Rust. But, as above, the
+overall strategy of reducing blockers assumes that what's most needed isn't more
+flashy examples of Rust's power, but rather more bread-and-butter work on
+reducing friction, improving tooling, and just making Rust easier to use across
+the board.
+
+The roadmap is informed by the survey, systematic outreach, numerous direct
+conversations, and general strategic thinking. But there could certainly be
+blind spots and biases. It's worth double-checking our inputs.
+
+## Other ideas from the internals thread
+
+Finally, there were several strong contenders for additional goals from the internals
+thread that we might consider. To be clear, these are not currently part of the
+proposed goals, but we may want to consider elevating them:
+
+- A goal explicitly for
+  [systematic expansion of commercial use](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/68);
+  this proposal takes that as a kind of overarching idea for all of the goals.
+
+- A goal for Rust infrastructure, which came
+  [up](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/9)
+  [several](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/68)
+  [times](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/5).
+  While this goal seems quite worthwhile in terms of paying dividends across the
+  project, in terms of our current subteam makeup it's hard to see how to
+  allocate resources toward this goal without dropping other important goals. We
+  might consider forming a dedicated infrastructure team, or somehow organizing
+  and growing our bandwidth in this area.
+
+- A goal for progress in areas like
+  [scientific computing](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/52),
+  [HPC](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/48).
+
+After an exhaustive look at the thread, the remaining proposals are in one way
+or another covered somewhere in the discussion above.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+The main unresolved question is how to break the given goals into more
+deliverable pieces of work, but that's a process that will happen after the
+overall roadmap is approved.
+
+Are there other "areas of support" we should consider? Should any of these areas
+be elevated to a top-level goal (which would likely involve cutting back on some
+other goal)?
+
+Should we consider some loose way of organizing "special interest groups" to
+focus on some of the priorities not part of the official goal set, but where
+greater coordination would be helpful? This was suggested
+[multiple](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/70)
+[times](https://internals.rust-lang.org/t/setting-our-vision-for-the-2017-cycle/3958/135).
+
+Finally, there were several strong contenders for additional goals from the
+internals thread that we might consider, which are listed at the end of the
+goals section.