-
Notifications
You must be signed in to change notification settings - Fork 945
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
Add a formal policy about changes in this repo #1564
Comments
Before adding a protected branch setting, we need to agree that nobody can merge through a block, as is the standard on most projects with multiple collaborators. |
Yes, I agree with @ljharb. |
Note that includes #1556, which was merged through a block, and so those changes must not reland in any form until a new PR arrives that meets my approval. |
Ok, in this case I block this proposal. |
This isn't a PR, but sure, that's fine - that's how consensus works. Since the three of us can't agree, that leaves us in a state where either:
|
Frankly, I'm surprised that's not already the case. It's a standard practice in any repository with multiple contributors. Does the majority agree with this? |
@ljharb I will be happy to give up the burden of maintainer this project if you do it properly. However, you are only trying to impose your rules without any contributions to the project. |
@ljharb maybe instead of pretending to absolute right to block PRs with important fixes here and in many other repos, require other maintainers to perform useless tasks for tens of hours and at the same time refuse to do it yourself, since you have more important tasks, you should at first review PRs in your own projects, like here? |
Every maintainer in any project has the absolute right to block anything and require anything of a PR author, unless they have an explicit policy that differs (which is rare). Discussing specific PRs in other repos isn’t something i plan to do here. @kangax without a policy around maintainers blocking changes, a protected branch will add friction, so I’d prefer not to enable that until we have one. |
Seem the answer to the question of why you don't review / merge PRs like this is the answer why you block my work here -) |
I review and merge PRs all the time. That specific repo is for a stalled proposal, and I don't plan to make any changes to it of any kind until I'm ready to revisit the proposal. I'm not sure why you're so focused on rapid forward progress to the exclusion of all else, but that's not how things operate in most projects, and certainly not in this one. |
About initial @chicoxyzzy topic:
|
I agree with all those points, and for now i'm content to have the data differentiate between how it's verified while leaving the table still as green/red only (with the caveat on the last point, ofc, that before we enable protected branches we agree on blocking) |
@zloirock @ljharb we should add a policy/guidelines to this project to have formal rules about what changes we accept, what is
obsolete
andvery obsolete
and so on.As an option we can add a flag
verified by human
to the test results, so we'll be able to add changes proposed by @zloirock, but flag them as not verified. IMO such results should have an optional link which proves these changes or a description how results were collected.@kangax in the meantime, could you please make
gh-pages
a protected branch and add a condition that PR should have at least one approve to be merged? This will help to prevent rebases in thegh-pages
so people can add PRs and any controversial changes could be discussed before merging.The text was updated successfully, but these errors were encountered: