Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative maintenance strategies for this repository #41

Closed
wking opened this issue Jan 31, 2018 · 2 comments
Closed

Alternative maintenance strategies for this repository #41

wking opened this issue Jan 31, 2018 · 2 comments

Comments

@wking
Copy link
Contributor

wking commented Jan 31, 2018

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 ;).

@caniszczyk
Copy link
Contributor

it's working fine for now :)

@wking
Copy link
Contributor Author

wking commented Apr 6, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants