PR Merge Policy

[ryanflorence]

If you look at the git log, there isn't much community contribution to the actual code, docs and stuff, yeah, but not the code. I think it's because:

1. We don't have a clear roadmap (as discussed in Vision/Roadmap #3289)
2. We don't have a PR merge policy.

Right now it's basically "everybody wait for @mjackson to be okay with this." Except when I'm on a "we need to ship the next version now!" and just push straight to master.

I propose instead we just need two collaborators to +1 the change, if a collaborator is the one making the pull request, that counts as 1.

That also means any non-trivial change (API additions, changes, deprecations) needs to go through a PR.

[jquense]

👍 @mtscout6 set up a similar policy with react-bootstrap and its worked out great for us, its been a good combo of process to slow down potentially short sighted choices, while at the same time not too onerous that stuff stays stuck for a long time.

[mjackson]

I almost opened an issue like this yesterday. Sounds great. I'm +1
On Wed, Apr 13, 2016 at 11:38 AM Jason Quense [email protected]
wrote:

[image: 👍] @mtscout6 https://github.com/mtscout6 set up a similar
policy with react-bootstrap and its worked out great for us, its been a
good combo of process to slow down potentially short sighted choices, while
at the same time not too onerous that stuff stays stuck for a long time.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3294 (comment)

[mxstbr]

👍 we've been using it over at https://github.com/postcss/postcss.org and it's been working very well for us. Definitely recommended.

[mtscout6]

You may find this useful: https://lgtm.co/

[ryanflorence]

I thought we already had this policy.

[taion]

Would somebody care to start by reviewing #3295, #3296, and #3298? 😈