I'm thinking of using PullApprove to enforce the two LGTM sign off

All decisions are pull requests, and the relevant maintainers make decisions by accepting or refusing the pull request. Review and acceptance by anyone is denoted by adding a comment in the pull request: LGTM. However, only currently listed MAINTAINERS are counted towards the required two LGTMs.

We probably won't have Go code to lint or format in this repo, but having Travis run git-validation will help catch whitespace issues and such here before they trickle downstream (e.g. here). By having a .travis.yml in this repo, there's a chance of merge conflicts when pulling template updated into the downstream projects. But I expect the file will be pretty stable and any merge conflicts easy to resolve. If this sounds like a useful direction, I'm happy to work up a PR.

I'm suggesting that we pick one of the active repos and then re-do this template repo based on that

Then we can also close out any existing PRs. cc @vsoch @wking @caniszczyk

Some decent options:

• distribution-spec
• runtime-spec
• umoci
• runc
• Some combo of several?

This is listed under "Tier 1: Replace Immediately" in the Inclusive Naming Initiative:
https://inclusivenaming.org/word-lists/tier-1/#master

There about a thousand things more important to contributing than the name of an incoming branch. No need to burden contributors further with that kind of sillyness.

This requirement is silly, unnecessary and provides no benefit to the project.

Since #29 was merged back in 2017-03-17, the plan was for this repository to be maintained by maintainers from all the OCI Projects (as listed in .pullapprove.yml). But that hasn't really worked out. There are some LGTMs using that approach in #40, but so far the only PRs landed since #29 are #33 and #36, both of which were merged by @caniszczyk without any maintainer LGTMs. Most existing projects already have governance docs, so maintainers of existing projects aren't directly impacted by bugs in this repo. They may muster the energy to fix typos locally (e.g. opencontainers/runtime-spec#752) but not have the bandwidth to follow through and update the templates (e.g. #36). Having a pan-OCI-maintainer consensus would be nice (#4), but we don't seem to have the time or interest to accomplish that. In order to unstick this repository (which continues to be used as a template for new projects, e.g. in opencontainers/tob#35), I can think of a few possible approaches:

• Just make @caniszczyk the sole maintainer. This is pretty close to what we have now, and if @caniszczyk is willing to formally assume this role, he'll probably have an easier time of it as himself than if he's trying to channel the spirit of the OCI maintainer community.

• Make the maintainer set “the current TOB”. As direct consumers of this repository (when spawning new projects), they have a vested interest in improving this repository in the run up to any new project creation.

• Form a new OCI Project to maintain this repository. Find a set of maintainers who are actually interested in maintaining this repository, instead of assuming that all OCI maintainers (of any project) are interested. To avoid having too many hands at the wheel, I'd recommend selecting the maintainer set (at least initially) from people who are currently maintainers of some other OCI project.

Thoughts? I think all of these have a decent chance at working, but am not sure which of them has the best odds. I'm happy to work up a TOB proposal for the second two approaches; if we switch to the first approach can update this repo with the current “@caniszczyk makes an executive decision” approach ;).

@crosbymichael we should apply this across OCI projects once it's finalized