diff --git a/gsoc/2016.md b/gsoc/2016.md
index d3572ea0c..a8dbdc5d0 100644
--- a/gsoc/2016.md
+++ b/gsoc/2016.md
@@ -9,7 +9,7 @@ title: "Google Summer of Code 2016 Scala Projects"
 ## Google Summer of Code
 
 **This year the Scala team applied again for the [Google Summer of
-  Code](http://www.google-melange.com/gsoc/homepage/google/gsoc2016)
+  Code](https://summerofcode.withgoogle.com/)
   program to work with enthusiastic students on challenging Scala
   projects**
 
@@ -19,7 +19,7 @@ in much more detail, preferably with their own suggestions and
 detailed plans on how they want to proceed. Don't feel constrained by
 the provided list! We welcome any of your own challenging ideas, but
 make sure that the proposed project satisfies the [main
-requirements](#requirements_and_guidelines) mentioned below.
+requirements](#requirements-and-guidelines) mentioned below.
 
 ### How to get involved
 
@@ -50,7 +50,8 @@ reviewed.
 There is a long list of smaller and medium sized open tickets for the Slick code generator.
 Time to tackle them and give it another overhaul. This is going to be a very useful and somewhat easier project.
 
-https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers
+[https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers
+](https://github.com/slick/slick/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Atype-providers)
 
 Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://github.com/szeiger)
 
@@ -60,7 +61,7 @@ There are lots of open tickets in the Slick issue tracker. Some which have long
 be about tackling as many of them as time permits. It will be a good chance to learn about the Slick code base
 and have an impact in this successful project. Some issues may be simple, but many issues may be challenging to fix and will require someone smart, dedicated and persistent enough to learn the details of how Slick works.
 
-https://github.com/slick/slick/issues
+[https://github.com/slick/slick/issues](https://github.com/slick/slick/issues)
 
 Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://github.com/szeiger)
 
@@ -69,7 +70,7 @@ Supervised by [@cvogt](https://github.com/cvogt) and/or [@szeiger](https://githu
 Super-charged for-comprehensions are an effort to implement an alternative direct-style dyntax for monadic comprehensions in Scala.
 The goals are reduction in syntax, enabling more control flow expressions, inline Monad value extraction and transformer operations on the Monad context (as in Comprehensive Comprehensions). At the time of writing the project is in heavy flux. Depending on its status there will likely be interesting idea how to take the project further. One likely topic would be exploring type changing comprehensive comprehension transformers, such as groupBy or aggregations. The implementation heavily relies on macros and will require learning how to work with Scala's compiler ASTs and make changes to the AST transformation stages.
 
-Work in progress: https://github.com/cvogt/flow-comprehensions
+Work in progress: [https://github.com/cvogt/flow-comprehensions](https://github.com/cvogt/flow-comprehensions)
 
 Supervised by [@cvogt](https://github.com/cvogt)
 
@@ -100,7 +101,7 @@ Supervised by [@axel22](https://github.com/axel22)
 
 ### Better Scripts in Scala
 
-There are several hacky, ad-hoc ways to write scripts in Scala already, e.g. SBT's script-runner, and the Ammonite REPL's script loader. Your task in this project would be to improve the experience writing scripts using Ammonite to be on-par with the experience writing scripts in any other language, as well as on-par with the experience writing Scala code in a large project. This includes:
+There are several hacky, ad-hoc ways to write scripts in Scala already, e.g. SBT's script-runner, and the [Ammonite REPL](https://github.com/lihaoyi/Ammonite)'s script loader. Your task in this project would be to improve the experience writing scripts using Ammonite to be on-par with the experience writing scripts in any other language, as well as on-par with the experience writing Scala code in a large project. This includes:
 
 * Improving startup time: SBT is terribly slow, and even Ammonite scripts take 1-2 seconds to boot up, This is speed-up-able.
 * Improved error reporting: Ammonite's scripts currently report line-numbers and file-names based on the mangled compilation-unit. We should report based on the location within the source file a user wrote.
@@ -112,13 +113,13 @@ Supervised by [@lihaoyi](https://github.com/lihaoyi/)
 
 ### Flexible Fast Parser Combinators
 
-The FastParse library is a modern replacement for Scala's old parser combinators library. It provides similar API, drops a lot of redundant operators, and runs 50-100x faster. However, right now it only parses Strings.
+[The FastParse library](https://github.com/lihaoyi/fastparse) is a modern replacement for Scala's old parser combinators library. It provides similar API, drops a lot of redundant operators, and runs 50-100x faster. However, right now it only parses Strings.
 
 This project would be to extend FastParse to parse other things. Cases to cover include:
 
-* Binary data: Array[Byte], ByteBuffer, ByteString, letting us parse things like binary files, network protocols, or other formats
-* Streaming data: Iterator[String] and Iterator[Char], letting us parse files while not materializing the entire contents in memory
-* Pre-tokenized data: Seq[T] for an arbitrary T, letting you re-use a pre-written lexer before your parser
+* Binary data: `Array[Byte]`, `ByteBuffer`, `ByteString`, letting us parse things like binary files, network protocols, or other formats
+* Streaming data: `Iterator[String]` and `Iterator[Char]`, letting us parse files while not materializing the entire contents in memory
+* Pre-tokenized data: `Seq[T]` for an arbitrary `T`, letting you re-use a pre-written lexer before your parser
 
 Using virtual classes, we should be able to extend FastParse to do this while still re-using most of our code. Your task would be to:
 
@@ -162,7 +163,8 @@ the REPL experience in Dotty. In this project you're going to expand
 current minimalistic REPL with advanced functionality to improve
 end-user's experience.
 
-https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl
+[https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl](
+https://github.com/lampepfl/dotty/issues?utf8=✓&q=is%3Aissue+is%3Aopen+repl)
 
 Supervised by [@densh](https://github.com/densh)
 
@@ -173,8 +175,9 @@ exposes user-controllable memory management to Scala programmers. At the moment
 it has fairly limited array-based collection API. Your goal in this project
 would be:
 
-* Expand existing functionality of combinator methods on off-heap arrays
-* Port new collections (Set[T] and Map[K, V]) to the off-heap world
+* Expand existing functionality of combinator methods on `offheap.Array[T]`
+* Port implementation of maps to scala-offheap (`offheap.Map[K, V]`)
+* Port implementation of sets to scala-offheap (`offheap.Set[T]`)
 
 Supervised by [@densh](https://github.com/densh)
 
@@ -182,13 +185,13 @@ Supervised by [@densh](https://github.com/densh)
 
 ### General Student Application Requirements
 
-This is the fifth time the Scala project has applied to the Summer of
+This is the sixth time the Scala project has applied to the Summer of
 Code, and from last years experience, increased popularity of the
 language and stories of other mentor organizations we expect a high
 number of applications. First, be aware of the following:
 
 *   Make sure that you understand, fulfill and agree to the general
-    [Google Summer of Code rules](http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2016/help_page)
+    [Google Summer of Code rules](https://summerofcode.withgoogle.com/rules/)
 *   The work done during GSoC requires some discipline from the
     students as they have to plan their day-to-day activities by
     themselves. Nevertheless we expect regular contact with the
@@ -196,8 +199,8 @@ number of applications. First, be aware of the following:
     make sure that the development is going according to the plan and
     students don't get stuck for weeks at a time (3 months may seem
     long, but in reality it is very easy to run out of time).
-*   The [official SoC timetable](http://www.google-melange.com/gsoc/events/google/gsoc2016)
-    mentions May 19th as the official start of coding, but if you
+*   The [official SoC timetable](https://summerofcode.withgoogle.com/)
+    mentions May 23 as the official start of coding, but if you
     have time you are encouraged to research your proposals even
     before that (and definitely learn the basics of Scala, if you
     haven't done that already).
@@ -231,7 +234,7 @@ number of applications. First, be aware of the following:
 ### General Proposal Requirements
 
 The proposal will be submitted via the standard web-interface at
-[http://www.google-melange.com/gsoc/homepage/google/gsoc2016](http://www.google-melange.com/gsoc/homepage/google/gsoc2016),
+[https://summerofcode.withgoogle.com/](https://summerofcode.withgoogle.com/),
 therefore plain text is the best way to go. We expect your application
 to be in the range of 700-1500 words. Anything less than that will
 probably not contain enough information for us to determine whether