updated contributing guidelines

CONTRIBUTING.md

@@ -3,20 +3,20 @@
 This project has a [Code of Conduct](./CODE_OF_CONDUCT.md) that we expect all of our contributors to abide by, please check it out before contributing.
 
 ## Contributor license agreement
-By submitting code as an individual or as an entity you agree that your code is licensed the same as the [Digital Paper Edit](./LICENCE.md).
+By submitting code as an individual or as an entity you agree that your code is licensed the same as the [slate transcript editor](./LICENCE.md).
 
 ## Pull requests and branching
 
-1. [Feel free to start by raising an issue](https://github.com/bbc/digital-paper-edit-electron/issues/new?template=feature_request.md) so that others can be aware of areas where there is active development, and if needed we can synchronies the effort.
+1. [Feel free to start by raising an issue](https://github.com/pietrop/slate-transcript-editor/issues/new?template=feature_request.md) so that others can be aware of areas where there is active development, and if needed we can synchronies the effort.
 
 2. [Fork the repo](https://help.github.com/articles/fork-a-repo/)
 
 3. Before working on a feature **always** create a new branch first. Createa a branch with a meaningful name.
 4. Branches should be short lived - consider doing multiple PR breaking down functionalities as opposed to one big change.
-5. If you've added code that should be tested, add tests, if you need help with automated testing, feel free to raise an [issue](https://github.com/bbc/digital-paper-edit-electron/issues/new?template=feature_request.md).
+5. If you've added code that should be tested, add tests, if you need help with automated testing, feel free to raise an [issue](https://github.com/pietrop/slate-transcript-editor/issues/new?template=feature_request.md).
 6. Ensure the test suite passes.
 7. Make sure your code lints.
-8. If you've changed APIs, consider [updating the documentation](https://github.com/bbc/digital-paper-edit-electron#documentation) and QA Testing docs.
+8. If you've changed APIs, consider [updating the documentation](https://github.com/pietrop/slate-transcript-editor/#documentation) and QA Testing docs.
 9. Once the work is complete push the branch up on to GitHub for review. Make sure your branch is up to date with `master` before making a pull request. eg use [`git merge origin/master`](https://git-scm.com/docs/git-merge) or [rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
 10. Once a branch has been merged into `master`, delete it.
 
@@ -39,7 +39,7 @@ See [this blog post for more on this](https://medium.com/mindorks/how-to-write-c
 - [ ] Ensure test suite passes (`npm run test`)
 - [ ] Make sure your code lints. (`npm run lint`)
 - [ ] consider re-factoring for code quality and readability
-- [ ] Update documentation and QA docs where appropriate - [see updating the documentation](https://github.com/bbc/digital-paper-edit-electron#documentation)
+- [ ] Update documentation and QA docs where appropriate - [see updating the documentation](https://github.com/pietrop/slate-transcript-editor/#documentation)
 - [ ] Setup your PR for review 
 
 <!--