New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document and make public new issue lifecycle #3465
Conversation
…ifecycle and remove some out-of-date instructions.
Signed-off-by: Tomás Ó hAodha <86358393+tomasohaodha@users.noreply.github.com>
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 42
As you change the file, maybe remove reference to not existing dir vendor/
?
CONTRIBUTING.md
Outdated
|
||
### Open a Pull Request | ||
|
||
* Before working on a possible pull request, you should first open an associated issue (feature request or bug report) describing the proposed change. This gives an opportunity for the core development team to discuss the potential pull request with you before you do the work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should require an issue for every PR. It might be needed for some big or controversial change, but in most cases seeing the code changes actually helps. We probably should change the PR template to encourage people to give a more detailed description of the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see the value in that. However as we want to move towards a 'github first' workflow in general, I think all work by external contributors should start with an issue. This will allow us to apply the issue workflow (and perhaps kindly turn down the issue) before the contributor goes to the trouble of creating a PR, thus saving them work.
If we decide that it is too onerous, we can always implement the changed PR template at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can apply the issue workflow to PRs as well
Co-authored-by: Luca Comellini <luca.com@gmail.com> Co-authored-by: Alan Dooley <ADubhlaoich@users.noreply.github.com> Co-authored-by: Shaun <s.odonovan@f5.com> Signed-off-by: Tomás Ó hAodha <86358393+tomasohaodha@users.noreply.github.com>
Signed-off-by: Tomás Ó hAodha <86358393+tomasohaodha@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## main #3465 +/- ##
==========================================
- Coverage 51.97% 51.95% -0.02%
==========================================
Files 60 60
Lines 16811 16806 -5
==========================================
- Hits 8737 8732 -5
Misses 7777 7777
Partials 297 297
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I'll leave that to a new PR so that we keep the PRs cohesive and uncoupled. (Thanks for pointing it out). |
Proposed changes
This PR contains a new markdown file called ISSUE_LIFECYCLE that documents the proposed issue lifecycle as has been discussed internally over the last quarter. The goal of the lifecycle is to improve responsiveness to issues being created by the community by providing clarity on how to progress the issue.
The PR also updated the CONTRIBUTING doc to reflect the changes in the lifecycle doc and place emphasis on creating an issue before a pull request.
Checklist
Before creating a PR, run through this checklist and mark each as complete.