The ../user-guide links do not seem to work anymore.

contributors/design-proposals/apps/deploy.md

@@ -19,7 +19,7 @@
 
 ## Motivation
 
-Users can use [Deployments](../user-guide/deployments.md) or [`kubectl rolling-update`](../user-guide/kubectl/kubectl_rolling-update.md) to deploy in their Kubernetes clusters. A Deployment provides declarative update for Pods and ReplicationControllers, whereas `rolling-update` allows the users to update their earlier deployment without worrying about schemas and configurations. Users need a way that's similar to `rolling-update` to manage their Deployments more easily.
+Users can use [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [`kubectl rolling-update`](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/) to deploy in their Kubernetes clusters. A Deployment provides declarative update for Pods and ReplicationControllers, whereas `rolling-update` allows the users to update their earlier deployment without worrying about schemas and configurations. Users need a way that's similar to `rolling-update` to manage their Deployments more easily.
 
 `rolling-update` expects ReplicationController as the only resource type it deals with. It's not trivial to support exactly the same behavior with Deployment, which requires:
 - Print out scaling up/down events.

contributors/design-proposals/aws/aws_under_the_hood.md

@@ -47,13 +47,13 @@ kube-up.
 
 ### Storage
 
-AWS supports persistent volumes by using [Elastic Block Store (EBS)](../user-guide/volumes.md#awselasticblockstore).
+AWS supports persistent volumes by using [Elastic Block Store (EBS)](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore).
 These can then be attached to pods that should store persistent data (e.g. if
 you're running a database).
 
 By default, nodes in AWS use [instance storage](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
 unless you create pods with persistent volumes
-[(EBS)](../user-guide/volumes.md#awselasticblockstore). In general, Kubernetes
+[(EBS)](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore). In general, Kubernetes
 containers do not have persistent storage unless you attach a persistent
 volume, and so nodes on AWS use instance storage.  Instance storage is cheaper,
 often faster, and historically more reliable. Unless you can make do with
@@ -112,8 +112,8 @@ ELB has some restrictions:
 on ELB annotations for pods speaking HTTP).
 
 To work with these restrictions, in Kubernetes, [LoadBalancer
-services](../user-guide/services.md#type-loadbalancer) are exposed as
-[NodePort services](../user-guide/services.md#type-nodeport).  Then
+services](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) are exposed as
+[NodePort services](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport).  Then
 kube-proxy listens externally on the cluster-wide port that's assigned to
 NodePort services and forwards traffic to the corresponding pods.
 

contributors/design-proposals/cli/simple-rolling-update.md

@@ -1,10 +1,10 @@
 ## Simple rolling update
 
 This is a lightweight design document for simple
-[rolling update](../user-guide/kubectl/kubectl_rolling-update.md) in `kubectl`.
+[rolling update](https://kubernetes.io/docs/user-guide/kubectl/kubectl_rolling-update.md#rolling-update) in `kubectl`.
 
 Complete execution flow can be found [here](#execution-details). See the
-[example of rolling update](../user-guide/update-demo/) for more information.
+[example of rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update-intro/) for more information.
 
 ### Lightweight rollout
 

contributors/design-proposals/network/networking.md

@@ -127,7 +127,7 @@ to serve the purpose outside of GCE.
 
 ## Pod to service
 
-The [service](../user-guide/services.md) abstraction provides a way to group pods under a
+The [service](https://kubernetes.io/docs/concepts/services-networking/service/) abstraction provides a way to group pods under a
 common access policy (e.g. load-balanced). The implementation of this creates a
 virtual IP which clients can access and which is transparently proxied to the
 pods in a Service. Each node runs a kube-proxy process which programs

contributors/design-proposals/scheduling/resources.md

@@ -1,6 +1,6 @@
 **Note: this is a design doc, which describes features that have not been
 completely implemented. User documentation of the current state is
-[here](../user-guide/compute-resources.md). The tracking issue for
+[here](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/). The tracking issue for
 implementation of this model is [#168](http://issue.k8s.io/168). Currently, both
 limits and requests of memory and cpu on containers (not pods) are supported.
 "memory" is in bytes and "cpu" is in milli-cores.**
@@ -281,7 +281,7 @@ to encourage comments.
 Because resource usage and related metrics change continuously, need to be
 tracked over time (i.e., historically), can be characterized in a variety of
 ways, and are fairly voluminous, we will not include usage in core API objects,
-such as [Pods](../user-guide/pods.md) and Nodes, but will provide separate APIs
+such as [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) and Nodes, but will provide separate APIs
 for accessing and managing that data. See the Appendix for possible
 representations of usage data, but the representation we'll use is TBD.