ER: update the pull request contributing guidelines

[ino-iosdev]

Emergent Requirement - Problem

This problem was brought up during the weekly Sunday meeting on 06/09/24. A common mistake was discovered in the pull request title among many newly on-boarded devs, the issue ticket number was often added at the end of the title which would stack with the PR number, I have come across this problem in the PR review process 5 times in a row, which raised my concern, screenshot of a recent discovery below:

This might be caused by confusing the PR ticket number attached at the end of the title example in the pull request instruction as the issue ticket number, see below:

Issue you discovered this emergent requirement in

• 6982

• 6984

Date discovered

• 06/09/24

Did you have to do something temporarily

• [x] YES
• [ ] NO

Who was involved

@ino-iosdev @t-will-gillis

What happens if this is not addressed

• Repetitive change request in PR review
• Reduce PR review efficiency

Resources

CONTRIBUTING.md#part-3-pull-requests

Recommended Action Items

• [x] Make a new issue
• [x] Discuss with team
• [x] Let a Team Lead know

Potential solutions [draft]

• Solution (1)

Replace Update Care Link in Credits Page - #2131 with Update Care Link in Credits Page

• Solution (2)

Replace Update Care Link in Credits Page - #2131 with Update Care Link in Credits Page - #2131 (DO NOT include issue ticket number in the PR title!)

[github-actions[bot]]

Hi @ino-iosdev.

Please don't forget to add the proper labels to this issue. Currently, the labels for the following are missing:

• Complexity, Role, Feature

NOTE: Please ignore this comment if you do not have 'write' access to this directory.

To add a label, take a look at Github's documentation here.

Also, don't forget to remove the "missing labels" afterwards. To remove a label, the process is similar to adding a label, but you select a currently added label to remove it.

After the proper labels are added, the merge team will review the issue and add a "Ready for Prioritization" label once it is ready for prioritization.

Additional Resources:

• Wiki: How to create issues
• Wiki: How to read and interpret labels

[t-will-gillis]

Hey @ino-iosdev good start on this! Here are some suggestions:

• If this were my ER, I would approach this more from the standpoint of “We want the title of the PR to clearly summarize how the dev resolved the issue. When devs unnecessarily include the issue number in the title, the issue number collides with the PR number making it unclear which is which, and is a detriment to clear communication.” Or something to that effect.
• It may be helpful to crop down the first screenshot to emphasize the circled area.
• I think that it would help to remove the second screenshot. I understand what you are saying, but I think the first screenshot illustrates the point and the second only distracts from your argument. Also, although it might not be strictly the case in this exact instance, when we link them, the issue and PR number usually appears at the end.
• For the “Potential solutions [draft]”, you will want to reference a specific area of code where the solution would be applied- think of it as you are writing an issue and need to tell a dev exactly what needs to be changed. For example, since you are recommending a change to the way devs title their PRs, the applicable code is CONTRIBUTING.md, Section 3.1.b.i. around or after line 889 (your 2nd screenshot). Where our docs say - Please change it to provide a summary of what you did. you could recommend adding another bullet - Note: Please do not include the issue number in the PR title; a PR number will be added automatically. or some such.

For the labels: role: back end/devOps, complexity: depending on the change this might be a good first issue, and feature: this would be p-feature: onboarding/contributing.md

One final thing, if this is approved, you should volunteer to write the issue for it.