RFC: Tune the RFC process to the needs of the ReactiveUI project about rfcs HOT 3 OPEN

I love the fact that you are thinking about this. I agree with a lot of your points. I will add my three cents.

2. They try to describe and discuss the idea as an issue in the reactiveui/rfcs, much like I am doing right now. Should there be a template? Probably not a bad idea.

I would argue some form of RFC template should be established. We want uniformity and some level of detail in order to consider the request valid.

4. The team(s) involved need to take a look - if the idea is spam or obviously worthless, get rid of it. Otherwise, we need to be scientists about it, see the good and bad sides etc. and discuss the thing until it is completely understood

It is important that we are scientist about it, weight options chime in. Give the RFC some serious consideration. Even evaluation of how it should be incorporated into the library. Maybe some level of technical design. This will allow new people ( like myself) the ability to see the process, follow and contribute.

5. If the community agrees that this should move forward, it should be given an identifier (a proper RFC number) in an official list (like FSharp does), and a Pull request should be opened containing the name.

I would think a PR, Feature Branch and Issue in the repository where the work is being done would be ideal.

7. If our process is correct, at this point the functionality/changes should be ready to move into the current version of the project. EFFORT SHOULD BE MADE TO SYNCHRONIZE THESE CHANGES INTO THE DOCS AT THE SAME TIME

I would argue that there be a set of criteria for any feature to be merged in.

• API level documentation
• Unit Tests
• Integration Tests
• Feature break down to show the value add for people consuming
• Blog post highlighting the RFC

8. Hold-your-breath-period where we evaluate the RFC itself and perhaps even the RFC process to see what could have gone better or been handled differently.

I would argue that we would need some form of beta process. Not as extensive as ReactiveUI 8.0. This is asking a lot, but maybe an app sample that highlights the RFC and helps iron out wrinkles?

from rfcs.

For anything significant, I have a strong opinion based on my experience in other communities and with publishing APIs.

Feature break down to show the value add for people consuming

This is useful. Even better is a tiny compilable example which shows the current approach and can be put side-by-side with a working example once the feature works.

For any significant feature, as a consumer, I want to be assured that I can adopt that feature easily.

Such a code sample makes the blog post and other docs a lot easier to write and can be linked to.

from rfcs.

@RLittlesII , thanks for chiming in. This already shows the value of the RFC process - we all see the world from a slightly different angle, and you've already picked up on some valuable points that I missed in my original post.

Of course it would be beneficial if some of the higher-ups in the project would share their opinions as well - they have experience and history that they could bring to the RFC table to affect how we do this thing.

And to your comments on template and "being scientific", @AndyDentFree here also makes a valid point - this needs to be seen from the perspective of both the code teams (i.e. various platforms), the learning team etc., but also the consumer of the project.

I like your criteria for new features. Of course, the criteria might vary depending on what the RFC seeks to change; Unit tests don't make a lot of sense for documentation changes, but perhaps some sort of automated spelling / grammar check would make sense here? But yeah, agreed 100%, new or changed items need docs, tests (for code) and all the information both we and the project could desire. The learning team would need a heads up on how and where to work on material covering the changes so that we can work in parallel with getting stuff ready.

I love the idea of a simple, self-contained sample app that focuses on one feature alone. This could kinda be in the same spirit as TDD and ensure that we know when the feature is complete, AND do wonders for our Samples repo.

from rfcs.