Issue policy #3655
Issue policy #3655
Conversation
|
@devyte this seems to be off in an archive other than your @devyte/Arduino Why not? I am a bit unclear how to get to the matter to clone and edit |
|
Looks good to me, seems to nicely include solutions to the main issues raised initially. |
|
@igrr a question I just encountered: do we want to accept issues for code in pending PRs? I would think not. Instead, any issues found should be discussed in the PR itself. |
POLICY.md
Outdated
| 1. Any contributor of the project can participate in the triaging process, if he/she chooses to do so | ||
| 2. An issue that needs to be closed, either due to not complying with this policy, or for other reasons, should be closed by a contributor | ||
| 3. Issues that are accepted should be marked with appropriate labels, e.g.: component: xyz | ||
| 4. If an issue is deemed to require specialized knowledge (e.g.: TLS, HTTP parser, SDK integration, etc), contributor(s) relevant to the affected code should be /cc’ed, as this can help grab attention by the right person |
There was a problem hiding this comment.
"by the right person" seems superfluous
POLICY.md
Outdated
| 10. Feature requests that are not accompanied by a PR: | ||
| * could be closed immediately (denied) | ||
| * could be closed after some predetermined period of time (left as candidate for somebody to pick up) | ||
| * could be deemed interesting enough to work on, but without a specific project or target, and hence accumulated in a long-term feature request list. Such feature requests should in general not be targeted for a deadline or release. |
There was a problem hiding this comment.
Based on the previous discussion i gather that the agreement is to go for option (2) here (close after some time unless someone expresses interest in working on an enhancement). Suggest removing options 1 and 3 and replacing 'could' with 'should'.
POLICY.md
Outdated
| * could be closed immediately (denied) | ||
| * could be closed after some predetermined period of time (left as candidate for somebody to pick up) | ||
| * could be deemed interesting enough to work on, but without a specific project or target, and hence accumulated in a long-term feature request list. Such feature requests should in general not be targeted for a deadline or release. | ||
| 11. In some cases, feedback may be requested from the requestor, either as additional info for clarification, additional testing, or other. If no feedback is provided after 30 days, the issue may be closed by a contributor. |
There was a problem hiding this comment.
maybe "requested from the issue reporter"?
POLICY.md
Outdated
| # Pull requests | ||
| 1. All pull requests should undergo peer review by at least one contributor other than the requestor | ||
| 2. All pull requests should consider updates to the documentation | ||
| 3. All pull requests should consider updates to regressions, where possible |
POLICY.md
Outdated
| 2. All pull requests should consider updates to the documentation | ||
| 3. All pull requests should consider updates to regressions, where possible | ||
| 4. Pull requests that address an outstanding issue, particularly an issue deemed to be severe, should be given priority | ||
| 5. If a feature requests is accepted, the PR should then be updated based on feedback, then merged. |
There was a problem hiding this comment.
I don't understand what this item means, could you please clarify?
There was a problem hiding this comment.
@igrr This is about PRs. If a PR is accepted, then it should undergo review and updated based on the feedback provided, then merged.
POLICY.md
Outdated
| 4. Pull requests that address an outstanding issue, particularly an issue deemed to be severe, should be given priority | ||
| 5. If a feature requests is accepted, the PR should then be updated based on feedback, then merged. | ||
|
|
||
| # Other |
There was a problem hiding this comment.
Suggest moving each item from this section into a new issue, or into a "project". Unlike all previous sections, this is more of a "here is where we want to go, but something needs to be done about this", rather than "here are the rules".
There was a problem hiding this comment.
@igrr I don't quite understand what you mean. Could you please elaborate?
There was a problem hiding this comment.
Do you mean eliminate the section altogether, and create projects for the three topics?
Probably not, it's usually better to comment in PR instead. Some mega-PRs (which change a lot of things) could be an exception, in which case we can say so in PR description. |
|
Small typo on line 3 "Opening an issue_s_". |
|
Also an extra "s" in the last point of the "Pull requests" section : "If a feature request_s_". |
|
Finally, in the first paragraph of the "Other" section : "this is essential to figure out i_s_". Should read "if" I guess. |
Included review feedback from igrr included feedback in PR (typos)
|
Updated policy doc based on review and feedback. |
First draft of a policy document, based on discussion under issue #3571