maintainers.md: fix cross-links

Signed-off-by: Santiago M. Mola <santi@mola.io>

engineering/README.md

@@ -9,7 +9,7 @@
 
 ## Key Concepts
 
-* [Project Maintainers](maintainers.md)
+* [Repositories](repositories.md)
 * [Releases](releases.md)
 * [Git workflow](git-flow.md)
 * [Development Conventions](conventions.md)

engineering/continuous-delivery.md

@@ -55,7 +55,7 @@ CI and CD is controlled [by drone](https://drone.srcd.host)
 
 `master` branch is the starting point for feature branches (considering some [special cases](#special-cases))
 
-Since the workflow in the source{d} web applications used to be closely guided by Product, it is quite likely that it is needed to obtain its approval before merging into `master`; the repository [Maintainers](maintainers.md) will decide if any PR must be reviewed by Product, by themselves or by any other person.
+Since the workflow in the source{d} web applications used to be closely guided by Product, it is quite likely that it is needed to obtain its approval before merging into `master`; the repository [Maintainers](repositories.md) will decide if any PR must be reviewed by Product, by themselves or by any other person.
 
 # Deploying into Production
 

engineering/conventions.md

@@ -65,7 +65,7 @@ Some projects might define both build and runtime requirements that go beyond wh
 
 ## Others
 
-Refer to the [licensing](licensing.md), [maintainers](maintainers.md) and [documentation](documentation.md) guides for other important information you should know when creating new projects.
+Refer to the [licensing](licensing.md), [repositories](repositories.md) and [documentation](documentation.md) guides for other important information you should know when creating new projects.
 
 ## Development Environments
 

engineering/maintainers.md

@@ -0,0 +1 @@
+repositories.md

engineering/releases.md

@@ -3,7 +3,7 @@
 
 ## How frequently/what prompts a release?
 
-At [maintainer](maintainers.md)'s discretion. But in general, if a bug that is a critical regression from latest release is fixed, a new release should be done ASAP. If, after some time, there are pending changes that are well tested, a release should be performed too.
+At [maintainer](repositories.md)'s discretion. But in general, if a bug that is a critical regression from latest release is fixed, a new release should be done ASAP. If, after some time, there are pending changes that are well tested, a release should be performed too.
 
 ## What should be provided in terms of files?
 
@@ -19,4 +19,4 @@ Release notes should contain something along these lines:
 - _Bug Fixes_ section.
 - _Known Issues_ section, with reference to issues that are new in a stable release, known that the time of release, but not fixed yet.
 
-Links to issues or PR should be used as much as possible, as well as acknowledgements to contributors (specially external contributors), preferably in the form of a GitHub user mention.
+Links to issues or PR should be used as much as possible, as well as acknowledgements to contributors (specially external contributors), preferably in the form of a GitHub user mention.

engineering/repositories.md

@@ -2,13 +2,13 @@
 
 ## Repository creation request
 
-In order to create a new repository, this should be requested through a [infrastructure issue](https://github.com/src-d/issues-infrastructure), and will be handled by @mcuadros.
+In order to create a new repository, this should be requested through a [infrastructure issue](https://github.com/src-d/infrastructure), and will be handled by @mcuadros.
 
 The name should be discussed with product, and the tags and description should be provided.
 
 ## Repository privileges
 
-Each repository should belong to a team, and the full team has admin rights over this repository. If the repository engineering wise, the admin will be @smola and @mcuadros. 
+Each repository should belong to a team, and the full team has admin rights over this repository. If the repository is engineering-wide, the admin will be @smola and @mcuadros.
 
 ## Maintainer role