Skip to content

Update contributing guidelines #2726

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.

Sign up for GitHub

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

Open
RDaxini wants to merge 7 commits into
base: main
Choose a base branch
from
+23 −0
Open

Update contributing guidelines #2726

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
35c5b3d
Update introduction_to_contributing.rst
RDaxini Mar 30, 2026
da18071
order/formatting
RDaxini Mar 30, 2026
14e1c0a
typos
RDaxini Mar 30, 2026
8fb6fab
Update introduction_to_contributing.rst
RDaxini Mar 30, 2026
a1f7e40
Apply suggestions from code review
RDaxini Mar 30, 2026
50046fa
formatting, whatsnew, section reference
RDaxini Mar 30, 2026
fc23299
fix section reference link in whatsnew
RDaxini Mar 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions docs/sphinx/source/contributing/introduction_to_contributing.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,27 @@ contributors from novice to expert. Don't worry if you don't (yet)
understand parts of it.


.. _core-guidelines:

Core guidelines
~~~~~~~~~~~~~~~
While we welcome new contributors, reviewer capacity is limited. Therefore,
following these core guidelines is essential:

* Every pull request (PR) should address one or more open issues. The PR should
be outlined in the issue discussion.
Comment on lines +22 to +23
Copy link
Copy Markdown
Member

@kandersolar kandersolar Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

@cwhanse cwhanse Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about "Pull requests should address one or more open issues." Does that create flexibility for maintainers?

Copy link
Copy Markdown
Contributor

@williamhobbs williamhobbs Apr 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could add "... unless it has been discussed with a maintainer..." somewhere in there.

Copy link
Copy Markdown
Member

@echedey-ls echedey-ls Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take, but I don't really mind whatever wording gets picked:

Suggested change
* 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.

Copy link
Copy Markdown
Member

@AdamRJensen AdamRJensen Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add something along the lines of "If an issue does not exist, please open an issue before proceeding to make a PR.

* 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
Copy link
Copy Markdown
Member

@AdamRJensen AdamRJensen Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
significant PV modeling experience and who are motivated to join the pvlib
some PV modeling experience and who are motivated to join the pvlib

maintenance teams
Copy link
Copy Markdown
Member

@echedey-ls echedey-ls Apr 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
maintenance teams
maintenance team.

edit: applied Adam's suggestion

Copy link
Copy Markdown
Member

@AdamRJensen AdamRJensen Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest writing "team" instead of "teams".

* pvlib-python is an advanced scientific modeling toolbox. A background
in solar energy and/or experience in pvlib-python is required to
address some issues effectively. It is not always clear which issues
fall into this bucket. Don't be offended if maintainers close your PR for
this reason.
* Maintainers reserve the right to close PRs that do not comply with the
contributing guidelines.


.. _easy-ways-to-contribute:

Easy ways to contribute
Expand Down
2 changes: 2 additions & 0 deletions docs/sphinx/source/whatsnew/v0.15.1.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,8 @@ Documentation
* Fix a broken docstring reference to ``grounddiffuse`` in
:py:func:`pvlib.irradiance.poa_components`
(:issue:`2089`, :pull:`2708`)
* Add :ref:`core-guidelines` to the :ref:`introduction-to-contributing` page.
(:issue:`2716`, :pull:`2726`)


Testing
Expand Down
Loading