Hi all, KIP numbers have quietly become shared vocabulary: people say "kip-848" (new rebalance) or "kip-932" (queues for kafka/Share Groups) or kip-1150 (Diskless/Inkless) in threads, talks, and PRs and everyone knows what's meant. [1]
But nothing canonical matches how we already refer to them, and the links we do paste are fragile: the readable Confluence URLs (.../display/KAFKA/KIP-500+Replace+ZooKeeper+...) tend to 404 the moment a title is edited, and the stable page-id URLs (.../pages/viewpage.action?pageId=66945394) are opaque and impossible to type from memory. So archives, PRs, and commit messages slowly fill with unreachable links. (I’ve personally faced this a couple of times already). I propose that we use a stable, memorable scheme that matches how people already talk: https://kafka.apache.org/kip/848 -> KIP-848 on Confluence https://kafka.apache.org/kip/500 -> KIP-500 Implementation is deliberately light. kafka-site on Hugo already has a custom redirect_to front-matter that emits a client-side redirect, so each KIP is one tiny Markdown file: content/<...>/kip/848.md --- title: "KIP-848" redirect_to: "https://cwiki.apache.org/confluence/x/KoxiBw"; --- The target is the Confluence TinyLink, which is derived from the page id and so survives title renames and page moves. Rollout: - One-time backfill: a script reads the KIP index and generates one file per existing KIP, submitted as a single PR for normal committer review. - New KIPs: add one file. we create the generator plus an optional daily job that opens a PR when new KIPs appear; a committer still reviews and merges. Out of scope for now: true server-side 301s. They'd be better for search engines/crawlers and can be added later via infra config without changing any of the above or breaking existing links. Also, no thoughts on moving away from confluence currently. Looking forward to hearing the PMC/Committers on this idea. Thanks, Aditya [1]: https://imgur.com/a/KUHA7lM#k5smzbb
