Extend CONTRIBUTING for actions after PR submission

[MikeMcC399]

What would you like?

In CONTRIBUTING > Pull Requests describe what an external contributor should do (or not do) after submitting a PR.

Should everything be left to the Cypress.io team and actions only be taken by an external PR submitter when explicitly requested by the Cypress.io team or should some conditions be resolved by the submitter pro-actively?

Why is this needed?

The document CONTRIBUTING > Pull Requests section does not describe what an external contributor should do after submitting a PR.

• After PR submission it is possible (and currently quite likely) that one or more CI checks fail. Should the external contributor try to re-run flakey tests?
• If the PR is out of date with the target branch should the external contributor follow the GitHub prompt to update the PR?
• If GitHub shows that a PR has conflicts with the target branch (usually the develop branch) should the external contributor fix this situation without being prompted?

Other

• Follows on from comment in https://github.com/cypress-io/cypress/pull/29657#issuecomment-2163769518

[jennifer-shehane]

@MikeMcC399

• The contributor is responsible for addressing the original issue and writing tests for it.
• The contributor is responsible for writing a changelog entry
• The contributor is responsible for fixing any conflicts as they come through
• A Cypress team member must review the code for each commit and approve the jobs to run in our CI machines. Outside contributor's PRs do not automatically run in CI.
• The contributor is responsible for fixing any failing tests that are a result of their code changes (this is tricky and often requires a Cypress team member to surface since we're more familiar with common flake in the repo)
• A Cypress team member is responsible for review of the PR (2 reviews are required).
• Once there are 2 PR approvals, a Cypress team member is responsible for merging. Oftentimes this requires merging in develop as other changes are merged, approving CI jobs to run, rerunning flaky tests and sometimes assisting with conflicts in order to merge as quickly as possible.

[MikeMcC399]

@jennifer-shehane

Thank you for the summary of responsibilities. To fit into the scheme of the current text CONTRIBUTING > Pull Requests this would need translating into what to do, from the viewpoint of an external contributor.

I will make a proposal for this based on your input.

[MikeMcC399]

@jennifer-shehane

Are you able to give general guidance to external PR contributors about whether to click on "Update branch" or not if there are no conflicts shown?

Should this be left to the Cypress.io team or should the contributor attempt to keep a pending PR updated with the master branch?

If an external contributor updates a PR branch it triggers a CircleCI workflow linux-x64-contributor which has a partial block contributor-pr. This requires manual permission each time and this is something that the external contributor cannot give.

[jennifer-shehane]

It's fine as long as it's not too frequent I think. Sometimes I approve the PR to run, then go to do other things, come back an hour later - the contributor pulled down develop, so I approve again, go to do other things, come back an hour later - the contributor pulled down develop, so I approve again, repeat. This is the situation that'd be nice to avoid.

[MikeMcC399]

@jennifer-shehane

Thanks for providing the additional background and your perspective. I think I can now write something to that effect.