The PR for SE-0489 has been ready to merge for a bit now, and I’m wondering if someone could please help make sure it gets merged before it slips out of date and needs to be rebased again?
I’ve force-pushed to the branch 40 times over its 7-month history. While much of that was responding to PR feedback, most of the recent pushes were just keeping up with other changes that were landing upstream and introducing trivial conflicts.
A few thoughts…
First of all merge conflicts are kind of an unavoidable pain point of working on very large projects with many engineers. While I completely sympathize and empathize with the churn this puts on your calendar… it can be difficult to then present that churn to library maintainers as an incentive to help review and ship these changes. Every engineer has this churn on their diffs… so why prioritize this diff to eliminate the churn for you?
But… you're not just some random engineer attempting to ship on swift. You are the author of an evolution proposal! The LSG — acting on behalf of the project lead — selected your proposal to ship in the standard library. That's great! If we know the project lead wants this code to ship… that alone should be some very strong incentive for engineers working at the project lead to prioritize reviewing and approving the changes.
Something I've noticed going through the evolution process as an "outsider" — that does not work at the project lead — is that there might be places where an engineering culture that optimizes for the DevX of an open source community might not always be optimizing for the DevX of a private corporation with a traditional and historical culture of secrecy.
Engineering cultures can skew in very different directions. Walking into an engineering culture without very good context how that engineering culture operates can lead to wasted time. Walking into an engineering culture that could be carrying over artifacts from a private company that prioritizes secrecy and attempting to "reverse engineer" that culture from the outside as an open source contributor can be very challenging without some kind of documentation or roadmap.
Some cultures expect IC engineers to be strong advocates and evangelists of their own changes. An IC engineer that waited too long without acting as their own advocate and evangelist might be seen as not serious about — or not committed to — standing behind their changes. A very different engineering culture might expect IC engineers to wait for explicit "top down" sponsorship. An IC engineer that prioritizes advocating and evangelizing for their own changes might be seen as too "pushy" or "aggressive" and not respectful of the norms and unwritten laws.
For some more practical examples here… suppose I am working on a large codebase and want some engineers to prioritize reviewing my diffs. What are some options I might have available?
Because the project lead is a private corporation… engineers coming from the outside do not always have visibility for what the internal culture looks for when prioritizing work. Should you be posting in an internal slack channel? Great… you don't have access to that. Should you be opening a rdar issue? Great… you don't have access to that.
The conjecture that I made earlier is that the LSG accepted your proposal and the project lead at that point explicitly incentivized library maintainers to review and approve your diffs. If the project lead at that point only implicitly incentivized library maintainers to review and approve your diffs and it is your responsibility then to make that incentive explicit under the culture and constraints of the project lead… you are kind of stuck in a Catch-22. You need internal access and visibility to create the incentive to review your changes… but you can't have internal access and visibility.
Sorry—bad timing, merging is locked going into the U.S. Thanksgiving holidays. That does also mean that merge conflicts are less likely too, though 
Merged!
Great! I look forward to removing my copy-pasted version from my codebases.