Re: Clarifying Commitfest policies

On Thu, 4 Aug 2022 at 20:38, Jacob Champion <jchampion(at)timescale(dot)com> wrote:
>
> On Wed, Aug 3, 2022 at 2:05 PM Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> > On Wed, 3 Aug 2022 at 20:04, Jacob Champion <jchampion(at)timescale(dot)com> wrote:
> > > 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.
>
> Agreed, a sweep of those materials would be helpful as well. I'm
> personally focused on CFM tasks, since it's fresh in my brain and
> documentation is almost non-existent for it, but if you have ideas for
> those areas, I definitely don't want to shut down that line of the
> conversation.

Nor would I want to hold you back on CFM documentation.

> > 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.
>
> Right. So what kinds of info do we want to highlight in this
> documentation, to make it high-quality?

I think it would be a combined and abbreviated version of the detailed
manuals that we (will) have: The pages "Submitting a patch" and
"Reviewing a patch" on the wiki, and the CommitFest manual (plus
potentially info on CFBot).

The first part of "So, you want to be a developer?" seems like a very
good starting point for dense, high-quality entry-level documentation.
Each section should then further refer to the relevant sections of the
"Developer FAQ" and the "Submitting / Reviewing a Patch" pages for the
in-and-outs of the specific procedure (such as "installing development
dependencies", "reviewing changes", "code style", etc.).

> Drawing from some of the questions I've seen recently, we could talk about
> - CF "power" structure (perhaps simply to highlight that the CFM has
> no additional authority to get patches in)
> - the back-and-forth process on the mailing list, maybe including
> expected response times
> - what to do when a patch is returned (or rejected)
>
> > 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
>
> (I think some text got cut here.)

... This could help reduce the amount of mis-addressed (maybe better
word: mis-located?) contributions, and potentially help the
contributor get involved at -hackers. Indeed this process is much more
involved than 'just' opening a pull request, but at least it is now
slightly more visible.

> The mirror bot will point you to the "So, you want to be a developer?"
> wiki when you open a PR, but I agree that a CONTRIBUTING doc would
> help prevent that small embarrassment.

That's news to me, but nice to see some improvements there. I have
previously noticed that there were PRs on GitHub that went unnoticed
for several weeks, so this bot is a significant improvement.

Kind regards,

Matthias van de Meent