You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ;).
The text was updated successfully, but these errors were encountered:
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 ;).
The text was updated successfully, but these errors were encountered: