repo: Add RFC process document #3
Conversation
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
2 times, most recently
from
41833e2 to
a039f98
Compare
This process is adapted from the Rust RFC process on rust-lang/rfcs and is intentionally less formal than that of Rust as the Typst community is still much smaller and the RFCs are less official than those of Rust. The formality may change in the future and the repository may be incorporated into the typst organization itself. But until then, this process can stay simple and somewhat informal.
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
from
a039f98 to
241a125
Compare
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
2 times, most recently
from
ac676f1 to
d740c50
Compare
|
I've put this up for review, but I'd like to discuss the current state of the ecosystem team on the forge before this is merged to ensure we have a representative portion of the community for the final vote of the RFC (as the process stands for now at least). |
|
We've started pre-nominations for the ecosystem team, see https://github.com/orgs/typst-community/discussions/19 for more information on how the new ecosystem team will be chosen. Once this process is completed, the new ecosystem will vote on this process as its first decision, paving the way for RFCs to be accepted, rejected or postponed. |
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
2 times, most recently
from
8a414db to
e22ba98
Compare
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
from
e22ba98 to
0af7925
Compare
|
Looking at RFC #6, I think it would be useful to also add a "rendered" link to each PR. Random example from Rust: rust-lang/rfcs#3786 has a link "Rendered" pointing at the author's fork and the Markdown file for more convenient reading. Further suggestion: recommend that RCF PRs start with "RFC: " or a related prefix, e.g. "Draft RFC: " (as an example; that can actually be implied by marking the PR as a draft too) |
We may add a GitHub action to help suggest that: https://github.com/Myriad-Dreamin/tinymist/blob/8be6a12256a18d8c3d170e6cf104ba6e3ef04e9a/.github/workflows/lint-pr-title.yml
|
Yeah, that sounds like a good, I'll add this to the process document.
Perhaps, though I personally tend to write the where, not the what in such a prefix. (I write |
tingerrr
force-pushed
the
tinger/rztqymutxyps
branch
from
0af7925 to
086763e
Compare
|
I've updated the process document and added a PR template people can fill out with the link after the PR is created. |
|
I've requested review from the ecosystem team to get this over the finish line, one question remains unanswered: should be use Typst for the RFCs considering that it won't be rendered on a GitHub PR? I personally think we should, and we can add infrastructure to render an RFC whenever necessary. If we keep the template for it simple, then we probably won't need the rendered version until it is merged anyway. |
|
I agree. Simple Typst source is easy to read and review. For larger, more complex RFCs, a compiled PDF or HTML version can be attached to facilitate reading. Using Typst instead of Markup may even turn out to be very useful for demonstration purposes within the RFC. Aside from that, it just feels more than appropriate considering the subject. |
|
|
Couldn't the PDF file just be uploaded to the PR (in the comment I mean)? There should be no problem regarding size then. |
@Mc-Zen certainly the authors could upload PDF, but I think it kind of unconvenient to keep updating PDF. |
|
@tingerrr @Mc-Zen I notice that in #6 tinggerrr comments on the typst source file directly. Then I think it is not such bad to only submit a typst source file. But I also noticed that, like gistd, the source file may not longer get compiled as we upgrade typst (to v0.14, v0.15, ...). The authors may include some information in the source file to tell readers which typst version is used. Alternatively, we may still require a rendered markdown file for future readers. |
|
Especially the last comment is a fair point, either we stick with Markdown (I don't think we should require both, either one or the other) or we ensure old RFCs still render with CI and migrations by targeting a specific version. |
That's a concern I didn't have on my radar when I first read through the discussion, but I think that's actually very important.
If we (initially) plan to not render the RFCs if they're in Typst, I think the benefit compared to markdown is small. It sounds nice in theory, but I think tooling within Github is the overriding concern here. Even once an RFC is accepted, people will want to read through it, and as opposed to the people actively working of the RFC, these readers would legitimately want to read the rendered document. So I also think that Markdown is probably the better option here—disappointingly, but still. |
|
I think we can initially use Markdown and keep it simple. Later we can think about adding infrastructure with a pinned Typst version and automated rendering and port them to Typst. |
|
I would like to bring this over the finish line. The fixup commits will be squashed down before the merge, but I'll leave them up for now to not impede review. I'll prepare a vote of the ecosystem team in the community channel later today. Feel free to leave any concerns on here regardless of the vote. |
See commit description.
Please make sure to read the source code directly, as some parts of the original text have not yet been altered, these usually have comments which aren't visible in the rendered version.
Two parts in particular stand out:
The Rust process requires consensus by all members of a subteam, since we may not have subteams (see community forge discussion) this would have to be revised.After the review I've changed this to be a sizable majority of the ecosystem team for now.
RFCs need some kind of advertisement when they go into FCP, Rust for example uses the "This Week in Rust" newsletter. See the comment for ideas.I went with the forum as an example here, this need not be just that, it merely serves as an example.
I've also left out the explanation about postponing and informality because they didn't seem to add much and the doc is already long enough. I think we can still simplify a lot of the wording here to make it more approachable.