Determine maintainer policy

[mattstratton]

We need to decide what the policy is for major changes to the devopsdays.org site (things related to design, etc).

Perhaps a very light RFC type system that requires 👍 from a certain number of core folks? Discuss.

[mattstratton]

One thing to consider (although we could make it lighter) is an RFC process similar to this
https://github.com/chef/chef-rfc/blob/master/rfc000-rfc-process.md

[phrawzty]

It may be worth nothing that the "core folks" aren't exactly a known quantity (de facto is good but not great, especially when there's a problem); group membership and criteria would probably have to be hammered out, too. In other words, this is a can of worms, but that doesn't mean it shouldn't be opened - just have to do it with care.

[mattstratton]

Perhaps if we were to assign a committee/group (not necessarily core folks, but of course they could be) and we name them, they are the ones in charge of approve/disapprove these types of changes?

We could make it fairly lightweight and assume that anyone who has commit bits on this repo should follow the process decided (best judgement on whether something is a new feature or not) and request two 👍 from people on the "website" committee?

[mattstratton]

The rust community uses a similar process:

https://github.com/rust-lang/rfcs

Adding a requirement for CLA's for actual code changes? https://cla-assistant.io/ is good to make this nice and easy.

[bridgetkromhout]

I don't think we need CLAs.

The "core" team has very varied levels of involvement, but I don't think we should form new governing bodies of any sort when we have a core team. For big front-page changes in the past I've mailed core and waited a few days to see if anyone had strong opinions, and waited for a 👍 instead of just merging my own PR.

Today, I'll mail core and see what people think about the tweet stream.

[kmugrage]

The CLAs might be a good idea if they are lightweight. It took us almost a year to move selenium to a consortium because we had to track down every person who had contributed. Of course I have no idea what legal entity would be assigned the rights.

[bridgetkromhout]

This is a devopsdays governance question far outside the scope of the website migration or code. I'm closing this particular github issue, but I talked to @jedi4ever in Budapest and we're in agreement that we'll keep iterating on the org structure.