Merge pull request #5 from BOINC/cb_editorial_fixes

Fix links and modify readme

Development_Workflow.md

@@ -41,11 +41,11 @@ If a change is approved, the issue should be "ready to implement" and should be
 ## 2. Implementation
 All development is done using feature branches as defined in [GitHub Flow](https://guides.github.com/introduction/flow/). BOINC uses the [Fork and Pull Model](https://gist.github.com/Chaser324/ce0505fbed06b947d962) for development (background on this approach can be [read here](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/)). Once you have created your fork, set it up locally, and created a feature branch, then you can begin coding. When you are finished with development you can create a pull request for review.
 
-Make sure to review the [Definition_of_Done_for_Feature_Branches.md](../blob/master/Definition_of_Done_for_Feature_Branches.md) before starting work so that you are familiar with the expectations of your work.
+Make sure to review the [Definition_of_Done_for_Feature_Branches.md](../../blob/master/Definition_of_Done_for_Feature_Branches.md) before starting work so that you are familiar with the expectations of your work.
 
 If you wish to get some early feedback on your changes, then you can create a pull request with the text [WIP] at the start of the title. This indicates to reviewers that you are inviting others to look at your code, but that it should not be merged. Once you are ready for final review and merge into master, then you can remove the [WIP] prefix.
 
 Once the code has been approved it is merged into the master branch.
 
 ### 2.1 Code Review
-Once a pull request has been created for the implementation of an issue, anyone can review and comment on the changes. Committers need to follow consensus voting and determine if the code change is accepted. Committers should use the [Expectations_of_Code_Review.md](../blob/master/Expectations_of_Code_Review.md) as a guide to conducting the review.
+Once a pull request has been created for the implementation of an issue, anyone can review and comment on the changes. Committers need to follow consensus voting and determine if the code change is accepted. Committers should use the [Expectations_of_Code_Review.md](../../blob/master/Expectations_of_Code_Review.md) as a guide to conducting the review.

Governance.md

@@ -146,9 +146,9 @@ The process of making technical or code contributions is the same for everyone,
   - Review the Project (https://github.com/BOINC/boinc/projects) associated with the area of BOINC in which you want to contribute
   - Issues that have been reviewed and are ready for implementation are listed under Longterm or TODO
   - Issues with a higher priority for implementation are listed under TODO
-- Follow the software development process that BOINC uses (See [Development_Workflow.md](../blob/master/Development_Workflow.md))
+- Follow the software development process that BOINC uses (See [Development_Workflow.md](../../blob/master/Development_Workflow.md))
 
-If you are reporting a bug or requesting a feature, make sure you review the [Development Workflow](../blob/master/Development_Workflow.md) before you submit it.
+If you are reporting a bug or requesting a feature, make sure you review the [Development Workflow](../../blob/master/Development_Workflow.md) before you submit it.
 
 ## 5. Decision processes
 ### 5.1 Voting Processes

README.md

@@ -1,5 +1,5 @@
 # BOINC policy documents
 
-The official BOINC policy documents still reside at: https://boinc.berkeley.edu/trac/wiki/ProjectGovernance
+The documents in this repository describe the policies on how to contribute to the BOINC project.
 
-This is a repository to test a future change process to policy documents.
+This is not a place to discuss how the BOINC software should work. Please look at https://github.com/BOINC/boinc for that.