Governance

[danzilio]

In an effort to make the Vox Pupuli governance structure less opaque, we should come up with a charter that outlines:

• what the community managers do
• how to become a community manager (election, hand raising, bribing)
• what a community manager is empowered to do on behalf of VP
• when the community managers need to agree
• what agreement means in this context
• how to resolve disagreements between community managers
• when the community managers are required to meet
• how to remove a bad community manager (bad as in bad acting)
• whether community managers have terms and term limits
• how to stop being a community manager

This is not an exhaustive list. The term 'community manager' is a new one, it loosely refers to what are now project maintainers.

Please share your thoughts/suggestions/rants/etc here.

The AC for this issue:

• [x] a draft of a charter that answers the questions above (and any others raised during discussion)
• [x] a process for adopting the charter

[igalic]

i've dropped the word "community manager" perhaps because i aspire to be as cool as Kara, Meg, and puppetlabs' no longer community manager Dawn, or perhaps because if we chose "board of directors", i'd have no idea which direction to lead us…

[danzilio]

I like the idea of a 'board of directors' over 'list of community managers' if only because it makes it feel a little less subservient. Plus, 'community manager' is an established field which may or may not align with our definition.

[igalic]

"cat herders" ;)

anyway, we should move away from semantics and give place to real people discussing this.

[ffrank]

To me the most prominent question is: Do we want the cat herders to be more than CoC enforcers? I would be very happy if all things that are "not hard" rely on community self governance. (I'm almost surely missing some other things as well.)

[igalic]

@ffrank i was gonna ask the same thing, essentially.

what kind of powers reside where?

• who decides whether a module is accepted / rejected?
• who holds power over handing out access to repositories
• who invites new contributors?

what kind of guidance does the community need that cannot be decided in a democratic process?

• this is if we instate a "board of directors"

what kind of interface does the community need to an umbrella foundation?

• such as the software freedom conservancy?

[danzilio]

To your point @ffrank, I think charters like this are written mainly to address the things that are hard. I have confidence that we can self organize for most things, but a charter will help us handle the things that can't be resolved easily.

@igalic these are definitely the right questions to answer.

[igalic]

i just saw this… perfect tweet from @othiym23, and thought i persist it here.

@LennyMarkus any system that involves people that appears self-maintaining is a product of careful management and effort by _somebody_

— Forrest L Norvell (@othiym23) February 12, 2016

[danzilio]

This is interesting: https://github.com/docker/opensource/blob/master/MAINTAINERS

[ffrank]

@danzilio Agreed! I'd love to adapt this to serve as a compilation of answers for the org. Even though the project is currently much smaller than Docker, it would probably be a good idea to plan all these workflows ahead of time (i.e. now-ish).

I don't feel that the BDFL model is a good fit, unless either of the original founders steps up and declares willingness. Otherwise, this is where things get a little more complicated, and we need to implement a voting system, define terms etc. But I really do feel that this extra mile will make it that much easier to ensure a healthy community down the line.

I only skimmed the Docker maintainers list, but it appears that all the role definitions fail to address the need to enforce conduct rules and possibly exclude people from contributing or otherwise engaging the community. The "community manager" role is defined quite vaguely. I feel that this is a place were we should definitely improve upon the cue.

[juniorsysadmin]

@danzilio What things are hard but are a common occurrence, or are becoming increasingly 'common' ? If that's the point of a charter, then those are the things you want to be prepared for before they eventuate.

[vmbrasseur]

I don't have a horse in this race, but @igalic pointed me at this issue & asked whether I had any thoughts. That was weeks ago (sorry, Igor!), but I've finally made the time to give the issue a look. As I was doing so, I captured my thoughts in this gist, but to make it easier for you I've pasted in the contents below.

---

Igor pointed me at the governance discussion and asked whether I had any feedback. I'm finally getting around to having a look at it. What follows will be a stream of consciousness thoughts that occur as I review the issue. It could be I'll discover some of these issues addressed further down in the issue comments. Or maybe not. Let's find out! :-) /me commences reading…

• The process for changing the governance must be discussed. Too often it's not at the start then an org finds that not only has the structure it chose originally no longer meet their needs, but also they've created a structure which is not able to be changed. They're locked in. The governance structure must be able to evolve along with the organization.
• The semantics/naming of these people does actually matter. It implies responsibilities. So perhaps getting those hammered out first makes more sense, then pick a name to support/describe those responsibilities?
• As far as module inclusion goes, the "who" is important but also the "how", the "criteria for inclusion", and the "responsibilities after inclusion." Getting that out in the open may help people decide whether to go through the effort of contributing their modules.
• Discussing/resolving all of these questions up-front is what enables a self-managing organization. Without this level of discussion in advance there ends up being a lot of chaos later on.

[nibalizer]

Sorry I haven't been active on this issue. Part of the reason for that is such conversations are important enough to require a great deal of thought.

I feel strongly we should not roll our own governance. The docker project's governance/maintainers thing was listed and I don't think that a BDFL model will work well for us. I'd like to see us take a few existing governance structures and review them, ultimately deciding on one set of governing documents that we land in some repo and stick to. Since we will likely end up applying to SFC anyways, it would be useful to get some input from someone over there.

I'll take some time to review the OpenStack governance and decide whether or not to pitch that model. That might end up being way too heavyweight for us but maybe we could take the core of it or something.

I would expect we emerge with a charter or purpose document that very shortly describes our goals, a document (or documents) describing our governance, and a list of leaders that will be responsible for taking action inline with the governance documents to effect the purpose described in the charter.

[roidelapluie]

Real question is do we need this?

[nibalizer]

@roidelapluie yes I think we do. The logic goes something like this, in order to hold copyright, assets, etc we need some kind of legal personality. The easiest way to do that is to join something like the software freedom conservancy, in order to do that we need to have a reasonably well thought out governance structure.

[ffrank]

Another important reason in my book is that we want to be prepared for the eventuality that something goes horribly wrong. In such a case, the right people should know how to take action. I don't want to end up in the center of yet another freebsdgirl type situation.

[roidelapluie]

okay. to me voxpupuli has always been a namespace on github and irc, nothing more.

[nibalizer]

Yes I agree with Felix. If something went south or weird in some direction, I want to know (at a minimum)

a) Am I part of the governance group? b) What am I empowered to do about it personally? c) What am I emporwered to do about it in consultation with other governors? d) What am I only empowered to do when the entire voting population is considered?

This information would be contained in the charter that @danzilio opened this issue to generate.

See the rename from puppet-community to voxpupuli for something that was hard to do because we weren't sure what the governance of our organization was.

[igalic]

Is there a way to answer these above questions that @nibalizer posts, while also answering the ones from the SFC? Or do we want to keep that separate for now?

---

writing this line took a really long time… a month of absence due to travel, sickness & moving countries, and then three days of staring at this discussion again…

[igalic]

Recently i had a discussion with someone from the software freedom conservacy, and i also gave a talk on the subject of … well, Voxpupuli… some of the things have crystallized in those interactions, but also through observations i've made in the last couple of months preparing this talk

---

• [ ] owners are not the same people as project maintainers
• [ ] not all owners/project-maintainners have access to our secrets
• [ ] not all owners/project-maintainers are on the coc@

there's currently no process how to get on or off those groups.

---

There's also no process how to get on or off the members group. Basically, we observe, or try to, or are pointed at someone who needs to be added

we haven't had an issue yet, where we needed to boot someone.

Most people remove themselves by the means of not participating ;)

---

Finally, there's currently no clear process of how to add a new module. Please note that there's also no process for how to give it away again, either. n.b.: I'm also not quite sure if the latter is necessary.

The former, definitely is if we want to get under the software freedom conservancy's umbrella: they are used to having single projects, not the kind that just grows indefinitely and uncontrollably.

[roidelapluie]

why would we want to get under the software freedom conservancy's umbrella ?

[igalic]

@roidelapluie they can hold our copyright and other assets, such as domain names… they can take and manage donations, and other incomes or expenses for us.

and most importantly, they can get sued instead of us, individually.

[roidelapluie]

that would require a CLA :cry:

[danzilio]

@roidelapluie i don't think it would require a CLA... just based on a cursory glance at the other projects under the SFC, plenty of them are CLA-free...

[daenney]

It does indeed not require us to have a CLA at all. The requirements of CLAs stem from the license you've used and how much you need to prove that you "own" the code. For bigger projects like Apache it makes sense, they get a bajillion contributions (from companies with deep deep pockets too) and if anyone every comes their way with a lawsuit having everyone's signature on CLAs closes that avenue. CLAs become especially important when multiple licenses and copyright owners get involved or if you want to maintain a dual/more-licensing scheme. By having copyright assigned to your org through a CLA you fully own it, also giving you the right to relicense without further involvement of the original authors.

It also makes a lot of sense for companies so that in the future, if they get bought, they can prove to their buyers what code they own which drastically diminishes risk and makes you a more attractive candidate.

Having or not having a CLA is a decision we get to make based on the potential risk/problems that might arise, it is not a requirement but would be something that needs to be discussed with the SFC. Since they have plenty of projects that are CLA-free I see no reason why we couldn't argue for it either and continue to maintain our software under Apache 2.0, which already stifles a bunch of the risks CLAs try to address.

[igalic]

uhm… to be perfectly honest, i'd prefer to remain free as in hippie, and not being bought…

[daenney]

Well yeah. It was to point out in which cases a CLA is useful. Doesn't apply to us.

[igalic]

perhaps, that too, is an issue that needs discussion. ?

i, for one, am happy with this organisation and its doings to remain free as in hippie.

[daenney]

As far as I'm concerned I never intended for this to be incorporated in any way shape or form past a non-profit/foundation. The latter mostly only to be able to deal with things like putting assets under the control of an entity, not a person.

I'd be surprised if anyone wanted to go that route and I would say that this is not really in the spirit of the project. If people wanted to do this though our license would permit them to fork the repo's and go a different route. But that feels a bit like premature optimisations 😛.

[nibalizer]

Yes, lets not try to make a company :D. Free as in hippie.

[nibalizer]

I have created https://github.com/voxpupuli/plumbing/pull/45 to maybe get the ball rolling

[daenney]

Now that we have #45 in progress we need to discuss how to adopt this once it is finalised.

It seems to me that:

• Collaborators on the project should get to vote on the charter since everyone in the organisation will be bound by it
• We need a XX% (I'm going to say 70) turnout
• We need a XX% (I'm going to say 80) majority
• Polls are open for a week

The numbers I suggested are relatively high but we currently have 69 people in this org, most of which are pretty active. Paired with a week to decide on the issue I believe that's feasible and with high enough barriers to acceptance that we can honestly say that this is the direction the project members decided to take (and not go brexit style).

[danzilio]

🇬🇧🇬🇧🇬🇧🇬🇧🇬🇧🇬🇧

[nibalizer]

45 merged today.

[daenney]

So. With that done. I guess it's time for elections? I'll be on vacation next week to mid-September so I won't be able to organise anything before then.