Correction of roles and workflow

[iSazonov]

Based on my first experience. 🐔

---

This change is 

[msftclas]

@iSazonov,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

[joeyaiello]

I owe you a review on this: the intent looks totally right, I appreciate you recognizing some of our gaps. I

f it's okay with you, I'll probably just push some of the language and terminology changes right into your branch.

[iSazonov]

@joeyaiello
While working on a RFC I asked @SteveL-MSFT and here I only tried to reflect his answers about workflow as I understood him.
So feel free to make any changes.

[iSazonov]

The line is still difficult to understand 😕

[joeyaiello]

How about:

No one has begun implementing the RFC, and there are no current plans to implement the RFC.

[iSazonov]

👍

[joeyaiello]

@SteveL-MSFT can you merge this when you get a chance?

Also, as a heads up, @iSazonov, we decided in our last community call that we need to revise the process itself here, and we'll likely be switching to PR-based feedback rather than issue-based feedback. When I get around to that, I'd like to add you as a reviewer to make sure we're not missing any gaps in the "new" process (it shouldn't be that different, but we're hoping it simplifies some of the manual steps). Sound good?

[iSazonov]

@joeyaiello From the short post I don't understood that is "PR-based" so I just explain what I see.

The main problem is the low activity. We need more advertising the opportunity to discuss our RFCs.
Therefore, we need a single entry point for discussion.
Then we can publish it in the PowerShell PG blog team, MVP's blogs, and UserVoice. I suppose it will not be too burdensome for maintainers if we add this to the process.
Perhaps we should create a referencing Issue in PowerShell repo with label "RFC-Discussion" (blocked for posts creation).
To provide a single point of entry we need to strike a balance between the use of Issues and PRs. Maybe even use GitHub Projects.

We also have to consider what to do a feedback post much easier than a PR. If we will be "PR-based" only we may lost 99% feedback.
With regard to PR we need Howto with easy step-by-step - we should not assume that feedback will only be from coders, git and GitHub gurus.