Move TSC from containerd

[crosbymichael]

Closes #15

Signed-off-by: Michael Crosby crosbymichael@gmail.com

[mlaventure]

Should we still have a paragraph about how technical conflicts are to be handled?

[crosbymichael]

@mlaventure any proposed wording for a paragraph like this?

[mlaventure]

I think we should probably write a TSC document (could probably just be a modified of Moby's. Although I would lower the members to 5 personally). In between I would be fine with just saying any unresolved dispute shall be adjudicated by a small group of predefined maintainers until a TSC is define and an election made.

For the maintainers to start I would personally go with (based on latest activities/investment and companies):

• @crosbymichael
• @estesp
• @AkihiroSuda
• @Random-Liu
• @jhowardmsft / @jterry75

Or we could use the same process as when promoting new maintainers while waiting for us to add a TSC.

[crosbymichael]

I think from the last discussion, we would just defer to maintainers overall to keep from a voting process for a TSC. I think we have a diverse enough group to get wide points of view on things. Maybe a formal process to "escalate" to a vote on certain issues to be voted on as a whole by maintainers would work.

[mlaventure]

In that case, just opening a PR with a proper title could do and the vote can follow the same restrictions as for adding maintainers. That would work for me.

[estesp]

Maybe under conflict resolution we can just have something like:

"If you have a technical dispute that you feel has reached an impasse with a subset of the community, any contributor may open an issue, specifically calling for a resolution vote of the current maintainers to resolve the dispute. The same voting quorums required for adding and removing maintainers will apply to conflict resolution."

[crosbymichael]

Updated with @estesp suggestion for resolutions

[estesp]

LGTM

[lowenna]

LGTM

[stevvooe]

I think we need to be more specific about the quorum requirements. Tying it to maintainer adding vote isn’t enough. I would say 2/3 for big things, erring in the side of not having a change.

[mikebrow]

I think we need to be more specific about the quorum requirements. Tying it to maintainer adding vote isn’t enough. I would say 2/3 for big things, erring in the side of not having a change.

I think the point was we have a quorum requirement for adding and removing, looking above that percent is 66% (2/3) and we can use that here as well. But yeah nbd to repeat that value here vs cite to it. I'm good with the text as is, or edited to repeat the majority quorum requirement separately here.

[crosbymichael]

Updated per @stevvooe 's comment

[AkihiroSuda]

This PR itself should require quorum?

[crosbymichael]

I think we have quorum

[estesp]

I would like to see @stevvooe give a nod on the updated wording; given the approval on the discussion and the number of LGTMs here, I assume we are good but @containerd/containerd-maintainers please take a look at the update.

[lowenna]

Still LGTM

[mlaventure]

Still LGTM too

[mikebrow]

/LGTM

[stevvooe]

LGTM

The wording still links it to maintainer additions. As the project scales, my guess is that we’ll change that. Resolution votes will always be 2/3 or more while maintainer addition criteria may change.

Resolved with LGTM

[dmcgowan]

LGTM

[jterry75]

LGTM