fixed few minor typos

Signed-off-by: Venu Vardhan Reddy Tekula <venuvardhanreddytekula8@gmail.com>

CONTRIBUTING.md

@@ -5,13 +5,13 @@ all of them in the [metrics directory](metrics).
 You can contribute by helping to refine those metrics definitions.
 
 * Reference implementations. For each metric, we intend to produce reference implementations, in the [implementations directory](implementations).
-They are based on data from real data sources, retrieved using [Perceval](https://github.com/chaoss/grimirelab-perceval) or by using a GHTorrent or other data store implementation. The idea is to first use a Python notebook to study how to produce the metric, and all the variations, parameters, etc, that are convenient to have into account. And then, produce a simple script that will compute the metric from the chosen data.  These scripts would be used a reference implementations, both for informing other implementations, and for ensuring that, if they intend to implement CHAOSS metrics, they produce the same results
+They are based on data from real data sources, retrieved using [Perceval](https://github.com/chaoss/grimirelab-perceval) or by using a GHTorrent or other data store implementation. The idea is to first use a Python notebook to study how to produce the metric, and all the variations, parameters, etc, that are convenient to have into account. And then, produce a simple script that will compute the metric from the chosen data.  These scripts would be used as reference implementations, both for informing other implementations, and for ensuring that, if they intend to implement CHAOSS metrics, they produce the same results
 on the same data sources.
 
 In any of these subjects, you can propose your ideas by opening an issue, proposing a pull request, introducing your concerns during a GMD meeting,
 or via a message to the mailing list. However, the usual procedure (meetings and general comments in the mailing list) is as follows:
 
-* If you think something should be done (including a contribution by yourself),please open an issue in this repository. That will allow others to learn that
+* If you think something should be done (including a contribution by yourself), please open an issue in this repository. That will allow others to learn that
 you think some work should be done, and can comment on that. If you intend to do the job yourself, please say that.
 
 * Everyone with an opinion on the matter should comment on the issue, explaining how they support the idea, propose some change to it,
@@ -20,14 +20,14 @@ or think it is not worth / it is not the moment for doing it.
 * If comments are positive, and a certain consensus is achieved, propose a pull request with the changes to the repository
 (new document, changes to existing documents).
 
-* Everyone with an opinion on the pulll request should comment on it, and detailed reviews should be done, maybe asking for new
-versions of the pull requet. Once comments and reviews are positive, the change will be merged in the repository.
+* Everyone with an opinion on the pull request should comment on it, and detailed reviews should be done, maybe asking for new
+versions of the pull request. Once comments and reviews are positive, the change will be merged in the repository.
 
 * If consensus is not reached at any of these points, or the process stalls, it can be raised during one of the GMD meetings,
 or in the mailing list, to try to unblock it.
 
 * In some specific cases (eg, drafts for use cases), Google Docs or other means could be used, if that helps newcomers to contribute their ideas.
-But this will in general be the exception.
+But this will, in general, be the exception.
 
 We're also open to discuss the [Definition of GMD itself], but please refrain from this except that you have very good reasons for that,
 just because currently we're focused on the definition of GMD and its refining in focus areas.

ROADMAP.md

@@ -35,7 +35,7 @@ by February, including reference implementations. Thus area will be code develop
 
 * We are aiming to produce metrics for the next CHAOSSCon (February), in at least 2 focus areas.
 
-* We are aiming to release formally version 1 of the metrics by Summmer.
+* We are aiming to release formally version 1 of the metrics by Summer.
 
 ### Goal #2: Make focus areas consistent with use cases
 
@@ -60,7 +60,7 @@ the focus areas will become more consistent with use cases and vice versa.
 
 We need a way to know which metrics are implemented by CHAOSS projects,
 a kind of a dashboard or tables in a document where people can quickly
-understand wich metrics are already implemented.
+understand which metrics are already implemented.
 
 * We are aiming at lists of concrete implementations of CHAOSS metrics
 in Augur and GrimoireLab.

gmd_metrics.md

@@ -20,7 +20,7 @@ Implementation [README](./example_implementations/README.md)
 
 The following are the areas of focus:
 
-1. [Issue Resolution](./focus_areas/Issue_resolution.md)
+1. [Issue Resolution](./focus_areas/issue_resolution.md)
 2. [Code Development](./focus_areas/code_development.md)
 3. [Community Growth](./focus_areas/community_growth.md)