Mini-post-mortem on PRs we can't accept?

[it33]

When a contributor creates a PR we cannot accept, it's a failure on the part of the open source project, not on the contributor.

Mattermost is an advanced code base and people submitting PRs are typically highly intelligent.

Every instance of a PR not being accepted is a failure in the processes of the open source project and it wastes the potential contributions of what is usually a highly talented person. At the same time, it is an opportunity to improve our contribution guidelines, our documentation, our automation and the future of the project.

Propose we figure out a way to do mini-post-mortems on PRs we can't accept to make these improvements, as well as train future core committers and community advocates on how to run our processes well.

[justinegeffen]

@jasonblais, perhaps this can be documented in the Community section of the Handbook with some helpful guidance around reasons a PR may not be accepted. Something like:

"My PR wasn't accepted - why?

Sometimes we may close a PR and not accept the changes. Sometimes a PR includes changes to code/content that's in the process of being deprecated. In other cases, the change may not add value or improve the code/content (e.g., the addition of a comma where one isn't needed). We look at all PRs and assess them - we never close PRs on a whim and we welcome feedback about our decisions."

[jasonblais]

Thanks @justinegeffen - that may work for documentation. The original intent with this proposal was to find opportunities to improve our contribution guidelines, our documentation, or our automation when a PR cannot be accepted, and one way of doing that was through mini-post-mortems. We've done some of these in the past, but not consistently.

This now falls more under @BenLloydPearso's ownership, so will defer to him whether this is something we'd want to do.