All of the authors of "Unwrap or Die" were surprised when the proposal was suddenly posted for review.
Please change your policies such that you will notify proposal authors before beginning reviews. It's possible authors may want to make last-minute clarifications or changes. This is especially true for proposals that were posted, and then languished because discussion ended. Unwrap-or-die has been under discussion for almost two years or so, and we were all caught extremely off-guard when it came up for review.
Thanks. One approach might be to post a “review will begin next week and cover these proposals...” topic and then @mention the various authors for each proposal. The post wouldn’t need commentary, so locking it would prevent “but what about ...” replies.
In addition to this specific issue, any sort of transparency into the review selection process would be appreciated. How does the core team select proposals that will be reviewed? How do they determine the length and timeframe of the review? Is there any communication with proposal authors indicating a proposal is more or less likely to be accepted for review? The time before reviews are actually triggered is extremely opaque to me, at least into the core team at that point.
The Swift Evolution dashboard at Swift Evolution can handle "Scheduled for Review". Merging the PRs early and scheduling the reviews in advance will make sure they show up there.
I'm going to do a holistic review of how the transparency of the review process can be improved, and the critical aspects of communication.
FWIW, review lengths are roughly determined by a guess (based on past experience) of how much discussion is anticipated. However, we have had many cases where review discussion has extended beyond the original review period because more discussion was needed. The Core Team has not historically "cut off" reviews when discussion was still active and producing new perspectives, and in some cases reviews have been extended or sent back for additional review phases based on incorporating the feedback from review discussion. However, even this bit can be more transparent.
Communication with proposal authors has potentially not been as consistent as it could be. This is something I want to review with both proposal authors and members of the Core Team. While I think the Core Team has often given feedback to proposal authors on the shape of their proposal and what aspects are likely to get more traction (as well as hints such as the "Core Team: Needs Implementation" labels on GitHub PRs for proposal to indicate that a proposal will be run if their is an implementation) much of this remains a bit informal and isn't clearly documented.
Sometimes when I have initiated reviews I have contacted review authors asking them if they are ready to have the review kicked off. I myself am guilty of not being consistent here, and it is definitely something we (the Core Team) should be consistently mindful of when initiating reviews. Proposal authors need to be prepared — and available — during a review period, so naturally scheduling of a review should involve the proposal authors being in the loop.
As I said in another post on this thread, I think it is worth the Core Team doing a holistic review of the transparency and communication in the scheduling of reviews and the review process. I suspect that there are some very simple things we could do that would go a long way to addressing some of the underlying concerns being voiced on this thread.
neat. Can we get an RSS feed for that or something, so we can have interrupt-driven notifications and not poll-driven ones, then? 