Idea: update rfc format

[xxchan]

The current proposal process and format is specified by https://github.com/beyondstorage/specs/blob/master/rfcs/17-proposal-process.md and https://github.com/beyondstorage/specs/blob/master/spec/2-proposal.md.

The metadata status and updated_at are required.

For status, the transition draft -> candidate -> finished is troublesome (have to start a PR to update status). In practice, this is not followed (There are 18 rfcs with status draft. Actually, we implemented a proposal immediately after an RFC.
As an alternative, we can link an issue to track the implementation status.

For updated_at, we often forgot to update this when a proposal was discussed for days. And I think maybe the date information is not important (or only give created_at?

---

ref: Rust RFC https://github.com/rust-lang/rfcs

metadata

- Feature Name: (fill me in with a unique ident, `my_awesome_feature`)
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

[Xuanwo]

Rust's RFC looks good to me, let's resolve this problem together with #99

[Xuanwo]

Some detailed ideas:

• Keep metadata in markdown front matter (so we can parse all our proposals to build a website like https://rfcbot.rs/ ?)
• Remove status (status will represent via related PR and issue)
• Migrate updated_at to start_from
• For process
  • Start issue at specs or forum for pre-proposal, we can reject impractical ideas early.
  • Implement demos while required by the reviewer.
  • Start real-time discussion rooms while needed.
  • All RFC requires at least 2 LGTMs and one of them should be a committer.

rfcbot

[Xuanwo]

For RFC PR and Issue, maybe we can refer to them in previous discussions?

[xxchan]

Since the RFC number is PR number, i think this is not necessary, but may help jump quickly to the page.

I think Rust Issue is not only discussion, but also tracks implementation status. So it is good and maybe we can have go-storage Issue? But the problem is that sometimes we directly start a GSP PR and a go-storage PR without any issues.

[bokket]

Rust RFClooks very simple and clear, for newcomers to the community, this approach may be easier to get started than GitHub projects ?

[Xuanwo]

But the problem is that sometimes we directly start a GSP PR and a go-storage PR without any issues.

For complex GSPs, we usually create an issue to track like: beyondstorage/go-storage#560

I think it's a good idea to create an issue to track the implementations.

[Xuanwo]

For now, our idea/proposal issue is separated from the implementation status tracking ones. Is it a good idea to merge them into one?

[bokket]

For now, our idea/proposal issue is separated from the implementation status tracking ones. Is it a good idea to merge them into one?

I prefer to merge together.

[xxchan]

I think before a proposal, there may or may not be some problem issues we want to solve.

So there are:

• problem issue: problems we may want to solve in the go-storage repo, may be linked in the proposal background
• idea issue: pre-proposal in the specs repo
• tracking issue: tracking proposal implementation status in the go-storage repo

Idea issue is optional and can be closed when a proposal PR is opened (or closed by the proposal PR?).

Tracking issue is required, linked in the proposal, and can close problem issues.

[xxchan]

Since they are in different repos, they can't be merged.

Or do you think putting tracking issue in specs repo is ok? Then we can turn an idea issue into a tracking issue.

[Xuanwo]

Or do you think putting tracking issue in specs repo is ok? Then we can turn an idea issue into a tracking issue.

LGTM.

It makes sense to have an issue to track the whole process from an idea to the proposal and finally, the implementations.

[xxchan]

I think one possible reason for separating the tracking issue is that we may already have some discussion in the idea issue and proposal PR, so a separate one may be cleaner?

Anyway, I'm OK with either style.

[Xuanwo]

I have a problem: If we separate the tracking issue from the idea issue, what's the timing to create the tracking issue?

• every time a proposal started: Not a good idea, not all proposals will be accepted.
• just before a proposal gets merged: Need extra work to update the proposal to add a link.

---

Rust's RFC uses the second way: rust-lang/rfcs@644025d , see also rust-lang/rfcs#2603 (comment)

The maintainer will update the proposal's link just before merged, and the author just needs to keep them empty.

[Xuanwo]

ping @xxchan, can you start a new GSP to update the RFC format and SPEC-2?