Define RFC process

[tingerrr]

We should define the RFC process and write it down in a document alongside the README.md.

This document should outline:

• what an RFC should contain,
• for which reasons it may be accepted or rejected,
• how collaboration on an RFC should happen,
• how long RFC PRs should be open before being accepted (final comment period).

All of these are defined in rust-lang/rfcs, which serves as the primary inspiration for this repo.

Some thoughts from me personally:
@Myriad-Dreamin already suggested that we could author the RFCs in Typst itself. I initially went with Markdown, because this has the benefit of being readable in rendered form directly on GitHub. However, as Myriad suggested, we could use the WebApp to collaborate on and render the actual RFC. One downside is that this makes collaboration less privacy tolerant. People need to be invited with write permissions somehow, which either requires a link with write permissions (easy to share on accident) or account login emails. But this only applies to the WebApp.

I think we shouldn't adopt the full rust RFC process, it's quite complex as rust is a much larger project typst-community being relatively small and the RFCs being unofficial in themselves means we can keep it simple at first (shorter waiting periods, less strict requirements).

[Thumuss]

One downside is that this makes collaboration less privacy tolerant. People need to be invited with write permissions somehow, which either requires a link with write permissions (easy to share on accident) or account login emails. But this only applies to the WebApp.

One way to remediate that could be that every person who wants to create a RFC needs to fork / use a template (like the one written in markdown) and publish it directly on the WebApp (with readonly perms). If some people doesn't want to use the WebApp, they can just PR a typst file and locally edited it. On the other hand, it's not that easy to manage when you want to edit multiple RFCs (reviews in general) nor creating one directly from github (like you said).

An other way could be using typst.ts and create a part of typst.community dedicated to RFCs.

[tingerrr]

I believe we discussed this further on the discord already so I'll try to outline the conclusions here; It's probably mostly fine to view a simple RFC in plain text as it's fairly similar to Markdown. Rendering the document can be done automatically in CI when it's finished or manually in between, as long as it is a document with no external dependencies other than universe packages.

Creating a dedicated editor page may pose the same privacy issues as on typst.app, for now viewing them plain is probably fine.

[Myriad-Dreamin]

I think we have already made much progress on deciding how to process rfcs. I suggest we start a few rfcs soon and figure out the best settings for typst during practice.

[tingerrr]

We can start RFCs now, accepting them just can't be done until we have a team that was actually elected by the community, for which we have started the pre-nominaitons and I think we can move on to the nomination soon.