Make definition of substantive changes more specific

[justinwb]

This pull request is aimed to solve the points raised by @RubenVerborgh in #57, where the language in the current process that determines whether something is a substantive change, and how to proceed if it is (or not), needed further clarity.

[Mitzi-Laszlo]

Re: Candidate Proposals without substantive changes require one editor to actively approve the proposal with no editors actively rejecting. Editors may abstain. Candidate Proposals without substantive changes must remain open for at least twenty-four hours before final acceptance. If an editor does not vote by the end of that twenty-four hour period it will be assumed that the editor abstained.

• The open time needs to be a little longer to give an editor the chance to agree that it is not substantive. It is quite possible that an editor may not check GitHub for 24 hours. Perhaps a week is more reasonable?

Once a Candidate Proposal has successfully passed editorial review and the specified wait-time has elapsed, it may be merged by an editor, or by one of its authors if they have appropriate permission to do so.

• Isn't it the role of admins to merge the result of editors? Perhaps best to maintain consistency in the division of voting and executing?

[justinwb]

• The open time needs to be a little longer to give an editor the chance to agree that it is not substantive. It is quite possible that an editor may not check GitHub for 24 hours. Perhaps a week is more reasonable?

Perhaps one day is too fast of a turnaround, but I think one week for a non-substantive change (for example, to fix a typo), is too long. That's the same amount of review time we ask for a substantive change. I don't think they should be equivalent. Maybe two days is more appropriate?

• Isn't it the role of admins to merge the result of editors? Perhaps best to maintain consistency in the division of voting and executing?

If something has already passed editorial review I don't think there's a real reason to mandate that only Administrators can merge it. Adding people into the mix that aren't directly involved in the editorial review process adds another step, and I'm not sure what value that brings. If someone is an approved editor, or has authored something good enough to pass editorial review, they should be allowed to merge it on their own if they have appropriate permissions already to do so.

[TallTed]

It's important to remember that part of the point of git (and similar) is to allow reversion of changes -- so if something is merged (by an editor or whomever) as non-substantive and subsequently determined (by the director or whomever) to be substantive, that merge can be reverted (usually easily if not trivially; occasionally with some difficulty, if subsequent changes were based on it).

[RubenVerborgh]

Agree in general, smaller suggestions added.

[RubenVerborgh]

👍 That's the kind of trust we need in people. We should trust that editors can decide themselves what is substantive and what is not.

[kjetilk]

To elaborate on @TallTed 's point of reverts, it enables us to live with relatively short time periods for non-substantiative changes. I think 24h is the longest acceptable, but that any editor could open a proposal to revert.

Any editor may also call for a revert on something that was deemed a non-substantiative change to upgrade it to a substantiative change.

[justinwb]

Any editor may also call for a revert on something that was deemed a non-substantiative change to upgrade it to a substantiative change.

Great points. I'm happy removing the time period altogether and adding in some language about the ability for editors to revert non-substantive changes. Anyone have a fundamental disagreement with that?

[justinwb]

This pull request has been succeeded by #95. This branch and its associated version history was merged into that branch and then modified further. Closing this pull request.