New process of getting changes into the commitfest app

(Resent because sending to both -hackers and -www gets emails put in
the moderation queue, and I don't want to introduce that delay to all
replies. If you received the previous version because you're in the CC
please only reply to this one)

# Background

As some of you might have noticed I've been trying to breathe some
more life into development on the commitfest app[1], both by
contributing myself but also by encouraging contributions of others.
Basically I'd like to become one of the maintainers of the commitfest
app project. The process to get there has been much more of a struggle
than I'd hoped...

So far I've been sending patches privately to Magnus (who is currently
the only maintainer afaik). Sadly, Magnus usually has a lot on his
plate so he often takes a while to respond. This has made the
turn-around on getting my patches deployed pretty long (even for minor
patches).

I requested Magnus to give me commit access to the pgcommitfest repo
so that I could deploy improvements without having to wait for his
reviews. He didn't think that was a good idea. It turns out we
fundamentally disagree on what's acceptable way to deploy:

Magnus wants reviews before deployment to be required, in an effort to
get as close-to-perfect commits as possible. I, on the other hand,
think that the benefit of close-to-perfect commits is not worth the
delays in deploying that those reviews currently introduce. I'd rather
deploy code more often to get feedback from users, and make quick
improvements/fixes based on that feedback. (this "deploy early, fix
quickly" approach is also what's being done for cfbot repo and I
haven't heard any complaints about it)

After some private emails back-and-forth, one thing that we both do
agree on is that it would be good to move both development and
discussion of new features into the open. So I thought it would be
good to also discuss in the open, what exactly that should look like.

# Proposal for new process

I think the following set of guidelines would be a good start:

1. Development happens on GitHub using Pull Requests (PRs) and Issues
(see last section for why GitHub). Currently that's on my mirror of
the repo[2], but that could be moved under the official "postgres"
GitHub org.
2. Chat discussions around development happen on the #commitfest-dev
channel on the PostgreSQL Hacker Mentoring Discord[3].
3. Ideas for new features should be discussed on the pgsql-hackers
mailinglist to make sure that the users of the commitfest app don't
hate the idea.
4. Small incremental improvements to existing features and bugfixes
don't need pgsql-hackers involvement.
5. Reverts and trivial fixes (typos/forgotten check for None/etc) can
be deployed without review
6. "Big" changes should bake in the staging environment for at least a week.
7. If you're deploying a change, you're expected to be reasonably
available in the next few days after to resolve issues (by reverting
or hotfixing).
8. Feedback/complaints about newly deployed changes can be given on
pgsql-hackers (CC-ing the committer & author) or through GitHub
issues.

Then there's some open questions that require some more discussion:

a. Do all changes that don't fall under 4 require a review? Or are
there certain changes that don't need one (e.g. HTML only changes)?
b. Who can deploy? i.e. can I deploy PRs by other contributors after I
approve them? An example being [2]? Or is Magnus the only person?
c. Is there some time after which a PR can be deployed without review,
even if normally it would require review? i.e. because no-one reviewed
it in "a reasonable" amount of time

# Call for reviews

Magnus also suggested that I ask more people for a review of my
existing commits. That seemed like a good idea, so I created a PR that
contains all the currently not-yet-deployed patches[5]. Note that
normally these commits would be separate PRs, not one big PR, but
given this is a new process and they are already deployed to staging
like this, I just did it this way. I can split them up too though, if
people prefer that. (just let me know)

You can try these changes out on the staging website[6]. For now that
requires credentials, but I hope we can make it publicly accessible
soon. Until that happens just ping me for the credentials.

# Why GitHub?

1. GitHub has CI and issue/patch tracking included (hosting a
commitfest app + cfbot instance, just for commitfest app development
seems like a pain)
2. Web developers are generally much more comfortable with GitHub than
sending patches over email, so this makes the lives of new
contributors much easier.
3. cfbot development is also on GitHub

[1]: https://commitfest.postgresql.org/
[2]: https://github.com/JelteF/commitfest
[3]: https://discord.gg/XZy2DXj7Wz
[4]: https://github.com/JelteF/commitfest/pull/4
[5]: https://github.com/JelteF/commitfest/pull/7
[6]: https://commitfest-test.postgresql.org/