[pgsql-www] Commitfest Application unconference notes - Mailing list pgsql-www

From Peter van Hardenberg
Subject [pgsql-www] Commitfest Application unconference notes
Date
Msg-id CABTbUph73cKLHkJPKrtMwQpBWEGVdN3VQjhcKfCBwVmuh=_C8w@mail.gmail.com
Whole thread Raw
List pgsql-www
As noted in the previous thread, we had a fairly productive conversation about the commitfest application at the unconference in PGConf.Asia. Here are my notes from that session, which included (among others) several patch authors, a commitfest manager, as well as Magnus, Joe Conway and Dave Page from the infra team.

The goal of the session was to discuss ways that the commitfest app might help encourage people to do more reviewing, as well as to identify usability issues for average commitfest users. (We concluded that the present task of the commitfest manager can be a little bit fiddly but is not burdensome.)

Here's an accounting of the issues with some suggested improvements:

# Determining what to review

## Does a patch have consensus around design/approach on the list?

There is an annotation mechanism that doesn't get much use right now. Consider adding comments / annotations more obviously during patch attachment and/or state changes. Consider adding a new patch state like "Under Consideration" which a patch starts in before going to "Ready for Review".

## Is the patch readable / testable / difficult / easy?

It can be tricky to figure out which patch to apply, and there's no "stats at a glance" to help a reviewer guess how relevant a patch might be to their interests / experience / available time. Consider adding some patch details like patch file size on the review. Consider automatically trying to apply any patch that gets posted to the CF app to the current HEAD at some interval and complain if it doesn't work.

## Does the patch already have enough review coverage?

Sometimes a more junior reviewer might benefit from additional review by a more experienced community member. Some patches really need many eyes on them to cover different issues. Sometimes a reviewer might grab a patch and then get too busy to follow through. Automatically reviewing idle reviewers from patches might encourage follow-through, as would some form of automated nagging.

## Do people know about the commitfest app? How to submit patches? (etc)

The developers FAQ and wiki could use a good edit and stream-lining. Finding the commitfest app is a subtle thing. Once you do find the app, the patch submission form doesn't necessarily prompt or fill in information as smoothly as it could.

## Should we nag people more? 

Attention is a limited quantity and we should be respectful of people's time and attention, but we could give people a way to opt into reminders when review periods start or to remind them they signed up to review a patch. (Perhaps signing up for a review could include a date you promise to have reviewed the patch by?)

## Landing Page Redesign

The current landing page has some confusing terminology and doesn't really take advantage of being the default page. With a little bit of work we could probably build a personal view of the world which showed your patches in review, the reviews you've committed to, and the upcoming relevant dates for the future. Specifically "Future", "Open" and "In Progress" were highlighted as potentially confusing terms. and "Planned", "Open for Submissions" and "In Review" were suggested as alternatives.

-p

There were probably other notes -


--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt."—Kurt Vonnegut

pgsql-www by date:

Previous
From: Peter van Hardenberg
Date:
Subject: [pgsql-www] Simple README for pgcommitfest2 and an update to requirements.txt
Next
From: "Ideriha, Takeshi"
Date:
Subject: [pgsql-www] Wiki editor request