UIP 0137 merge window notice

README.md

@@ -55,6 +55,7 @@ UIPs can be divided into the following categories:
 | [0134](./UIPS/UIP-0134.md) | Subsecond Timing Syntax   | ~lagrev-nocfep                 | Approved  | Standards |
 | [0135](./UIPS/UIP-0135.md) | Adjust @da format         | ~palfun-foslup                 | Approved  | Standards |
 | [0136](./UIPS/UIP-0136.md) | Comet Attestation         | ~hanfel-dovned, ~tinnus-napbus, ~bonbud-macryg, ~tondes-sitrym | Review | Standards |
+| [0137](./UIPS/UIP-0137.md) | Merge Window Closing Notice Requirement | ~nisfeb | Draft | Process |
 
 ## Background
 

UIPS/UIP-0137.md

@@ -0,0 +1,68 @@
+---
+uip: "0137"
+title: Merge Window Closing Notice Requirement
+description: Requires minimum four weeks notice before any merge window closes, announced at Core Architecture meetings.
+author: ~nisfeb (@nisfeb)
+status: Draft
+type: Process
+created: 2026-04-08
+---
+
+## Abstract
+
+This UIP establishes a minimum notice requirement of four weeks before any merge window closes for an Urbit release. The notice MUST be given at a Core Architecture meeting of the Core Guild, which convenes monthly. This ensures that developers have adequate time to finalize and submit work targeting a given release.
+
+## Motivation
+
+Currently, there is no formal requirement for how much advance notice developers receive before a merge window closes. This can result in situations where contributors are caught off guard by a closing window, leading to rushed submissions, deferred work, or missed releases entirely. Since the Core Architecture meeting is the primary coordination point for core development and occurs on a monthly cadence, it is the natural venue for such announcements. A four-week minimum aligns with the monthly meeting schedule and gives developers at least one full meeting cycle to respond.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+1. Before any merge window is closed for a release, the Core Guild MUST provide a minimum of four (4) calendar weeks of notice to the developer community.
+
+2. The notice MUST be announced at a Core Architecture meeting. The meeting at which the announcement is made starts the four-week clock.
+
+3. The notice SHOULD include:
+   - The target date for the merge window closing.
+   - The release or kelvin version the window applies to.
+   - Any UIPs or work items expected to land in the release.
+
+4. The merge window MUST NOT close earlier than four weeks from the most recent announcement of its close date at a Core Architecture meeting.
+
+5. If the merge window is extended, the new close date SHOULD be announced at the next Core Architecture meeting.
+
+6. This process applies to all releases, including kelvin decrements, non-kelvin OTAs, and any other release that involves a merge window.
+
+7. The following categories of releases are EXEMPT from the four-week notice requirement:
+   - **Security fixes**: Releases that address CVEs, actively exploited vulnerabilities, or other security issues where delayed deployment would put the network or its users at risk.
+   - **Critical bug fixes**: Releases that fix bugs causing data loss, ship bricking, network partitions, or other severe operational failures.
+   - **Dependency uplifts for security**: Updates to third-party dependencies driven by upstream security advisories.
+
+8. When an exempt release is made without the standard four-week notice, the Core Guild MUST provide a retrospective explanation at the next Core Architecture meeting, including:
+   - The nature of the issue that triggered the exception.
+   - Why the standard notice period could not be observed.
+   - What was included in the release beyond the exempt fix, if anything.
+
+9. Exempt releases SHOULD be scoped narrowly to the issue justifying the exception. Non-critical changes SHOULD NOT be bundled into an exempt release to bypass the notice requirement.
+
+## Rationale
+
+Four weeks was chosen because it aligns with the monthly cadence of Core Architecture meetings. A shorter period (e.g., two weeks) would risk the announcement falling between meetings, meaning some developers might not hear about it through the primary coordination channel. A longer period (e.g., eight weeks) would slow down the release process unnecessarily.
+
+Requiring announcement at Core Architecture meetings rather than through informal channels (e.g., group chat) ensures there is a well-defined, auditable moment when notice is given. The meeting format also allows for immediate Q&A and coordination.
+
+Exceptions for security fixes, critical bugs, and security-driven dependency uplifts are necessary because rigid adherence to a four-week window in those cases would leave the network exposed to known threats. The retrospective requirement ensures these exceptions are not abused. The narrow-scoping provision (item 9) prevents unrelated changes from being bundled into an emergency release as a way to skip the notice period.
+
+## Backwards Compatibility
+
+This is a process change and does not affect any software interfaces. Existing release procedures would need to incorporate the notice requirement going forward. Any merge window that is already open at the time this UIP is adopted SHOULD be given a four-week notice from the next Core Architecture meeting before closing.
+
+## Security Considerations
+
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).