Conversation
docs/sphinx/source/contributing/introduction_to_contributing.rst
Outdated
Show resolved
Hide resolved
docs/sphinx/source/contributing/introduction_to_contributing.rst
Outdated
Show resolved
Hide resolved
docs/sphinx/source/contributing/introduction_to_contributing.rst
Outdated
Show resolved
Hide resolved
docs/sphinx/source/contributing/introduction_to_contributing.rst
Outdated
Show resolved
Hide resolved
docs/sphinx/source/contributing/introduction_to_contributing.rst
Outdated
Show resolved
Hide resolved
RDaxini
changed the title
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
kandersolar
left a comment
kandersolar
left a comment
There was a problem hiding this comment.
Fine with me. One lazy question below
| * Every pull request (PR) should address one or more open issues. The PR should | ||
| be outlined in the issue discussion. |
There was a problem hiding this comment.
Will we hold ourselves (the maintainers) to this standard? Many of my PRs do not close any issue, and I would prefer to retain that freedom. Requiring an issue for what a maintainer believes is a straightforward, non-controversial PR would (IMHO) often be repository clutter and notification noise for little benefit.
There was a problem hiding this comment.
What about "Pull requests should address one or more open issues." Does that create flexibility for maintainers?
There was a problem hiding this comment.
You could add "... unless it has been discussed with a maintainer..." somewhere in there.
There was a problem hiding this comment.
My take, but I don't really mind whatever wording gets picked:
| * Every pull request (PR) should address one or more open issues. The PR should | |
| be outlined in the issue discussion. | |
| * Every pull request (PR) scope must be clear. Context must always be provided (e.g., a link to the relevant discussion). Failing to do so may be considered spam and the PR may be closed without further explanation. |
There was a problem hiding this comment.
I would add something along the lines of "If an issue does not exist, please open an issue before proceeding to make a PR.
| * Every pull request (PR) should address one or more open issues. The PR should | ||
| be outlined in the issue discussion. |
There was a problem hiding this comment.
My take, but I don't really mind whatever wording gets picked:
| * Every pull request (PR) should address one or more open issues. The PR should | |
| be outlined in the issue discussion. | |
| * Every pull request (PR) scope must be clear. Context must always be provided (e.g., a link to the relevant discussion). Failing to do so may be considered spam and the PR may be closed without further explanation. |
| be outlined in the issue discussion. | ||
| * GSoC: For Google Summer of Code, we invite applications only from those with | ||
| significant PV modeling experience and who are motivated to join the pvlib | ||
| maintenance teams |
There was a problem hiding this comment.
| maintenance teams | |
| maintenance team. |
edit: applied Adam's suggestion
There was a problem hiding this comment.
I suggest writing "team" instead of "teams".
| * Every pull request (PR) should address one or more open issues. The PR should | ||
| be outlined in the issue discussion. | ||
| * GSoC: For Google Summer of Code, we invite applications only from those with | ||
| significant PV modeling experience and who are motivated to join the pvlib |
There was a problem hiding this comment.
| significant PV modeling experience and who are motivated to join the pvlib | |
| some PV modeling experience and who are motivated to join the pvlib |
| be outlined in the issue discussion. | ||
| * GSoC: For Google Summer of Code, we invite applications only from those with | ||
| significant PV modeling experience and who are motivated to join the pvlib | ||
| maintenance teams |
There was a problem hiding this comment.
I suggest writing "team" instead of "teams".
| * Every pull request (PR) should address one or more open issues. The PR should | ||
| be outlined in the issue discussion. |
There was a problem hiding this comment.
I would add something along the lines of "If an issue does not exist, please open an issue before proceeding to make a PR.
6 participants
Tests addedUpdates entries indocs/sphinx/source/referencefor API changes.docs/sphinx/source/whatsnewfor all changes. Includes link to the GitHub Issue with:issue:`num`or this Pull Request with:pull:`num`. Includes contributor name and/or GitHub username (link with:ghuser:`user`).remote-data) and Milestone are assigned to the Pull Request and linked Issue.