Use pull/issue # as sequence numbers in the RFC file names about oteps

[yurishkuro]

Yes, or the number of the PR if there is no tracking issue, since it's the same unique sequence.

[carlosalberto]

I was not talking about a PR for this issue

Aha! Gotcha, sorry :)

PRs can be made to amend it before it becomes accepted in a final PR

Yeah but that takes extra iterations. I'd be definitely up to something as simple as possible (as the number-after Issue approach)

[yurishkuro]

Most of the discussion here seems to be missing the main point - we have a whole lot of useless process:

• get N approvals for a PR
• bug admins to "assign a number", push another change to rename (100% useless chore)
• wait for admins to merge merge PR as "pending"
• open another one to "switch to approved" and again wait for approvals (500% useless chore)

All that can be simply fixed by using dates or the tracking issue ID (which I like even better):

• Open issue describing the problem, get initial agreement (no extra work, the wording of the problem can be transferred to the RFC)
• Use issue number as the RFC number - thanks to GitLab's globally unique issue #s :-)
• A single PR, no additional admin changes
• A single round of approvals

[lizthegrey]

We either need this, or we need some mechanism of reserving sequence numbers (maybe the tracking Issue reserves the number? IMO that would be way simpler and let us maintain easy correlation between tracking issue and RFC)

[yurishkuro]

Numbers are meaningless anyway, dates at least convey certain info as well as serve unique (ish) IDs. But yes, starting with a ticket describing the problem, and then a PR with an RFC numbered after the issue sounds like a stable process.

[yurishkuro]

And to clarify, the intent of this proposal is to remove the "proposed" state of the RFCs, because it results in silencing the discussion by switching the focus onto another "approval" ticket.

[Oberon00]

Using PR numbers is what rust-lang/rfcs does, and it seems sensible. But I don't think reserving a number is what drives people to merge an RFC ASAP. Merging an RFC means that the community agrees that this is worth discussing. Also, you can make a PR to modify a merged-as-proposed RFC.

[carlosalberto]

starting with a ticket describing the problem, and then a PR with an RFC numbered after the issue sounds like a stable process.

I think this is very good way to address things - we both simplify RFC process, and we also keep on using numbers.

Also, you can make a PR to modify a merged-as-proposed RFC.

Usually PRs are used for the Specification, not the repo itself, no? Also I think this change is relatively straightforward, not sure we need a PR for that anyway ;)

[Oberon00]

Usually PRs are used for the Specification, not the repo itself, no? Also I think this change is relatively straightforward, not sure we need a PR for that anyway ;)

I think there is a misunderstanding here. ❓ I was not talking about a PR for this issue but I was making the argument that one advantage of the two-step RFC process is that while the RFC is in the proposed state, PRs can be made to amend it before it becomes accepted in a final PR.

[Oberon00]

You wouldn't even need an issue, just create the PR with 0000 and then push another commit to it that assigns the number of the PR.

[carlosalberto]

just create the PR with 0000 and then push another commit to it that assigns the number of the PR

I remember hearing the case of the desire of merging a PR once it has enough approvals, and then having to wait for the maintainer/somebody else to go update the number first (instead of simply pressing the Merge button, as we usually do with the rest of the code).

What would be the cons of number-after Issue approach?

[Oberon00]

I would push a commit that assigns the number of the PR immediately (the same number as the PR, i.e. assigned by the GitHub PR system). No need for any additional persons to be involved.

What would be the cons of number-after Issue approach?

Just that you need an additional issue. 🤷‍♂ I have no objections against that either, there was talk about having tracking issues that gather/link all discussion for an OTEP anyway.

[lizthegrey]

Do we have agreement on either using the PR number or the tracking bug here?

[lizthegrey]

We're talking the same thing then. Use the issue id number of the tracking issue, and done.

[tigrannajaryan]

Are we going forward with this? I think everybody was on board in the last Spec SIG meeting.

[yurishkuro]

Looks like we have an agreement, someone needs to update the README with the new process.

[tedsuo]

👋 PR is here (#55), I incorporated this into the process simplification we discussed at the last Spec meeting.