Template#4
Conversation
|
this seems pretty long 😅, I'm working on rendering the RFCs in the docs website, depending on frontmatter support or other formats I would love to use something like that |
|
Not sure how the length of the RFC would affect how we render things? |
|
that comment has two points:
|
|
take a look at #6, that's roughly how proposals should be formatted |
|
actually lets merge #7 first |
|
@AdamGS I'm not sure how the formatting of the current template is special? It looks like normal markdown to me (other than the header). Also, I would far prefer a lengthy template to a short one because it gives the writer an idea of how to structure it. We don't necessarily have to require everyone to follow the exact template but it should be a good starting point. Or AFAICT none of the things that we probably want RFCs on would be sufficiently described with anything less than this... |
|
yeah I was (and now @a10y) figuring out formatting, nothing is special. I don't really feel strongly about this template, lets ship it |
|
how does the CI work here? Seems like the build is getting blocked. I'll also update the header |
connortsui20
force-pushed
the
ct/template
branch
from
1222fb3 to
d0ece9c
Compare
|
oh I guess I don't need to make a specific header anymore? Also when I run |
|
It pulls the author from git history. The user who committed the file is marked as the author. |
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
connortsui20
force-pushed
the
ct/template
branch
from
d0ece9c to
d4cb849
Compare
…im parity, framing Fixes a BLOCKER, two MAJORs, and 9 MINOR/NIT items identified in the second review of the RFC. BLOCKER: - amitport/EDEN-Distributed-Mean-Estimation is unlicensed (no LICENSE file). Removed the false "(MIT; PyTorch and TensorFlow)" annotation in §6 and added an explicit "no LICENSE — reference reading only, clean-room re-implementation required" note. Same note now also in Appendix D.4 for implementer-facing visibility. MAJORs: - §2 Motivation: replaced "The original RFC modelled TurboQuant as a new physical encoding..." with framing that doesn't reference the abandoned RFC 33 draft. - §6 TurboQuantConfig Rust snippet: aligned with the actual code at ff120401 — private fields, seed: u64 (not Option<u64>), explicit try_new constructor and getters. Noted that a Default impl may come in Stage 1 stabilization. - Appendix D.11 performance budgets: replaced fabricated round numbers with an explicit "TBD pending Stage 1 stabilization benchmarking" plan; only the compression-ratio budgets (which are exact from the wire format) remain pinned, plus the MSE bound from Theorem 1 with the SORF approximation slack. MINOR/NIT: - [1] arXiv version pinned to v1 in the reference entry (consistent with [4] and [12]). - Appendix D.2: reframed prost schema as "current schema (tags 1–5)" + "this RFC proposes (tag 6 for Stage 2, tag 7 reserved)" instead of the misleading "Reproduced from..." that added unsourced fields. - Appendix D.4: reordered the overflow check (validate `d <= MAX_DIMENSION` before calling `next_power_of_two`, which would otherwise overflow first). - Resolved Open Question #4 (wire-format identity at d=1024): Stage 2 writers leave `block_size` unset for k=1 so the artifact is bit-identical to a Stage 1 file. Documented the resolution in §13 and in the "Resolved during initial drafting" list. - §5 architecture diagram: fixed the cosmetic alignment on the box right borders. - §3.2 added a clarifying sentence that TQDecode is a regular scalar function (not a privileged canonicalization mechanism). - Appendix D.3: tightened error-message text to match the actual vortex_ensure! placeholder format ({dimensions}, {bit_width}, etc., not "got 0" / "got N" constants). Signed-off-by: Will Manning <will@willmanning.io> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Will Manning <will@willmanning.io>
3 participants
This is loosely based off of the Rust project's RFCs template, which you can find here: https://github.com/rust-lang/rfcs/blob/master/0000-template.md