doc(rfc): Add requirements / non requirements section to RFC.

[jplaisted]

This seems helpful to reviewers (and probably also the author). Motivation is too high level to be able to properly review a design. We need a clear set of requirements to review the design against.

Stems from comments on #1778 (review)

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable)

[keremsahin1]

Why is this a sub-section of requirements? Shouldn't it be top level or a sub-section of detailed design?

[jplaisted]

Extensibility requirements? I'm fine either way, but this a little clearer is it still a list of requirements.

[hshahoss]

Would be good to have this as a separate section as part of "Future Work".

[keremsahin1]

Do you think Goals & Non-goals would be better?

[jplaisted]

No, those can be too high level imo. "Goals" says high level, "requirements" says specific, to me at least.

For most designs I really think we need a detailed, bulleted list. We need to consider the design's requirements/goals in detail from the outset, and in plain English (outside of detailed design).

[mars-lan]

Let's also add a deadline section? Depending on the size of RFC, we can have 1 week for small, 2 weeks for medium, and 4 weeks for large. The reviewers can request extensions (maybe 1 week at a time?) if the discussion isn't converging. This way we can move RFCs forward at a more predictable pace.

[jplaisted]

Let's also add a deadline section? Depending on the size of RFC, we can have 1 week for small, 2 weeks for medium, and 4 weeks for large. The reviewers can request extensions (maybe 1 week at a time?) if the discussion isn't converging. This way we can move RFCs forward at a more predictable pace.

Should that be in the RFC or in the PR/issue? Either way probably involves updating the process doc. And can be done in a different PR :)

[mars-lan]

Let's also add a deadline section? Depending on the size of RFC, we can have 1 week for small, 2 weeks for medium, and 4 weeks for large. The reviewers can request extensions (maybe 1 week at a time?) if the discussion isn't converging. This way we can move RFCs forward at a more predictable pace.

Should that be in the RFC or in the PR/issue? Either way probably involves updating the process doc. And can be done in a different PR :)

Ideally both, but definitely for RFC. PR should really just be a straight forward realization of RFC and should be less controversial when it comes to review time.

[jplaisted]

Let's also add a deadline section? Depending on the size of RFC, we can have 1 week for small, 2 weeks for medium, and 4 weeks for large. The reviewers can request extensions (maybe 1 week at a time?) if the discussion isn't converging. This way we can move RFCs forward at a more predictable pace.

Should that be in the RFC or in the PR/issue? Either way probably involves updating the process doc. And can be done in a different PR :)

Ideally both, but definitely for RFC. PR should really just be a straight forward realization of RFC and should be less controversial when it comes to review time.

I think my concern is discoverability. I don't want an RFC opened with a week deadline and then just an immediate submit a week later. So if you aren't getting comments, I'm not sure putting it in the review is the best place to put it? I think we need more of a process around it. So I think we can do this in a different PR.