Add a formal policy about changes in this repo

[chicoxyzzy]

@zloirock @ljharb we should add a policy/guidelines to this project to have formal rules about what changes we accept, what is obsolete and very 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 the gh-pages so people can add PRs and any controversial changes could be discussed before merging.

[ljharb]

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.

[chicoxyzzy]

Yes, I agree with @ljharb.
If someone blocks PR for some reason, it shouldn't be merged before the person who blocks that PR will approve it.

[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.

[zloirock]

Ok, in this case I block this proposal.

[ljharb]

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:

• we proceed as we have for the past week or two, forever, with maintainers using git to attempt to enforce or bypass the majority opinion
• @zloirock, the lone dissenter, concedes and agrees with the majority
• @ljharb and @chicoxyzzy concede, and agree with the minority
• @kangax makes an executive decision and declares one position as the policy, and removes any maintainers who are unwilling to comply with that policy.

[kangax]

@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 the gh-pages so people can add PRs and any controversial changes could be discussed before merging.

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?

[zloirock]

@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.

[zloirock]

@kangax I agree with this point, but not about blocking PRs for sabotage of the project, like @ljharb doing.

[zloirock]

@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?

[ljharb]

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.

[zloirock]

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 -)

[ljharb]

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.

[zloirock]

About initial @chicoxyzzy topic:

• non-obsolete - 2 latest (excepting dead) engines releases + LTS + unstable. Why 2? A big part of users always still on the previous version and developers should think about it. At this moment, this rule works for almost all engines in the table.
• very obsolete - I don't know. I think it could be better to limit the number of obsolete versions of engines in the table, for example, to 5. But here should be exceptions, for example, to obsolete Node versions - here could be useful to show even Node 0.12 when enabled Show obsolete platforms flag.
• we can add a flag verified by human to the test results - I agree. But should it be shown in the table and how? I have no ideas.
• make gh-pages a protected branch and add a condition that PR should have at least one approve to be merged - agree.

[ljharb]

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)