Clarify objection period for lazy consensus in SKIP 1#7020
Clarify objection period for lazy consensus in SKIP 1#7020stefanv merged 13 commits intoscikit-image:mainfrom
Conversation
|
@lagru, thank you for working on this! I fully support the idea of making the decision process less fuzzy and more dynamic. However, 1-2 days feels a bit too short of a response period to any change, and 7 days - as a period to reflect on a considerable code-related PR and to prepare a critical review (should be sufficient for docs-related PRs, though). I can easily imagine a situation where a core developer does not have any spare time to read through GitHub notifications and respond over the course of 1-2 days due to competing activities. In my opinion, 3 and 10(/14) days, respectively, would be less biased estimates for |
Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
10aa090 to
e036dec
Compare
I totally get this. However, there's also a trade-off to increasing the objection period. The longer we wait, the easier the pending decision is forgotten again. At worst, a PR that is ready to merge becomes stale again and is re-discovered a few months later when everyone has forgotten the context. I really really want to avoid this case. Does it alleviate your concerns somewhat, that we can always revert a merged PR very quickly, if there are any concerns discovered after the fact? I just pushed fe12d04, so that there is an even longer grace period for serious changes that require a SKIP. Though, I get your case. It feels like a trade-off for which the right balance is probably entirely subjective. Right now, I would love to know the response time distribution between
to make a more informed decision here. 🧞 Maybe I should wip up a quick notebook. 🤔 😄 |
@lagru that would likely work well for small doc-related PRs. For functionality changes, I am personally sceptic about reverting PRs, since that may lead to nasty issues due to competing code changes being merged in-between.
What do you think about using an automatic scheduler for merging the approved PRs (e.g. https://github.com/marketplace/pr-scheduler, https://github.com/marketplace/actions/merge-schedule)? That could be a nice step forward in translation of the development policies from text to CI. |
Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
Regular API changes don't require a SKIP and fall within the second bullet point / case.
b3da944 to
89ad799
Compare
soupault
left a comment
There was a problem hiding this comment.
After discussing the PR with @lagru in person, the latest version looks good to me.
To summarize the spirit of this proposal:
- In
Minor documentation changes: the idea is to have a cooldown period to reduce the probability of bugs being brought with hasty merges. - In
Code and major documentation changes, and changes to the API: the main motivation is to have explicitly stated how to account for an opinion of a previously disagreeing core member(s) who turned inactive in the conversation. Here, such member(s) are expected to voice their concerns (or, at least, a presence of thereof) during the period, otherwise, their concerns are considered resolved (given approval by 2 other core members).
Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
as suggested by Marianne. Co-authored-by: Marianne Corvellec <marianne.corvellec@ens-lyon.org>
|
Should we give this a month-long objection period, since the change affects a SKIP? There would be 3 weeks left, since we had 2 approvals 7 days ago. Counting down... |
|
Can we get this sorted during the next community call @lagru? |
|
I think the next call is when we are in Seattle? Happy to discuss it. Though, it seems like we settled on a consensus mostly, so IMO we can just merge this if you can live with the clarifications as well @stefanv. I guess in practice it will only be relevant as a good reference to fall back on if decisions seem important or controversial. |
Co-authored-by: Stefan van der Walt <sjvdwalt@gmail.com>
Description
@scikit-image/core, I'd like to clarify our expectations around how long of an objection period we expect before a lazy consensus is assumed. The suggestion is based on what I feel is already established practice.
I don't think this omission or vagueness has been a big problem in the past, but clarifying and documenting it seems like a good thing. I remember that last year when I started working for EOSS and started more actively proposing decisions myself, this would have given me a bit more confidence. :)
Checklist
./doc/examplesfor new features