fix links (cncf#416)

* fix links

Signed-off-by: Daniel Holbach <[email protected]>

CONTRIBUTING.md

@@ -20,7 +20,7 @@ Possible ways to contribute:
 
 If you are interested in engaging in this way, we would encourage you to issue a pull request to [TOC Contributors](https://github.com/cncf/toc/blob/master/CONTRIBUTORS.md) that you desire to become a TOC Contributor. Although there is not an actual limit of having one Contributor per company, we would encourage CNCF member companies to designate an official TOC Contributor who is tasked with consulting internal experts and expressing a semi-official view on a given project. We will list current TOC Contributors on a page similar to https://www.cncf.io/people/ambassadors/.
 
-This is not only about individual contribution. It is also about rallying help from your employer, e.g., if you work for a CNCF Member company. Given the [breadth](https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_v0.9.5_cncf.jpg) of projects represented by cloud native, it is impossible for anyone to be an expert in all technologies that we’re evaluating. We’re particularly interested in Contributors that can act as a focal point for tapping relevant expertise from their organizations and colleagues in order to engage with CNCF discussions in a timely manner. 
+This is not only about individual contribution. It is also about rallying help from your employer, e.g., if you work for a CNCF Member company. Given the [breadth](https://landscape.cncf.io/) of projects represented by cloud native, it is impossible for anyone to be an expert in all technologies that we’re evaluating. We’re particularly interested in Contributors that can act as a focal point for tapping relevant expertise from their organizations and colleagues in order to engage with CNCF discussions in a timely manner.
 
 The TOC already has the pattern of encouraging non-members to make non-binding votes, so no change in the TOC charter is necessary to allow Contributors.
 

PRINCIPLES.md

@@ -55,7 +55,7 @@ _Principle: Great projects already have many ingredients to succeed. First: do n
 Identify projects that have a real shot at being a useful tool in the evolving box of cloud native technology. This is a mix of mature and early-stage projects. Early stage may not have all the criteria we want: diverse contributor bases, formalized governance, interoperability, cloud-native designs, quality bar, etc. 
 
 Some considerations:
-- Transparent, consistent technical and governance quality bar for [graduation](https://www.cncf.io/projects/graduation-criteria/) from incubation
+- Transparent, consistent technical and governance quality bar for [graduation](/process/graduation_criteria.adoc) from incubation
 - Has users, preferably in production; is a high quality, high-velocity project (for incubation and graduated projects). Inception level projects are targeted at earlier-stage projects to cultivate a community/technology
 - Has a committed and excited team that appears to understand the challenges ahead and wishes to meet them
 - Has a fundamentally sound design without obvious critical compromises that will inhibit potential widespread adoption

proposals/sandbox/flux.md

@@ -151,13 +151,13 @@ In the [GitHub project](https://github.com/weaveworks/flux).
 ## Website
 
 None at present; documentation is in markdown format in the [GitHub
-repo](https://github.com/weaveworks/flux/tree/master/site).
+repo](https://github.com/weaveworks/flux/tree/master/docs).
 
 ## Release methodology and mechanics
 
 Container images and executables for releases are built in CI. The
 process of preparing a release is [explained
-here](https://github.com/weaveworks/flux/blob/master/internal_docs/releasing.md).
+here](https://github.com/weaveworks/flux/blob/master/internal/docs/releasing.md).
 
 ## Social media accounts