RFC0000-RFC-Process comments

[SteveL-MSFT]

Use this to track comments for https://github.com/PowerShell/PowerShell-Language-RFC/blob/master/RFC0000-RFC-Process.md

[joeyaiello]

My suggestion is that, until an RFC reaches either Accepted or Experimental status (somewhat ambivalent as to which one is the gate; others may not be), it should only exist as a pull request from another branch. This way, people can comment on the RFC on a line-by-line basis as opposed to either forking, editing, and pull requesting, or referring to line #s on the associated Issue. (There's also the added benefit that I don't lose all my comments when working a little bit at a time in a browser window.)

From there, I think the Issue should be generated once the pull request is accepted (again, after it reaches either Accepted or Experimental.) There you can track comments on RFCs that are already in flight.

Alternatively, we could just require that people spin up an Issue for every problem that they have with an RFC, but that could be a bit too noisy.

Thoughts?

[vors]

sounds reasonable

[JamesWTruher]

We need to be sure that these RFCs don't wither on the vine. I think that part of the process should clearly mandate a time frame for comments - for example: Comments will be accepted until < date >. We need to describe timelines and closure actions in every RFC.

[vors]

We want to cover two main scenarios:

1. Gathering feedback about a new text
2. Continue gathering feedback about an existing text

We can address them in the same manner or differently.
I propose to use "PR+comments for PR" for (1).
Then, when PR is merged, we open an issue with the corresponding name to address (2).

[SteveL-MSFT]

@JamesWTruher added verbage in Process that typically we want to allow 2 months for comments. added due date to Mutual Exclusion doc as example

[SteveL-MSFT]

Feedback addressed