Remove staggered dev/burndown schedule from release docs

[AyodeAwe]

Since 25.12, all RAPIDS repos enter burndown simultaneously -- release branches are created for all repos at the same time. The docs still show a two-phase staggered schedule for development and burndown (cuDF group vs "others"), which has caused confusion -- most recently cucim PR #946 going to main instead of release/26.04 because the docs said cucim wasn't in burndown yet.

This PR collapses the dev and burndown phases into single entries while keeping code freeze staggered (cuDF group freezes before others).

[netlify]

✅ Deploy Preview for docs-rapids-ai ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	6eea8be
🔍 Latest deploy log	https://app.netlify.com/projects/docs-rapids-ai/deploys/69bc17d9a528f8000752f29f
😎 Deploy Preview	https://deploy-preview-758--docs-rapids-ai.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[AyodeAwe]

Netlify deploy preview verification:

Maintainers page (current/next schedule -- 5 rows: Dev, Burn Down, Code Freeze cuDF group, Code Freeze others, Release):

Schedule page (test entry with new hybrid format renders correctly alongside old 7-row staggered entries):

[AyodeAwe]

cc @gforsyth @caryr35 @msarahan @mmccarty -- this was discussed and agreed upon in the meeting on Mar 18.

[gforsyth]

Thanks for putting this together @AyodeAwe !

I think this is still a bit confusing, because for "others", there's no indication that their burndown period is longer.

Maybe we keep the burn down (others) row but change it from 5 to 12(?) days?

Also, just to check my self here, we only count working days in these counts, yeah?

[AyodeAwe]

@gforsyth the two code freeze rows are the indication -- cuDF group freezes first to give downstream libraries stability, while all repos enter burndown together. The "others" effectively have a longer burndown period because their code freeze starts later.

Re: day counts -- these are business days (weekdays only).

[gforsyth]

I think we need to be more explicit. As @jakirkham noted, burndown is a social convention, but there is the real technical hurdle of not including "future" tags on a release branch, so whether or not we call it "burndown", any PR that might go into the next release needs to be retargeted to the release branch at the beginning of the burndown period.

We can call it whatever, and devs can think about it however, but I think we need to be clear that there will be a longer period, pre-code freeze, for the non-core libraries where they can continue development, etc, but need to target their PRs accordingly.

I think something like this (where again we can shift language, etc)

Phase	Start	End	Duration
Development	Thu, Jan 15, 2026	Wed, Mar 11, 2026	38 days
Burn Down (core libraries)	Thu, Mar 12, 2026	Wed, Mar 18, 2026	5 days
Code Freeze/Testing (core libraries)	Thu, Mar 19, 2026	Tue, Apr 7, 2026	12 days
Burn Down (others)	Thu, Mar 12, 2026	Wed, Apr 1, 2026	17 days
Code Freeze/Testing (others)	Thu, Apr 2, 2026	Tue, Apr 7, 2026	4 days
Release	Wed Apr 8, 2026	Thu, Apr 9, 2026	2 days

[AyodeAwe]

Good point, being explicit about the longer burndown window for others is clearer. I'll update to match your proposed layout -- the key fix is that others burndown now correctly starts on the same day as core (when branches are created), rather than a week later as the old docs showed.

[AyodeAwe]

@gforsyth @jakirkham LGTY?

[gforsyth]

I think this should be either 12 or 14 days, depending on whether or not we include the "free days" in the count

[AyodeAwe]

Good catch @gforsyth. Updated.

Can be viewed here: https://deploy-preview-758--docs-rapids-ai.netlify.app/maintainers/

[gforsyth]

Ok, I think this is a good time to get the library PICs to sign off -- I can round up a list of reviewers