Report on the pull request experiment so far

From: Warner Losh <imp_at_bsdimp.com>
Date: Sat, 25 Feb 2023 23:54:26 UTC
Recently, I committed changes to our handbook that suggested submitting a
pull request for simple changes. Since then, we've had about 30 pull
requests opened. Here's some lesions that I've learned.

First, I've tried to script things so that we have the right tagging so
that pull requests notice when the changes are made. I've discovered that
git has a way to add these things automatically. git commit --amend
--trailer... will do that. However, it assumes a strict RFC822 format,
which means 'Reviewed-by:' is valid, but 'Reviewed by:' is not. I can cope
with this by some pre/post processing, but it suggests that the project may
want to alter its practices. I'd recommended this originally in the git
cutover, but could not point to a good reason to do that. Now I can point
to a good reason: git supports it a lot better.

Second, I'm preparing an update to create CONTRIBUTING.md. See
https://reviews.freebsd.org/D38771 for the review. The only thing so far
I'm unsure of is whether I should place it in .github or not. We're not
planning on doing anything with gitlab at the moment, so I think it's OK at
the top level. We can move it whenever.

We're getting a mixed bag of changes, which has influenced the
CONTRIBUTING. Some are decent bug fixes, while others are some variation on
style changes. I think we'll want to discourage it generally, but accept it
when someone is about to do work in some area. Otherwise we'll be spending
a lot of time on low-value changes. I can understand it is useful to
'train' on, and I'm willing to put up with some level of it, but I don't
want to have lots and lots of things here. A balancing act.

Next, we've had three or four new people pop up, which is cool. We'll see
if they will contribute long term. They are still in the small, useful but
also not super high value range. And that's fine: lots of these changes are
good incremental changes that didn't take me long to land. So we'll need to
find some way to nurture this, and we'll likely need a 'how to land a pull
request and grow new contributors into regular contributors' section in our
handbook. Hopefully the how to land part soon will be 'land with this
script, and it takes care of all the details'.

I also landed one commit that was from 2021. Yikes. The commit date is
right, but the author date is in the past. I suggest that we add a git
commit --amend --date="`date`" to the process. This likely is a good thing.
There's no simple --reset-date, alas: only a reset that also resets the
author.

Finally, I've rebranded our github description. It is now a 'publish only
repo' that we 'process pull requests from' which conveys that it's more
active than just a 'read-only mirror'. I got that language from git's
description and used it because I liked it. I'm open to feedback on this
for ways to make it better. I've wanted to get away from the very passive,
'read-only mirror' description for a while because you can push things to
github and have things happen based on it.

Anyway, that's all for now.

Warner