A more robust PR template and contribution guidelines

[kennethshsu]

Description

My goal is for me personally is to make sure this package stays robust and maintains consistent, high-quality PR reviews. With the rise of AI generated slop projects on GitHub, I want to make sure this clearly isn’t one of them.

I’d like to hear thoughts on what guardrails we should put in place around PRs and AI usage.

I opened a PR on this a while back, but I’d love feedback on what others would like to see. Some of the language, especially around credentials, may be stronger than needed, and I’m certainly not attached to any specific wording. The goal is not to limit PRs or participation, but to maintain a high standard of quality for contributions and reviews.

Is your feature request aligned with the scope of the package?

• Yes, absolutely!
• No, but it's still worth discussing.
• N/A (this request is not a codebase enhancement).

Describe the solution you'd like, or your current workaround.

• Implement new contributing guidelines, especially regarding AI tools usage
• Improve the PR template
• (maybe) How does one become a code owner (and therefore an approved PR reviewer)

Do you have any additional supporting notes?

No response

[genedan]

Bringing in my thoughts from other discussions. I think the contribution guidelines should be modeled after those of other big open source projects such as:

• Python Enhancement Proposals (PEPs)
• Pandas Contributing Guide
• Pandas Enhancement Proposals (PDEPs)

Our project is smaller, so we should just take what we need and then grow the guide as needed. I had proposed a set of CEPs (Chainladder Enhancement Proposals):

• CEP 1: Purpose and Guidelines (contains info about codeowners, continuity planning, voting rules for resolving disputes, adopting new features, etc.)
• CEP 1: AI Usage
• CEP 2: Pull Request review guidelines
• CEP 3: Docstring conventions

Other sub-pages for the contributing guides would include things for:

• Documentation formatting
• Unit test conventions
• Class design & deep-dive internals
• Deprecation guidelines
• Release schedule checklist & guidelines

Our current contributing page is a "here's the gist of what you need to know to get started", which I think should stay that way, but we should move it to a top-level page and add subpages, which can get into the details. Our practices have grown organically, and a lot of them aren't written down, or at least not in a central location.

For example, even the somewhat lengthy #704 issue wasn't enough to contain all the guidelines related to docstrings. Henry added more of his own as we went along - and those are just for the code examples! There would be more conventions for where to put the docstring within the class definition, what sections are needed (Parameters, Attributes, Returns, etc.), which style convention we use - Google style? numpy style? (turns out we use numpy style). These would be items that would belong in a subpage of the Contributing Guide, but not the top-level page.

I'm asking for a lot, so I think this issue should be tagged as being a serious effort with a significant impact.