Skip to content

Update contributing guidelines: solar energy experience, GSoC, avenue to close PRs #2716

@RDaxini

Description

@RDaxini

Is your feature request related to a problem? Please describe.
Ongoing discussion between maintainers regarding vetting contributors and GSoC spam PRs, and avenues to close low-quality PRs, all three of which are linked.

Describe the solution you'd like
The contributing homepage is currently a table of contents.
We can keep that structure or change the default to the intro page. Either way, I propose updating the first paragraph of the intro page to include the following points:

  1. pvlib-python is an advanced scientific modeling toolbox
  2. we welcome new contributors
  3. Reviewer capacity is limited
  4. PR contributors should have a background in solar energy/PV
  5. New contributors opening their first PR should clearly state that they have some background experience in PV
  6. Maintainers reserve the right to close PRs that do not comply with the contributing guidelines
  7. GSoC: TBD

Note on points 4–6:
all contributors are already required to read the contributing guidelines and tick the box to state they have done so in the PR template. Stating (or not) that they have PV experience serves as check of whether they actually did read the guidelines. At the maintainer's discretion, not reading the guidelines is sufficient grounds to close a PR because this is already a requirement for pvlib.

So, 4–6 serve three purposes: vetting contributing guidelines have actually been read, verifying the contributor has solar experience, clearly documenting a procedure/reason for maintainers to close PRs.

Describe alternatives you've considered
None really, whatever we do as a community to handle these issues is our decision that needs to be confirmed, but whatever it is that we do end up doing needs to be documented clearly and openly. The goal of this issue/PR is to document our policy and processes.

Additional context
I'm trying to keep the points being added to the docs simple and straightforward, and mostly in line with what we are already doing anyway. The hope is that this is therefore not a controversial suggestion and we can just get something clear in the docs on which we all agree.

Let's leave this issue open for a bit for feedback and we can reach a rough consensus then, if we are happy, I'll open a PR to finalize wording.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions