C-SSDS: The table with PRs table makes the document very long. The table is required, but we may be able to add it into a reference section. Additionally, update the reference from Chapter 2.3 to the new one.
We come up with this extended solution:
GAMP 5
MAIN SCENARIO: There are PR accepted and merged
The following 2 paragraphs in section 2.3 will always be rendered, regardless the existence of PRs merged:
"A Bitbucket Pull Request (PR)... bla bla bla", and
"A person who... bla bla bla"
Below the structure of the doc.
Example:
2.3 SOURCE CODE REVIEW OVERVIEW
A Bitbucket Pull Request (PR) is where contributors and reviewers meet to discuss and assert the readiness of a contribution to a
Bitbucket repository comprising code, tests, configuration, or a combination of these.
A person who creates a PR gets attributed as its author and nominates at least one reviewer. Once mandatory changes requested
by the reviewers have been incorporated by the contributors, reviewers can approve the PR. An approval permits that the
approved contribution can be merged from a temporary source branch into a longer living target branch inside the repository. A
single person must not assume the roles of contributor and reviewer on the same PR (no self-approvals).
For further details about Pull Requests information, see Section 16.1.
(...rest of document....)
16 APPENDIX
16.1 SOURCE CODE REVIEW DETAILS
The following table lists all PRs which have been approved and merged into a Bitbucket repository’s integration branch:
NOT-MAIN SCENARIO: There are not PR accepted and merged yet
Below the structure of the doc.
Example:
2.3 SOURCE CODE REVIEW OVERVIEW
A Bitbucket Pull Request (PR) is where contributors and reviewers meet to discuss and assert the readiness of a contribution to a
Bitbucket repository comprising code, tests, configuration, or a combination of these.
A person who creates a PR gets attributed as its author and nominates at least one reviewer. Once mandatory changes requested
by the reviewers have been incorporated by the contributors, reviewers can approve the PR. An approval permits that the
approved contribution can be merged from a temporary source branch into a longer living target branch inside the repository. A
single person must not assume the roles of contributor and reviewer on the same PR (no self-approvals).
16 APPENDIX
16.1 SOURCE CODE REVIEW DETAILS
"There are no Bitbucket Pull Request (PR) merged yet".
GAMP 1, 3 and 4
MAIN SCENARIO: There are not PR accepted and merged
Following 2 paragraphs in section 2.3 are not rendered since there are not PRs merged:
"A bitbucket pull request... bla bla bla", and
"A person who... bla bla bla"
No reference to an APPENDIX, i.e. APPENDIX does not exist.
Below the structure of the doc.
Example:
2.3 SOURCE CODE REVIEW OVERVIEW
N/A
NOT-MAIN SCENARIO: There are PR accepted and merged yet
If merged PR exist then the behaviour is like in GAMP 5: "MAIN SCENARIO: There are PR accepted and merged"
C-RA: Improve table from Chapter 5 to rename the following fields: 'Reference No' → 'Requirement No' | 'Requirement/Function' → 'Requirement Summary'.
C-SSDS: The table with PRs table makes the document very long. The table is required, but we may be able to add it into a reference section. Additionally, update the reference from Chapter 2.3 to the new one. We come up with this extended solution:
GAMP 5 MAIN SCENARIO: There are PR accepted and merged The following 2 paragraphs in section 2.3 will always be rendered, regardless the existence of PRs merged: "A Bitbucket Pull Request (PR)... bla bla bla", and "A person who... bla bla bla" Below the structure of the doc. Example:
2.3 SOURCE CODE REVIEW OVERVIEW A Bitbucket Pull Request (PR) is where contributors and reviewers meet to discuss and assert the readiness of a contribution to a Bitbucket repository comprising code, tests, configuration, or a combination of these.
A person who creates a PR gets attributed as its author and nominates at least one reviewer. Once mandatory changes requested by the reviewers have been incorporated by the contributors, reviewers can approve the PR. An approval permits that the approved contribution can be merged from a temporary source branch into a longer living target branch inside the repository. A single person must not assume the roles of contributor and reviewer on the same PR (no self-approvals).
For further details about Pull Requests information, see Section 16.1.
(...rest of document....)
16 APPENDIX 16.1 SOURCE CODE REVIEW DETAILS
The following table lists all PRs which have been approved and merged into a Bitbucket repository’s integration branch: