Containerd: [governance] Clearer documentation of containerd maintenance processes

[estesp]

Discussed at Hangzhou Alibaba Group containerd meetup:
Suggestions on topics where core containerd maintainers may have general ideas/workflow, but as the project grows we should be more specific on:

• clearer process and documentation for maintainers/contributors for backport to release/1.x
• how to decide about Golang upgrades on stable release branches? Issue: Golang lifecycle/support timeframe re: future CVEs, bugs, etc.
• how to determine need for dependency update (boltdb, as one example) in stable branches
• deprecation policy? (e.g. built-in vs. not-built-in; for example, moving aufs to a proxy plugin)
• support policy/docs on "official" plugins vs. 3rd party vs. out-of-band (proxy)

cc participants: @fuweid @dmcgowan @Random-Liu @Ace-Tang @AkihiroSuda @allencloud @tonistiigi and Alibaba Group, Ant Financial, and Alibaba Cloud teams

[crosbymichael]

All sound good updates to make

[craiglpeters]

Agree that these 200 type issues should be addressed. But I think some 100 type issues like regular meetings, recordings, and meeting notes that are open to all would help too. Then some guidance for people new to the community who want to play different roles (e.g. reviewer, documenter, question answerer, contributor, and committer) could go a long way towards making it easier to grow the community.

[estesp]

Thanks @craiglpeters. Because of containerd's narrow scope, after the initial push for "1.0" functionality we let regular community meetings/meeting notes peter out given it seemed like most discussions on smaller issues are easily handled with regular GitHub and Slack activity in fully visible issues and channels. That doesn't mean we shouldn't have community meetings, and we just had a 1.4 release planning meeting that we publicly announced (and recorded) for open discussion (which I think we will do for every release).

Given runtime implementations tend to have a small and focused community, and containerd now has approx. single-digit PR weekly flow, what do you think would be most helpful for those who aren't on the "inside" of our community as far as a standing meeting and scope of discussion?

To your second point--more contributor documentation seems like a reasonable immediate improvement we could make. We don't have formal roles for anything other than "reviewer" and "maintainer" although "contributor" is assumed by nature of our guide being a "Contributing" document. Would you suggest that there be specific sections for the types of contributing you mention?

Thanks!