Skip to content
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

Determine maintainer policy #94

Closed
mattstratton opened this issue Apr 11, 2016 · 7 comments
Closed

Determine maintainer policy #94

mattstratton opened this issue Apr 11, 2016 · 7 comments
Labels
Milestone

Comments

@mattstratton
Copy link
Member

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
Copy link
Member Author

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
Copy link
Collaborator

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants