Update template to fix #211

[kilasuit]

This adds suggested changes to the RFC template as part of issue #211

But also allows for an RFC author to say that they would like to implement this RFC themselves but may require some support to do so and gives them opportunity to detail any requirements for support they may have that would allow them to implement RFC.

[KirkMunro]

I have a few problems with this PR as it stands right now:

1. It's not enough.

   The RFC process needs documentation to accompany the template. This should be inline in the template at a minimum, in invisible HTML comments that can be removed during edit. Without it, the labels already in place, as well as the labels added as part of this PR, may not mean anything to RFC authors.

2. It feels hasty and I don't know that it addresses the problem it's trying to solve.

   One problem with the existing template is the field labelled Plan to implement. For many folks, it is not clear from the label that it is trying to answer is whether or not the RFC author plans to implement the RFC if it is approved. That question is also does not necessarily have a Yes/No answer, and you point out by this RFC with the additional note it adds; however, even with the additional question, that doesn't cover all of the scenarios either.

   I think a better approach would be something like this:

   Author willing to implement: <Yes, I got this | Yes, but I may need help | Maybe | No>
   

   That sticks to one field, and gives the PS Team a better idea of what someone is willing to do than the simple Yes/No question. Also by changing "Plan" to "Author willing", it is much easier to understand what is being asked. With this I don't believe the extra field is necessary (and using the word "Support" comes with expectations, so I would stay away from that one).

3. The new headings have no meaning.

   What does "Supporting Adoption" mean in the context of the template? And I don't know if the last heading of "Support required to implement" is appropriate at all, because the point of the RFC is to hash out a solid plan for a feature. Whether or not someone needs help on implementing that feature is a different discussion that should be had independent of the RFC itself. It's not the best place to have technical questions about how to implement an RFC -- those could be hashed out in Slack or in Issue discussions.

4. We need multiple templates.

   We should have multiple templates to choose from in the repository: one for forward compatible changes that will be made within PowerShell and released as part of PowerShell, and one for changes made external to PowerShell, in modules, where it is important to identify the minimum supported version of PowerShell that is planned for such changes. The impact of RFC changes should be clearly understood by a combination of the template that is used and documentation in the RFC repository that it links to.

I think there's more discussion to be had in Issues first, so that we can make a solid update to the RFC process/templates/documentation, rather than go through a few iterative updates that RFC authors have to adjust to along the way.

[KirkMunro]

Also a minor detail: it's better if the title of a PR clearly identifies what the PR is addressing, so that readers of the PR don't have to chase down that important detail.

[joeyaiello]

We on the @PowerShell/powershell-committee agree that something like this could be useful, and we also agree with most, if not all, of @KirkMunro 's comments. Given that we're still planning to update the entire RFC process, we're going to close this one and take all of this feedback into consideration with the new template.