Repository navigation
Idea: update rfc format #110
Description
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)
Activity
Xuanwo commentedon Jun 17, 2021
Rust's RFC looks good to me, let's resolve this problem together with #99
Xuanwo commentedon Jun 18, 2021
Some detailed ideas:
status(status will represent via related PR and issue)updated_attostart_fromspecsor forum for pre-proposal, we can reject impractical ideas early.committer.Xuanwo commentedon Jun 18, 2021
For
RFC PRandIssue, maybe we can refer to them inprevious discussions?xxchan commentedon Jun 18, 2021
Since the RFC number is PR number, i think this is not necessary, but may help jump quickly to the page.
I think
Rust Issueis not only discussion, but also tracks implementation status. So it is good and maybe we can havego-storage Issue? But the problem is that sometimes we directly start a GSP PR and a go-storage PR without any issues.bokket commentedon Jun 18, 2021
Rust RFClooks very simple and clear, for newcomers to the community, this approach may be easier to get started thanGitHub projects?Xuanwo commentedon Jun 18, 2021
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 commentedon Jun 18, 2021
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 commentedon Jun 18, 2021
I prefer to merge together.
xxchan commentedon Jun 18, 2021
I think before a proposal, there may or may not be some problem issues we want to solve.
So there are:
go-storagerepo, may be linked in the proposal backgroundspecsrepogo-storagerepoIdea 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 commentedon Jun 18, 2021
Since they are in different repos, they can't be merged.
Or do you think putting tracking issue in
specsrepo is ok? Then we can turn an idea issue into a tracking issue.Xuanwo commentedon Jun 18, 2021
LGTM.
It makes sense to have an issue to track the whole process from an idea to the proposal and finally, the implementations.
xxchan commentedon Jun 18, 2021
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 commentedon Jun 18, 2021
I have a problem: If we separate the tracking issue from the idea issue, what's the timing to create the tracking issue?
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 commentedon Jun 21, 2021
ping @xxchan, can you start a new GSP to update the RFC format and SPEC-2?
xxchan commentedon Jun 21, 2021
@Xuanwo What is a committer? Do we have this notion?
Xuanwo commentedon Jun 21, 2021
Well, we have not defined
committeryet. Let's useAll RFC requires at least 2 LGTMsinstead.We will track this problem in #116