Startrekzky commented on code in PR #298: URL: https://github.com/apache/incubator-devlake-website/pull/298#discussion_r1017841245
########## docs/Glossary.md: ########## @@ -13,6 +13,18 @@ description: > The following terms are arranged in the order of their appearance in the actual user workflow. +### Projects +**A project is a set of related [Data Scopes](#data-scope), the Data Scopes may contain different [Data Entities](#data-entities) from arbitrary [Data Sources](#data-sources) for Metric Computation** + +Project was introduced in v0.15 to solve some complex metric computation problems. For example, There is a **Change Failure Rate** in [DORA Metric](../UserManuals/DORA) which requires connecting Incident(issue.type = 'INCIDENT') to its related Deployment(`cicd_task.type = 'DEPLOYMENT'`) to determine whether a Deployment failed or not. Unfortunately, most data sources do not offer this relationship, the only reasonable approach so far is to map an Incident to its Closest Deployment. Without Project, the Incident may be mapped to unrelated Deployment in database. + +A project consists of the following elements: + +- A set of [Data Scopes](Glossary.md#data-scope), for example, several `repos` pointing to Github Repositories, `boards` pointing to a couple of Jira Scrum Boads and `cicd_scopes` to Jenkins Servers etc. Review Comment: Text change: "A set of data scope" to "One or Multiple sets of data scope" ########## docs/Glossary.md: ########## @@ -13,6 +13,18 @@ description: > The following terms are arranged in the order of their appearance in the actual user workflow. +### Projects +**A project is a set of related [Data Scopes](#data-scope), the Data Scopes may contain different [Data Entities](#data-entities) from arbitrary [Data Sources](#data-sources) for Metric Computation** Review Comment: Text change: "Apache DevLake supports users to view metrics based on projects. A `project` is associated with multiple sets of [data scope](#data-scope), such as GitHub/GitLab repositories, Jira boards, Jenkins pipelines, etc. Metrics for a project are calculated based on the data entities(#data-entities) under the project's data scope. For example, when a user associates 'Jenkins Job A' and 'Jira board B' with project 1, then ONLY `deployments` in 'Jenkins Job A' and `incidents` in 'Jira board B' will be used to calculate **Change Failure Rate** for project 1. ########## docs/Glossary.md: ########## @@ -13,6 +13,18 @@ description: > The following terms are arranged in the order of their appearance in the actual user workflow. +### Projects +**A project is a set of related [Data Scopes](#data-scope), the Data Scopes may contain different [Data Entities](#data-entities) from arbitrary [Data Sources](#data-sources) for Metric Computation** + +Project was introduced in v0.15 to solve some complex metric computation problems. For example, There is a **Change Failure Rate** in [DORA Metric](../UserManuals/DORA) which requires connecting Incident(issue.type = 'INCIDENT') to its related Deployment(`cicd_task.type = 'DEPLOYMENT'`) to determine whether a Deployment failed or not. Unfortunately, most data sources do not offer this relationship, the only reasonable approach so far is to map an Incident to its Closest Deployment. Without Project, the Incident may be mapped to unrelated Deployment in database. + +A project consists of the following elements: + +- A set of [Data Scopes](Glossary.md#data-scope), for example, several `repos` pointing to Github Repositories, `boards` pointing to a couple of Jira Scrum Boads and `cicd_scopes` to Jenkins Servers etc. +- A set of Metrics(currently, only DORA). Review Comment: When I read the whole sentence, I had no idea about 'A project consists the following elements: a set of metrics'. Do you mean that there's "a set of metrics" as a project's attribute? ########## docs/Glossary.md: ########## @@ -13,6 +13,18 @@ description: > The following terms are arranged in the order of their appearance in the actual user workflow. +### Projects +**A project is a set of related [Data Scopes](#data-scope), the Data Scopes may contain different [Data Entities](#data-entities) from arbitrary [Data Sources](#data-sources) for Metric Computation** + +Project was introduced in v0.15 to solve some complex metric computation problems. For example, There is a **Change Failure Rate** in [DORA Metric](../UserManuals/DORA) which requires connecting Incident(issue.type = 'INCIDENT') to its related Deployment(`cicd_task.type = 'DEPLOYMENT'`) to determine whether a Deployment failed or not. Unfortunately, most data sources do not offer this relationship, the only reasonable approach so far is to map an Incident to its Closest Deployment. Without Project, the Incident may be mapped to unrelated Deployment in database. + +A project consists of the following elements: + +- A set of [Data Scopes](Glossary.md#data-scope), for example, several `repos` pointing to Github Repositories, `boards` pointing to a couple of Jira Scrum Boads and `cicd_scopes` to Jenkins Servers etc. +- A set of Metrics(currently, only DORA). +- A [`Blueprint`](#blueprints) to pull data from [supported data sources](./SupportedDataSources.md). +- [Optional] A set of `Incoming Webhooks` to receive pushed from non-supported data sources. Review Comment: - to receive pushed (data) from ... ? - non-supported -> unsupported? ########## docs/Glossary.md: ########## @@ -13,6 +13,18 @@ description: > The following terms are arranged in the order of their appearance in the actual user workflow. +### Projects +**A project is a set of related [Data Scopes](#data-scope), the Data Scopes may contain different [Data Entities](#data-entities) from arbitrary [Data Sources](#data-sources) for Metric Computation** + +Project was introduced in v0.15 to solve some complex metric computation problems. For example, There is a **Change Failure Rate** in [DORA Metric](../UserManuals/DORA) which requires connecting Incident(issue.type = 'INCIDENT') to its related Deployment(`cicd_task.type = 'DEPLOYMENT'`) to determine whether a Deployment failed or not. Unfortunately, most data sources do not offer this relationship, the only reasonable approach so far is to map an Incident to its Closest Deployment. Without Project, the Incident may be mapped to unrelated Deployment in database. Review Comment: I put it in the last comment for your reference. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
