Add new metrics for Mapping between PR/MRs and issues

[king-gao]

In a healthy community, one PR/MR mapping to one issue.
If one PR/MR mapping to multiple issues, the PR granularity is too large. If one PR/MR does not have issues, it is abnormal, all PRs/MRs are based on requirements (fix security vulnerabilities, bugs, or small functions and features). in this way, PRs/MRs can better trace requirements and manage requirements in the community better.
Maybe there are some new metrics here:

• How many PR/MRs are not mapping to issue?
• How many PR/MRs are mapping to more than one issue?

[GeorgLink]

It seems reasonable on first sight. Here is a related idea to check whether issues were automatically closed by the merging of a PR: #243

[king-gao]

Hi @GeorgLink 👍

Maybe we can consider the two metrics together, your issue #243 is consider from issue side ; then this issue #382 is from PR side.

so, can we list all the scenarios between issue and PR(If the PR equal to code changed):

Number of issue	Number of PR
1	1
1	N
N	1
0	1
1	0

If the 1 issue VS 1 PR is best scenario , we can compute the number and the ratio, I think the ratio is more meaningful in this metrics.

[GeorgLink]

@king-gao I like where you're taking this. Expanding your table a bit:

Number of issue	Number of PR	Conclusion
1	1	BEST
0	1	PR links to issue only
1	0	Issue links to PR only
1	N	PR too big
0	N	PR too big
N	1	Issue too big
N	0	Issue too big

Legend:

• 0 = no out links
• 1 = links out to one of the other type
• N = links out to multiple of the other type

[foundjem]

Hello @king-gao and @GeorgLink,
Are we still talking about PR/MR? I think that we had a discussion in the evolution working group concerning this, which was agreed upon as "Change Request."

Irrespective of the naming convention, I like the discussion line on the relationship between "Issues and PR." In effect, this seems like a many-to-many relationship that is decomposable following the illustrated scenarios in the table. My question here is given a 1:1 correspondent, are we:-

(1) suggesting "beat practice" with the aim of this new metric?
(2) proposing quality assurance to control the threshold of a PR/Issue?

Signed-Off-By: Armstrongfoundjem@ieee.org

[sgoggins]

@foundjem / @king-gao / @GeorgLink : We do have this information in Augur.

[germonprez]

Start of the Metric:
https://docs.google.com/document/d/1uD_2dOmuaakwq5-frV8Pgg9Yf4p_P-vCrvnaDnP55B0/edit

Placed in Metrics Spreadsheet:
https://docs.google.com/spreadsheets/d/1tAGzUiZ9jdORKCnoDQJkOU8tQsZDCZVjcWqXYOSAFmE/edit#gid=1004270137

[sgoggins]

This metric is under development. We will need to caveat this metric, however, because the practice of linking of issues to pull requests will be idiosyncratic to each repository.

[ElizabethN]

I'm going to close this issue since the work is happening elsewhere and being tracked in the spreadsheet.