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

Proposed governance and maintenance policy #58

Merged
merged 7 commits into from Nov 13, 2014

Conversation

Projects
None yet
@adamhjk
Copy link
Contributor

adamhjk commented Oct 2, 2014

Below are the proposed governance and maintenance policy for Chef. :)

Before talking about certain roles and ideals, we want to make sure we’re clear about what we mean:

<dl>
<dt>CBGB</dt><dd>Means the Chef Board for Governance – the group of up to 12 representatives who will direct the roadmap and core criteria of the Project.</dd>

This comment has been minimized.

@miketheman

miketheman Oct 2, 2014

Contributor

What does the second "B" in the acronym stand for?

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Badass?

This comment has been minimized.

@jonlives

jonlives Oct 2, 2014

Contributor

If that's not what it stands for, I move that it should become so :p

This comment has been minimized.

@jjasghar

jjasghar Oct 2, 2014

Member

@adamhjk shouldn't it be an odd number not 12? Couldn't in theory something polarizing cause a deadlock?

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Also I would say this should read something more like who will [oversee | advise on | influence | assist with] the roadmap.

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

steer, e.g. a steering committee, means the right thing to me.

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

lets use "advise on" the roadmap


The Maintenance Policy defines how we make decisions about what happens with Chef, and associated software projects. It provides the process by which:

* Roadmaps are decided

This comment has been minimized.

@miketheman

miketheman Oct 2, 2014

Contributor

I think I don't understand the different between the maintenance policy vs the CBGB when it comes to roadmaps - it looks like there is info across both?

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

I've read this a few times and I 👍 this comment - it makes sense it's a shared responsibility, but exactly what's expected of that sharing should be expressed somewhere.

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

CBGB provides input to the maintainer teams when they are prioritizing, that's all.

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

that's awesome! I think that's how it should be. But the CBGB doc says lots of things like "the group of up to 12 representatives who will direct the roadmap" which is very different than "help with prioritizing"... we should clarify one, the other, or both.

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

Yep, I left a comment on that line but I think @adamhjk just hasn't had time to circle back since the summit. The word "direct" will (probably) be changed.

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

👍
(note it's not the only line stating or implying CBGB is responsible for roadmaps)

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

@coderanger has the right interpretation - CBGB -> input to maints


<dt>Scope</dt><dd>Means the issues under the CBGB purview such as: (a) long term roadmap; (b) project policies and procedures around maintenance and contributions; and (c) long term governance model. All initiatives within the Chef Project are required to reside within the Scope.</dd>

<dt>User/Contributor</dt><dd> Means (i) an organization that uses Chef and that has published at least one use case; and/or (ii) an individual contributor to the Project who is not a Company employee or Corporate Contributor.</dd>

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Should be a,b,c like above.

This comment has been minimized.

@juliandunn

juliandunn Oct 2, 2014

Contributor

What does "use case" mean?


* Provide a forum for individuals, users, and companies to discuss the issues within the CBGB Scope.

* Provide guidance and input to Leadership, and where possible, present a consistent and consolidated opinion from the broader Chef community.

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

the Leadership is defined as the Company Leadership + CBGB, so maybe this should say Company Leadership?

@juliandunn

This comment has been minimized.

Copy link
Contributor

juliandunn commented on new/governance_policy.md in 018cf48 Oct 2, 2014

Can you clarify what (c) means? Do we just mean a company that has committed to using Chef software in the conduct of its business?


The CBGB is not:

* Intended to serve as a decision-making governance board. The CBGB advises, but does not manage, the Leadership.

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

As above, should say Company Leadership probably.

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

The "Leadership" is defined above as "the CBGB and Company Leadership (Chef Software CEO)." Do we mean instead "Project Lead and Lieutenants" ?


# Chef Board of Governance

Chef was designed from the outset to have a very open structure, including open design, open contribution, and consistent use of tools across the project. Maintainers include both Chef Software, Inc. and non-Chef Software, Inc. employees. Given the large numbers of contributors, users, and companies with a stake in the future of the project, Chef leadership is looking to establish an advisory board, as part of its long term commitment to open governance.

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

Maintainers include both Chef Software, Inc. and non-Chef Software, Inc. employees.

I feel like this creates an unnecessary dichotomy. Can we say something broader here like "Membership is taken from the Chef community."

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

Yes


The CBGB is authorized to seek advice and counsel from other interested parties and invited experts as appropriate

Any outside party wishing to bring an issue before the CBGB may do so by emailing the CBGB mailing list

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

As you are fond of saying, also made of people so should probably welcome talking to individual reps too who can then bring up to the board on their behalf.

This comment has been minimized.

@adamhjk

adamhjk Oct 17, 2014

Contributor

Would rather they go directly to the board as a whole.


The CBGB is being formed at the discretion of the Leadership. The Leadership alone may decide to terminate the CBGB in its sole discretion; provided however, that the Leadership shall first consult the CBGB Chair.

The CBGB and its members shall abide by appropriate antitrust guidelines.

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

This line seems slightly scary. Not sure what would constitute illegal trust stuffs.

This comment has been minimized.

@adamhjk

adamhjk Oct 17, 2014

Contributor

Just because its scary doesn't mean we don't need it. In particular, we need to ensure that we don't collude to influence the market unduly.


The CBGB shall provide transparent and timely reporting (through any mechanism it deems appropriate) to the Community at large on all of its activities, subject to the right of any individual to designate their comments and the ensuing discussion as "in confidence," in which case the public report shall contain only a note of the request and an agreed summary (if any) of the substance.

The CBGB is being formed at the discretion of the Leadership. The Leadership alone may decide to terminate the CBGB in its sole discretion; provided however, that the Leadership shall first consult the CBGB Chair.

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Company Leadership? (or can the CBGB dissolve itself?)

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

Yes company leadership. CBGB cannot dissolve itself.

@juliandunn

This comment has been minimized.

Copy link
Contributor

juliandunn commented on new/maintenance_policy.md in 018cf48 Oct 2, 2014

Maybe also need some information in here about how any of these people can resign from their duties in a way that ensures the long-term viability of their component. i.e. wouldn't just want someone to just tableflip & bail.

@juliandunn

This comment has been minimized.

Copy link
Contributor

juliandunn commented on new/governance_policy.md in 018cf48 Oct 2, 2014

Assume you meant "Company Leadership" here, otherwise it's self-referential since "Leadership" is defined as CBGB + Company Leadership


Handle contributions on GitHub - first response to a PR within 48 hours
Be available on IRC
Attend the developers meeting (do not miss more than 3 in a row)

This comment has been minimized.

@jonlives

jonlives Oct 2, 2014

Contributor

Note to @adamhjk to clarify what happens when maintainers etc are in an inconvenient timezone for dev meetings

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

We need to just make it part of the deal - lets figure out something that works. The reality is, going to be hard to be a maintainer without being in the meetings

Weekends and local holidays in the maintainer’s jurisdiction are not counted for timeliness requirements. Absences for reasonable causes such as vacations, illness, etc. are also acceptable; Maintainers should notice of absences via the development mailing list whenever possible.
Committed to 100% tests passing for your component
Has full commit/merge access to the relevant repositories
Has ops on IRC

This comment has been minimized.

@juliandunn

juliandunn Oct 2, 2014

Contributor

Presumably we would retrofit existing ACLs in IRC, which I'd be 👍 to

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

Yes


Throughout the project: anyone should be able to participate and contribute. All bugs and tasks will be tracked in a public tracker and all of the source code and all of the tools needed to build it will be available under an open license permitting unrestricted use

Open technical meritocracy: technical merit over pride of authorship. Code is contributed for the express purpose of advancing technologies relevant to the project, effectively separating technology advancement from individual or commercial intent.

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Please don't use the word meritocracy :-( It is a keyword that invokes a lot of badness for many people.

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

Ok.


(ii) All Other Seats: All other members of the CBGB will be replaced upon any of the following: (1) End of term; or (2) majority vote of all other members of the CBGB.

## Operation

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

Quorum of 50% of current membership? Majority vote?

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

majority vote.


Influence through contribution: organizations and individuals gain influence over the project through contribution.

IP Cleanliness: Steps are taken to ensure that all incoming code is legally contributed (CLAs terms-of-use etc.), that use of approved third party libraries does not create incompatible dependencies

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

(CLAs, terms of use, etc.)


IP Cleanliness: Steps are taken to ensure that all incoming code is legally contributed (CLAs terms-of-use etc.), that use of approved third party libraries does not create incompatible dependencies

Open Licensing: code should be licensed using approved, standard, open-source licenses. (Chef is currently licensed under Apache 2.0).

This comment has been minimized.

@coderanger

coderanger Oct 2, 2014

Contributor

Worth noting that RFCs are not technically under an open source license because PD is an un-license.

This comment has been minimized.

@adamhjk

adamhjk Oct 17, 2014

Contributor

RFCs are not code.


### Maintainers

## Platform Specific Components

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

A platform should be a tier 1 and/or tier 2 supported platform in RFC021 to have a Lieutenant.

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

No - if you love it, you can maintain it.


Resolves disputes
Provides vision and roadmap
Has universal veto power

This comment has been minimized.

@jonlives

jonlives Oct 2, 2014

Contributor

I think it would be worth clarifying the process of appeal in a separate section, ie maintainer -> Lt -> project lead just to make explicit the veto chain


If you would like to speak to, or understand the position of, someone at Chef Software - feel free to drop a line to [info@getchef.com](mailto:info@getchef.com) - and we’ll get back to you. Or simply ask for the companies official perspective in any of the community spaces, and a representative will get back to you in that space.

The MAINTAINERS file in Chef

This comment has been minimized.

@btm

btm Oct 2, 2014

Member

Move this line below the header below.

@coderanger

This comment has been minimized.

Copy link
Contributor

coderanger commented Oct 2, 2014


<dt>Company Leadership</dt><dd>Means the CEO of Chef Software Inc.</dd>

<dt>Corporate Contributor</dt><dd>Means a company that (a) is one of the top eight companies in terms of non-trivial pull requests in the past six months as measured by contributions by all employees; (b) a company that has employees as Maintainers who make significant contributions to the Project; and (c) has committed to integrate Chef software into its products.</dd>

This comment has been minimized.

@jonlives

jonlives Oct 3, 2014

Contributor

is this one a) AND b) AND c) or is it a) OR b) AND c)

This comment has been minimized.

@adamhjk

adamhjk Oct 17, 2014

Contributor

All.

* No veto from the component lieutenant
* No veto from the current project lead

## Lieutenant

This comment has been minimized.

@juliandunn

juliandunn Oct 3, 2014

Contributor

So @jaymzh and I were chatting in the hallway at Summit and contemplating the role for lieutenants that aren't tied to a specific subsystem. There are potential overall changes in the core Chef codebase that aren't easily attributable to a subcomponent, so what do people think about that?

This comment has been minimized.

@jaymzh

jaymzh Oct 4, 2014

Member

I mentioned this to @adamhjk and he said the right thing here is probably "core", which seems reasonable to me. I shall propose myself as an LT/M for core once this is merged.

Release calendar for code outside of chef client/chef server
Resolves disputes within their subsystem
Has localized veto power
Plus all responsibilities of a maintainer

This comment has been minimized.

@cwebberOps

cwebberOps Oct 8, 2014

So it isn't super clear to me... is there An Lieutenant per subsystem or can there be more than one Lieutenant per Subsystem?

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

There will only be a single LT per subsystem.

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

Hmm. I wonder if that's scalable. Lot of responsibility on one person's shoulder's, especially if it's a big subsystem and they're not a Chef employee. How about a recommendation of one, but ... up to 3 (or even 5) as the discression of the existing LTs and the Project Lead?

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

I think the plan is to adjust the scope of subsystems to keep things manageable. Having a few LTs could work, but we would need to figure out how disputes are resolved. Having a single inheritance tree makes that part easy :)

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

Sure - I'm just saying some subsystems are necessarily bigger than others. For example, I'd be willing to share LTership of Client Core, but I certainly wouldn't dream of volunteering to do it myself. This leaves me with being a maintainer, which is fine, but also doesn't give me an option to do more even if I'm willing to.

This comment has been minimized.

@ranjib

ranjib Oct 8, 2014

Member

@jaymzh @jonlives oh yeah, i didnt knew core is considered as single component, i was under the impression that event dispatch, platform specific providers, solo, zero, run list expansions all being separate components. Initially we might keep functionally similar components in same bucket :-) . I just checked noah's google doc on the components, core as a whole, lead by a single LT will be too much

This comment has been minimized.

@ranjib

ranjib Oct 8, 2014

Member

regarding 'seeing the system as a whole' thing, i thought thats a common responsibility to all the LTs, they might have deep understanding of one subsystem, but all of them needs to understand how these components fit together, this can be relaxed for external subsystems (like chef-container etc), do you think we should state this explicitly? or delegate that to dedicated roles and formalize that in the RFC

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

I really think (and want the role of) a set of people who watch the bigger picture. Who look at the changes the various subsystems make and go "woah, these two things you two are working on are going to make a worse experience together"

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

@jaymzh That is more related to the CBGB than the LT/Project Lead structure. The LT exists mostly to settle disputes and do paperwork :)

But thats also something all community members should be doing I hope, if someone is doing something dumb just say so.

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

The LT team as a whole is that team, @jaymzh - @ranjib has this right.

Handle contributions on GitHub - first response to a PR within 48 hours
Be available on IRC
Attend the developers meeting (do not miss more than 3 in a row)
Be available to answer mailing list questions within 48 hours

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

Can we specify if this means -dev or -users? -dev is pretty low-traffic, but -users is very high traffic for stuff covering all subsystems of all projects and keeping up with it all for smaller subsystems may not be reasonable. As there become more projects and more subsystems that would get worse. The same problem would in theory hold true for -dev but seems to not be an issue at the moment. Either way, we should clarify.

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

I read this more as that the maintainer team as a whole should be able to respond. This would take the place of the "Official Company Response" that a lot of people want to see now.

This comment has been minimized.

@jaymzh

jaymzh Oct 8, 2014

Member

Hmmm. I like that interpretation. Though it certainly means the very first person to sign up for maintainership has some very tough responsibilities to measure up to. That may be OK... but it also may scare away people who want to maintain a small subsystem they know well, but don't want to have to be "on call" for email every 2 days. Again, that may be totally acceptable... but it's worth considering.

This comment has been minimized.

@jonlives

jonlives Oct 8, 2014

Contributor

Again with @jaymzh - depending on how many maintainers we get in the initial set, this could be a lot of work for one or two people. It'd also be good to clarify whether this means answering questions on the development of the feature in question specifically, or if this relates to all questions relating to that component, including more general "how do I do X" support.

This comment has been minimized.

@coderanger

coderanger Oct 8, 2014

Contributor

The LT role for some of the bigger subsystems is definitely a full-time job. One that I hope Chef Software will continue to support :)

This comment has been minimized.

@adamhjk

adamhjk Oct 15, 2014

Contributor

Yes, maintainers as a whole.

@ranjib

This comment has been minimized.

Copy link
Member

ranjib commented Oct 8, 2014

👍 the proposed format in its current shape is good enough for us to begin. We can revisit this as and when its needed, whats more important is to get this going and start working on these structures, as it will give us some early feedback (after which we might have to accommodate some changes in the proposed structure anyway ... like the respond within 2 days of raising a PR etc)

@sersut

This comment has been minimized.

Copy link
Member

sersut commented Oct 8, 2014

Ditto @ranjib. +1

@coderanger

This comment has been minimized.

Copy link
Contributor

coderanger commented Oct 8, 2014

I don't want to put words in @adamhjk's mouth, but I know sub-delegation has been discussed. I think the plan was to start with these somewhat broad categories and look in to additional delegation if we think this overall structure is working well. Minimum viable culture :)

@adamhjk

This comment has been minimized.

Copy link
Contributor

adamhjk commented Oct 17, 2014

Updated to reflect the changes I commented on this thread.

Be available on IRC
Attend the developers meeting (do not miss more than 3 in a row - special dispensation can be made for difficult time zones)
Be available to answer mailing list questions within 48 hours
Weekends and local holidays in the maintainer’s jurisdiction are not counted for timeliness requirements. Absences for reasonable causes such as vacations, illness, etc. are also acceptable; Maintainers should notice of absences via the development mailing list whenever possible.

This comment has been minimized.

@danielsdeleo

danielsdeleo Oct 31, 2014

Member

Missing the verb in "Maintainers should notice of absences." "provide" works.


* Project Lead: Initial Project Lead will be Adam Jacob. Any new Project Lead candidate will be selected by a majority vote of the Lieutenants, and approved by Company Leadership. This selection will happen according to the Maintenance Policy.

* All Other Seats: Candidates who meet the criteria for each group identified above will be elected by at least a majority vote of all qualified voters: +1

This comment has been minimized.

@coderanger

coderanger Nov 9, 2014

Contributor

What defines "qualified voters"? I think maybe this was a thought that got cut off.

Jon Cowie and others added some commits Nov 11, 2014

@adamhjk

This comment has been minimized.

Copy link
Contributor

adamhjk commented Nov 13, 2014

This has my 👍 to merge. We have one more change we are going to make, which is a clarification that anyone with a supermarket account is a registered voter.

@opscode/rfc-editors can merge when that is done. Long live Chef!

I want to publicly thank @coderanger for carrying this policy forward so strongly.

coderanger added a commit that referenced this pull request Nov 13, 2014

Merge pull request #58 from opscode/gov_maint
Proposed governance and maintenance policy

@coderanger coderanger merged commit b7bb7c6 into master Nov 13, 2014

@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Nov 13, 2014

🎉

@jtimberman jtimberman deleted the gov_maint branch Nov 14, 2014

@jtimberman

This comment has been minimized.

Copy link
Member

jtimberman commented Nov 14, 2014

🍨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment