Better organisation of reviews

[jawbroken]

Sure, it's possible, but that's life. I don't think it's reasonable or healthy for anyone to think “I have to participate in every review or they might make a major mistake or wrong decision without me”. We all know that participating in a review is no guarantee that you'll get the outcome you want, anyway.

[Karl]

@jawbroken

I don't think it's reasonable or healthy for anyone to think “I have to participate in every review or they might make a major mistake or wrong decision without me”. We all know that participating in a review is no guarantee that you'll get the outcome you want, anyway.

I think you might have misunderstood - I'm certainly not saying that and don't think that.

We have an evolution process so that developers who use Swift can help shape its future. Those who choose to participate do so because they are motivated to create a better language through collaboration and sharing ideas/experiences. If time limits are preventing them from fully participating or causing undue stress, I don't see the harm in asking whether those limits can be relaxed a bit.

Anyway, I think I've made the point I wanted to make. At least some members of the core team have seen it, so hopefully they'll factor it in when scheduling future reviews. Pre-scheduling is a welcome step: I learned that the concurrency reviews are coming a lot sooner than I expected. That helps me plan my time a bit better, and I appreciate that.

[jawbroken]

I wasn't talking about you there, just replying to @wowbagger's post which implied that individual pressure.

[Chris_Lattner3 (Chris Lattner)]

@Jumhyn

Based on @Chris_Lattner3's post above, I'm struck by the implication that scheduling of individual proposals seems to be entirely delegated to each RM as they see fit (please correct me if I've misunderstood). Perhaps it would be better for review scheduling to be taken up more as a collective effort.

Just to clarify, I proposed this timeline when we discussed it at the most recent core team meeting and others found it agreeable, so there was collective action there.

One of the reasons that a bunch of proposals got scheduled all at once is that it was correctly observed that we had a backlog and had to get on it.

I can understand Karl's concern, but there is a balance that needs to be struck here - we have to be aware of the time limitations on the side of the proposal authors and release managers as well. While we should continue to improve things, I don't think we'll ever achieve perfection. I don't think a rigid process is going to be better in practice.

-Chris

[Jumhyn (Frederick Kellison-Linn)]

Thank you for clarifying on that point, Chris!

[Douglas_Gregor]

@Douglas_Gregor

• Schedule "Structured Concurrency" for January 5...19.
• Schedule" Async Sequences" for January 5...19.

Well, those were optimistic ;)

We just scheduled Async Sequences as SE-0298 for January 12...26. Structured Concurrency has not yet converged to the point where it is ready to schedule a review (nor have actors).

Doug