Skip to content
This repository has been archived by the owner on Nov 21, 2018. It is now read-only.

Closing / Fixing policy #76

Closed
therebelrobot opened this issue Jan 16, 2015 · 16 comments
Closed

Closing / Fixing policy #76

therebelrobot opened this issue Jan 16, 2015 · 16 comments

Comments

@therebelrobot
Copy link
Contributor

We need a policy for closing/fixing PRs that have merge conflicts. see #24-comment-70226567. @snostorm suggested we close after some sort of X day policy. First maybe tag the author to try and rebase/conflict resolve before closing?

@therebelrobot
Copy link
Contributor Author

@snostorm et al.: should we delete branches after merge, or leave that to the PR submitter?

@snostorm
Copy link
Contributor

Meh. I sometimes do occasional cleanup of stale branches off repos while drinking my morning coffee. Zero preference on the timing. (Part of me likes the idea of a few hour buffer for some odd reason.)

@therebelrobot
Copy link
Contributor Author

I also think we should have a 2 or more 👍 from WG on a PR before merging. or 2 or more 👎 before closing without merge.

@mikeal
Copy link
Contributor

mikeal commented Jan 19, 2015

2 seems reasonable.

@therebelrobot
Copy link
Contributor Author

Also, what about someone who wants to "dibs" a merge for one reason or another? Should we allow for that, and check who the assignee is before merging, or should we do first-come-first-serve?

@therebelrobot
Copy link
Contributor Author

Bump

@Fishrock123
Copy link
Contributor

I also think we should have a 2 or more 👍 from WG on a PR before merging.

Even core only requires a single reviewer.

@mikeal
Copy link
Contributor

mikeal commented Jan 23, 2015

Core only requires a single reviewer but that assumes they are the expert in that particular area and it specifies that they let the PR sit for more than a day to give people a chance to weigh in. We're merging much faster so it might be worth it to change the policy to require 2 or more +1 but remove the requirement on letting PR's sit for so long.

@therebelrobot
Copy link
Contributor Author

+1 @mikeal

@mikeal
Copy link
Contributor

mikeal commented Jan 23, 2015

Someone should write up whatever we agree to and stick it in the CONTRIBUTING file ;)

@bnb
Copy link

bnb commented Feb 17, 2015

It seems the x day policy is still undefined. (First WG meeting minutes, search #76, third WG meeting minutes, search #76.) Are we going to leave this undefined for now, add it to the next WG-meeting agenda, or pick a time frame? @indexzero suggested 72 hours here.

@therebelrobot
Copy link
Contributor Author

I say we pick a timeframe and stick with it. +1 to 72 hours with no activity.

@bnb
Copy link

bnb commented Feb 18, 2015

Would this apply in all PRs that is commented on with a question or request, or just ones that have merge conflicts?

@therebelrobot
Copy link
Contributor Author

@bnb, I would say those with merge conflicts or have a single downvote. For regular PRs, as @mikeal said above, we should remove the need for it to sit for so long.

@bnb
Copy link

bnb commented Feb 22, 2015

Sent in PR #232.

@fhemberger
Copy link
Contributor

Further discussion taking place in #232, I will close this issue for now.

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

No branches or pull requests

6 participants