RFC: Tune the RFC process to the needs of the ReactiveUI project

[havremunken]

Summary: Let us have a discussion on how WE will do RFCs - we are free to borrow ideas from FSharp, Rust or Ember, but not required to copy them exactly.
Expected impact: Project-wide

From some light reading while I should have been working, the following is starting to make some sense to me.

1. Someone has an idea on how to improve RxUI. Doesn't matter if it is a huge idea or restricted to one sub-team, and it also doesn't matter who this someone is.
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.
3. Automatic and not-so-automatic actions spreads the word about the new RFC. Slack, twitter?
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.
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. Someone with more knowledge than me of Github should figure how how exactly this happens - I'm thinking that the RFC lives in reactiveui/rfcs, but the actual implementation of the change needs to live in the repository actually relevant to the project. So am I wrong, should the RFC PR actually then live in the repo for the project it affects?
6. Implementation, testing, further discussion occurs until the goal of the RFC has been attained.
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.e. unless the RFC targets the docs themselves, involve the learning team to make sure "outsiders" have an opportunity to learn about whatever the RFC brings to the table.
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.
9. End of RFC. Issue closed, history has been made, thanks for your effort.

This is a suggested starting point. Now please tear this apart. :)

[RLittlesII]

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?

[AndyDentFree]

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.

[havremunken]

@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.