Re: Clarifying Commitfest policies - Mailing list pgsql-hackers

On Wed, 3 Aug 2022 at 20:04, Jacob Champion <jchampion@timescale.com> wrote:
>
> [was: CF app: add "Returned: Needs more interest"]
>
> On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > I'm afraid that
> > patches will still be left alone to rot and there still be no clear rules on
> > what to do and when, reminder for CFM and such, and that this new status would
> > never be used anyway.
>
> Yeah, so the lack of clear rules is an issue -- maybe not because we
> can't work without them (we have, clearly, and we can continue to do
> so) but because each of us kind of makes it up as we go along? When
> discussions about these "rules" happen on the list, it doesn't always
> happen with the same people, and opinions can vary wildly.
>
> There have been a couple of suggestions recently:
> - Revamp the CF Checklist on the wiki. I plan to do so later this
> month, but that will still need some community review.
> - Provide in-app explanations and documentation for some of the less
> obvious points. (What should the target version be? What's the
> difference between Rejected and Returned?)
>
> Is that enough, or should we do more?

"The CF Checklist" seems to refer to only the page that is (or seems
to be) intended for the CFM only. We should probably also update the
pages of "Commitfest", "Submitting a patch", "Reviewing a Patch", "So,
you want to be a developer?", and the "Developer FAQ" page, which
doesn't have to be more than removing outdated information and
refering to any (new) documentation on how to participate in the
PostgreSQL development and/or Commitfest workflow as a non-CFM.

Additionally, we might want to add extra text to the "developers"
section of the main website [0] to refer to any new documentation.
This suggestion does depend on whether the new documentation has a
high value for potential community members.

Lastly, a top-level CONTRIBUTING.md file in git repositories is also
often used as an entry point for potential contributors. I don't
suggest we copy all documentation into the main repo, just that a
pointer to our existing contributer entry documentation in such a file
could help lower the barrier of entry.
As an example, the GitHub mirror of the main PostgreSQL repository
receives a decent amount of pull request traffic. When a project has a
CONTRIBUTING.md -file at the top level people writing the pull request
message will be pointed to those contributing guidelines. This could

Thank you for raising this to a topical thread.

Kind regards,

Matthias van de Meent

[0] https://www.postgresql.org/developer/