content: convert to Markdown-enabled present inputs

Converted blog to Markdown-enabled present (CL 222846)
using present2md (CL 222847).

For golang/go#33955.

Change-Id: Ib39fa1ddd9a46f9c7a62a2ca7b96e117635553e8
Reviewed-on: https://go-review.googlesource.com/c/blog/+/222848
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

1 files changed, 29 insertions, 28 deletions

diff --git a/content/go2-here-we-come.article b/content/go2-here-we-come.article
index 0f749de..c7927ae 100644
--- a/content/go2-here-we-come.article
+++ b/content/go2-here-we-come.article
@@ -1,14 +1,15 @@
-Go 2, here we come!
+# Go 2, here we come!
 29 Nov 2018
 Tags: go2, proposals, community
+Summary: At GopherCon 2017, Russ Cox officially started the thought process on the next big version of Go with his talk [The Future of Go](https://www.youtube.com/watch?v=0Zbh_vmAKvk) ([blog post](https://blog.golang.org/toward-go2)). We have called this future language informally Go 2, even though we understand now that it will arrive in incremental steps rather than with a big bang and a single major release. Still, Go 2 is a useful moniker, if only to have a way to talk about that future language, so let’s keep using it for now.
 
 Robert Griesemer
 
-* Background
+## Background
 
 At GopherCon 2017, Russ Cox officially started the thought process on the
-next big version of Go with his talk [[https://www.youtube.com/watch?v=0Zbh_vmAKvk][The Future of Go]]
-([[https://blog.golang.org/toward-go2][blog post]]). We have
+next big version of Go with his talk [The Future of Go](https://www.youtube.com/watch?v=0Zbh_vmAKvk)
+([blog post](https://blog.golang.org/toward-go2)). We have
 called this future language informally Go 2, even though we understand now
 that it will arrive in incremental steps rather than with a big bang and a
 single major release. Still, Go 2 is a useful moniker, if only to have a way
@@ -21,7 +22,7 @@ After almost 10 years of exposure, we have
 learned a lot about the language and libraries that we didn’t know in the
 beginning, and that was only possible through feedback from the Go community.
 
-In 2015 we introduced the [[https://golang.org/s/proposal][proposal process]]
+In 2015 we introduced the [proposal process](https://golang.org/s/proposal)
 to gather a specific kind of feedback: proposals for language and library
 changes. A committee composed of senior Go team members has been reviewing,
 categorizing, and deciding on incoming proposals on a regular basis. That
@@ -33,28 +34,28 @@ takes the bigger picture of Go 2 into account.
 
 It is now time to act on the Go 2 proposals, but to do this we first need a plan.
 
-* Status
+## Status
 
 At the time of writing, there are around 120
-[[https://github.com/golang/go/issues?page=1&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2&utf8=%E2%9C%93][open issues labeled Go 2 proposal]].
+[open issues labeled Go 2 proposal](https://github.com/golang/go/issues?page=1&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2&utf8=%E2%9C%93).
 Each of them proposes a significant library or language change, often one
 that does not satisfy the existing
-[[https://golang.org/doc/go1compat][Go 1 compatibility guarantee]].
+[Go 1 compatibility guarantee](https://golang.org/doc/go1compat).
 Ian Lance Taylor and I
 have been working through these proposals and categorized them
-([[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3AGo2Cleanup][Go2Cleanup]],
-[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3ANeedsDecision][NeedsDecision]],
+([Go2Cleanup](https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3AGo2Cleanup),
+[NeedsDecision](https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aproposal+label%3AGo2+label%3ANeedsDecision),
 etc.) to get an idea of what’s there and to make it easier to
 proceed with them. We also merged related proposals and closed the ones which
 seemed clearly out of the scope of Go, or were otherwise unactionable.
 
 Ideas from the remaining proposals will likely influence Go 2’s libraries
 and languages. Two major themes have emerged early on: support for better
-error handling, and generics. [[https://blog.golang.org/go2draft][Draft designs]]
+error handling, and generics. [Draft designs](https://blog.golang.org/go2draft)
 for these two areas have been
 published at this year’s GopherCon, and more exploration is needed.
 
-But what about the rest? We are [[https://blog.golang.org/toward-go2][constrained]]
+But what about the rest? We are [constrained](https://blog.golang.org/toward-go2)
 by the fact that we now have
 millions of Go programmers and a large body of Go code, and we need to
 bring it all along, lest we risk a split ecosystem. That means we cannot
@@ -62,19 +63,19 @@ make many changes, and the changes we are going to make need to be chosen
 carefully. To make progress, we are implementing a new proposal evaluation
 process for these significant potential changes.
 
-* Proposal evaluation process
+## Proposal evaluation process
 
 The purpose of the proposal evaluation process is to collect feedback on
 a small number of select proposals such that a final decision can be made.
 The process runs more or less in parallel to a release cycle and consists
 of the following steps:
 
-1. _Proposal_selection_. The Go team selects a small number of
-[[https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal][Go 2 proposals]]
+1. _Proposal selection_. The Go team selects a small number of
+[Go 2 proposals](https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal)
 that seem worth considering for acceptance, without making a final decision.
 See below for more on the selection criteria.
 
-2. _Proposal_feedback_. The Go team sends out an announcement listing the selected
+2. _Proposal feedback_. The Go team sends out an announcement listing the selected
 proposals. The announcement explains to the community the tentative intent to
 move forward with the selected proposals and to collect feedback for each
 of them. This gives the community a chance to make suggestions and express
@@ -84,12 +85,12 @@ concerns.
 The target for these significant language and library changes is to have
 them ready to submit on day 1 of an upcoming release cycle.
 
-4. _Implementation_feedback_. During the development cycle, the Go team and
+4. _Implementation feedback_. During the development cycle, the Go team and
 community have a chance to experiment with the new features and collect
 further feedback.
 
-5. _Launch_decision_. At the end of the three month
-[[https://github.com/golang/go/wiki/Go-Release-Cycle][development cycle]]
+5. _Launch decision_. At the end of the three month
+[development cycle](https://github.com/golang/go/wiki/Go-Release-Cycle)
 (just when starting the three month repo freeze before a release), and
 based on the experience and feedback gathered during the release cycle,
 the Go team makes the final decision about whether to ship each change.
@@ -106,15 +107,15 @@ We can’t go through this process for each of the open Go 2
 proposals, there are simply too many of them. That’s where the selection
 criteria come into play.
 
-* Proposal selection criteria
+## Proposal selection criteria
 
 A proposal must at the very least:
 
-1. _address_an_important_issue_for_many_people_,
+1. _address an important issue for many people_,
 
-2. _have_minimal_impact_on_everybody_else_, and
+2. _have minimal impact on everybody else_, and
 
-3. _come_with_a_clear_and_well-understood_solution_.
+3. _come with a clear and well-understood solution_.
 
 Requirement 1 ensures that any changes we make help as many Go developers
 as possible (make their code more robust, easier to write, more likely to
@@ -131,7 +132,7 @@ issue for a lot of people, but we don’t yet have a clear and well-understood
 solution. That’s fine, it just means that the proposal needs to go back to
 the drawing board before it can be considered.
 
-* Proposals
+## Proposals
 
 We feel that this is a good plan that should serve us well but it is important
 to understand that this is only a starting point. As the process is used we will
@@ -146,14 +147,14 @@ breaking existing code, and thus they serve as a perfect trial balloon.
 With all that said, we propose the following selection of Go 2 proposals for
 the Go 1.13 release (step 1 in the proposal evaluation process):
 
-1. [[https://github.com/golang/go/issues/20706][_#20706_]] _General_Unicode_identifiers_based_on_ [[http://unicode.org/reports/tr31/][_Unicode_TR31_]]:
+1. [_\#20706_](https://github.com/golang/go/issues/20706) _General Unicode identifiers based on_ [_Unicode TR31_](http://unicode.org/reports/tr31/):
 This addresses an important issue for Go programmers using non-Western alphabets
 and should have little if any impact on anyone else. There are normalization
 questions which we need to answer and where community feedback will be
 important, but after that the implementation path is well understood.
 Note that identifier export rules will not be affected by this.
 
-2. [[https://github.com/golang/go/issues/19308][_#19308_]], [[https://github.com/golang/go/issues/28493][_#28493_]] _Binary_integer_literals_and_support_for___in_number_literals_:
+2. [_\#19308_](https://github.com/golang/go/issues/19308), [_\#28493_](https://github.com/golang/go/issues/28493) _Binary integer literals and support for \_ in number literals_:
 These are relatively minor changes that seem hugely popular among many
 programmers. They may not quite reach the threshold of solving an
 “important issue” (hexadecimal numbers have worked well so far) but they
@@ -162,14 +163,14 @@ a pain point for some programmers. They have minimal impact on others who
 don’t care about binary integer literals or number formatting, and the
 implementation is well understood.
 
-3. [[https://github.com/golang/go/issues/19113][_#19113_]] _Permit_signed_integers_as_shift_counts_:
+3. [_\#19113_](https://github.com/golang/go/issues/19113) _Permit signed integers as shift counts_:
 An estimated 38% of all non-constant shifts require an (artificial) uint
 conversion (see the issue for a more detailed break-down). This proposal
 will clean up a lot of code, get shift expressions better in sync with index
 expressions and the built-in functions cap and len. It will mostly have a
 positive impact on code. The implementation is well understood.
 
-* Next steps
+## Next steps
 
 With this blog post we have executed the first step and started the second
 step of the proposal evaluation process. It’s now up to you, the