reactiveui / rfcs

RFCs for changes to ReactiveUI

What is ReactiveUI?

ReactiveUI is a composable, cross-platform model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming, which is a paradigm that allows you to abstract mutable state away from your user interfaces and express the idea around a feature in one readable place and improve the testability of your application.

🔨 Get Started 🛍 Install Packages 🎞 Watch Videos 🎓 View Samples 🎤 Discuss ReactiveUI

Book

There has been an excellent book written by our Alumni maintainer Kent Boogart.

NuGet Packages

Install the following packages to start building your own ReactiveUI app. Note: some of the platform-specific packages are required. This means your app won't perform as expected until you install the packages properly. See the Installation docs page for more info.

Platform	ReactiveUI Package	NuGet
.NET Standard	ReactiveUI
	ReactiveUI.Fody
Unit Testing	ReactiveUI.Testing
WPF	ReactiveUI.WPF
UWP	ReactiveUI.Uwp
WinUI	ReactiveUI.WinUI
MAUI	ReactiveUI.Maui
Windows Forms	ReactiveUI.WinForms
Xamarin.Forms	ReactiveUI.XamForms
Xamarin.Essentials	ReactiveUI
AndroidX (Xamarin)	ReactiveUI.AndroidX
Xamarin.Android	ReactiveUI.AndroidSupport
Xamarin.iOS	ReactiveUI
Xamarin.Mac	ReactiveUI
Tizen	ReactiveUI
Blazor	ReactiveUI.Blazor
Platform Uno	ReactiveUI.Uno
Platform Uno	ReactiveUI.Uno.WinUI
Avalonia	Avalonia.ReactiveUI
Any	ReactiveUI.Validation

Sponsorship

The core team members, ReactiveUI contributors and contributors in the ecosystem do this open-source work in their free time. If you use ReactiveUI, a serious task, and you'd like us to invest more time on it, please donate. This project increases your income/productivity too. It makes development and applications faster and it reduces the required bandwidth.

Become a sponsor.

This is how we use the donations:

• Allow the core team to work on ReactiveUI
• Thank contributors if they invested a large amount of time in contributing
• Support projects in the ecosystem

Support

If you have a question, please see if any discussions in our GitHub issues or Stack Overflow have already answered it.

If you want to discuss something or just need help, here is our Slack room, where there are always individuals looking to help out!

Please do not open GitHub issues for support requests.

Contribute

ReactiveUI is developed under an OSI-approved open source license, making it freely usable and distributable, even for commercial use.

If you want to submit pull requests please first open a GitHub issue to discuss. We are first time PR contributors friendly.

See Contribution Guidelines for further information how to contribute changes.

Core Team

Glenn Watson Melbourne, Australia	Rodney Littles II Texas, USA	Artyom Gorchakov Moscow, Russia
Colt Bauman South Korea	Chris Pulman United Kingdom

Alumni Core Team

The following have been core team members in the past.

Geoffrey Huntley Sydney, Australia	Kent Boogaart Brisbane, Australia	Olly Levett London, United Kingdom
Anaïs Betts San Francisco, USA	Brendan Forster Melbourne, Australia	Claire Novotny New York, USA

.NET Foundation

ReactiveUI is part of the .NET Foundation. Other projects that are associated with the foundation include the Microsoft .NET Compiler Platform ("Roslyn") as well as the Microsoft ASP.NET family of projects, Microsoft .NET Core & Xamarin Forms.

rfcs's Issues

funding: what sort of sponsors are unacceptable?

observation

• three of the sponsors on the reactiveui page at the moment are online casinos
• afaik they do not use reactiveui
• they are buying the advertising slots

RFC: [Learning Team] Interactive Documentation

The ability to visualize things and experience reactive programming without having to download/configure their developer workstation will definitely mean the difference between failure and success in getting someone to grok how stuff fits together.

The JavaScript ecosystem has a bunch of fully interactive tutorials but the .NET ecosystem doesn't which a hump that shouldn't exist. One shouldn't need to download Visual Studio to learn - let's get rid of this requirement.

The Xamarin workbooks team has a solution - it's super early but I think we are in a position where we could PR them and make the future happen sooner.

Here are some screenshots of ReactiveUI running in the browser - no downloads required:

If you want to take it for a whirl the fastest route right now is to do as follows:

git clone [email protected]:reactiveui/try.reactiveui.net-binaries.git
cd try.reactiveui.net-binaries
dotnet workbooks-server.dll
start http://localhost:5000

If you want to hack on this:

• Clone down http://github.com/reactiveui/try.reactiveui.net
• Introduce yourself over at https://gitter.im/Microsoft/workbooks
• Discuss below 👇

RFC: [Learning team] Onboarding tutorial for ReactiveUI

When I start using a new library or framework, there are two things I really appreciate: Good reference docs, and a tutorial showing me WHY this is a good idea and HOW to get going.

I'm talking about addressing the newborns here. The people who may have heard about Reactive Extensions, who perhaps gets the basic concept of a viewmodel, but when they look at the RxUI docs site will look like a huge question mark and think "How will any of this ever be useful to me?" - the people that need motivation to join us.

So I thought as my first contribution to the learning team, I could get going on on this "onboarding" tutorial. The "Welcome to ReactiveUI" bit. Once again my primary source of inspiration as I write this is how the Ember.js project has done it. Take a look at their guides site here:

https://guides.emberjs.com/

This will take you to a friendly site that promises to take you from total beginner to expert. Ambitions are good!

As you can see, it has a bunch of subsections. First "Getting Started" shows you how to get it onto your system and explains core concepts. Then the tutorial goes through every step of creating an app from planning to deploying. Each page is relatively short, explains the relevant concepts well, and has source code listings aplenty. They even spend time showing how you test these features as you learn them to get into good habits early.

A similar (updated) tutorial for RxUI would be extremely useful (I've missed it in the past myself). As pointed out in my other docs-related RFC we might need to allow the user to choose the platform they want guidance on - the main structure of the tutorial would probably be the same, but that would mean several versions of each page with custom text, source code and screenshots for each platform.

In my mind, we would need to come up with one simple, understandable but still real-world-relevant example to follow through the entire tutorial. It would make sense to write a ViewModel object using plain C# to see how awful the world is without RxUI (note: Would it be a good idea to show how this could be done in other UI frameworks as well, to help people coming from there to us?), and then step by step improve it using observables and friends. It could start with a short explanation of how MVVM is The Right Path and reactive extensions are awesome, and then show how RxUI lives at the intersection of these two concepts.

I believe such a tutorial is a good idea, but since I am new to the project I would love some input on this RFC before I start working on it. So please feel free to disagree or add additional points that would be good to include. The primary goal of this RFC is to create something that makes users WANT to use RxUI for everything.

RFC: Make mobile more accessible

We all talk about moving towards a more accessible web. This leaves out a category that we all use in our daily lives i.e. Mobile applications. How about we change that by adding an accessibility plugin/package to ReactiveUI.

I did a bit of research on what Xamarin Forms offers us in terms of accessibility and having a read through https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/accessibility/ tells us that XF has built in support for screen readers and buttons/text entry handles. It's just that when people make XF applications they forget or leave out accessibility all together.

By creating conventions around writing controls we can modify fields to be like :

<Entry AutomationProperties.IsInAccessibleTree="true" />
and then and help text around it with the placeholder forms or actions:

<Button Text="Toggle ActivityIndicator" AutomationProperties.IsInAccessibleTree="true" AutomationProperties.HelpText="Tap to toggle the activity indicator" />

Lets discuss what the implementation could look like and move towards a more accessible mobile

https://www.w3.org/WAI/standards-guidelines/mobile/

RFC: [Core Team] Improving list-based databinding, documentation and standardising (mobile) platforms

• Start Date: 2018-05-18
• RFC PR: (leave this empty)
• ReactiveUI Issue: (leave this empty)

Improving list-based databinding, documentation and standardising (mobile) platforms

Summary

I think list-based navigation and data insight is one of the most commonly seen UI/UX paradigms on current mobile platforms, even desktop platforms before that. But for this RFC I'm focussing on iOS and Android since that is what I know best.

I've noticed that data-binding list- or collection-based data to multiple platforms is currently cumbersome because of platform differences, and how ReactiveUI is currently heavily mirroring platform-available functionality only.

Motivation

The data itself is often identical across platforms, so it would be great if it could be treated as such. Unfortunately both iOS and Android both have different platform-level features for handling data in list- or collection-based formats. iOS for example offers sections, where Android does not (by default).
ReactiveUI in itself has adapted to the platforms by offering, for example, TableSectionInformation on iOS to supply a TableViewSource with section information.
This means you'll need to reformat your data on iOS the group sections based on one or multiple properties, and while this isn't necessarily hard, it's cumbersome and requires quite some boilerplate every time.
It can also complicate things like searching or filtering since the data formatted in your ViewModel may not end up being what's presented in the view.

I'm personally not a big fan of abstracting platform-level features to some most-common denominator of all. Hence why I refuse to use Forms for anything else than a simple prototype. But in the end you're often recreating the same section experience on Android and it would be nice if ReactiveUI could help you with this so you can format your data from the source.

Detailed design

This is the current state of affairs on Android:
You can create an instance of ReactiveRecylerViewAdapter for every collection change, and supply the new IReadOnlyReactiveList to the adapter.

On iOS you have a lot more options:
You can use BindTo to bind your IReadOnlyReactiveList directly to a TableView or CollectionView.
Or you can do the equivalent to what you can on Android and create your own ReactiveTableViewSource or ReactiveCollectionViewSource.
You then have the option to supply an IReadOnlyList of TableSectionInformation which allows you to specify section grouping, headers and footers.

I would propose to bring TableSectionInformation (or CollectionViewSectionInformation) to the NETStandard library, remove features that are platform or view specific like InitializeCellAction, maybe replace them with platform-independent variants purely to prepare data for cell representation.

In the case you do want to initialise the cell layout or view holder properties, it's still easy to extend these in the platform projects if you so desire using your own Adapter or DataSource implementations.
This way it's easier for most use-cases to get started with section-based list data, but it's still extendable for advanced usage.

Lastly there needs to come a ReactiveRecyclerViewAdapter implementation with support for sections. It might be insightful to look into how other projects have implemented this. I haven't done extensive research on this front yet. Any ideas are welcome!

Bonus; Maybe we could also bring the BindTo syntax of iOS to Android or other platforms where this is useful.

How we teach this

Currently there's almost no documentation regarding data binding of lists on any platform as far as I can find. I had to discover methods like BindTo on UITableView myself, and had to look into the source of ReactiveUI to find out how it even works.

I've been thinking of writing docs long before today, but it's a confusing mess at the moment due to the differences in platform implementations. So I feel a refactoring is warranted before even getting started on docs.

Drawbacks

Well, for starters, I hardly have any experience with or interest in any other platforms than iOS or Android

We would also impose some more platform-dependency and effort to keep the SectionInformation implementation working with all supported platforms, but I feel this is worth the trouble as it would seriously improve the developer experience.

Other than that I think we could deprecate the current implementations on iOS (because I don't think Android would be affected a lot) but keep it intact until vNext without too many consequences to ease transitioning.

Alternatives

The alternative would be to not do a lot about it, maybe only introduce some BindTo functionality to other platforms and finally write up some docs on how to use it.

Unresolved questions

• How are people currently handling the differences in implementation of these types of data per platform?
• Can we adopt this idea to Forms as well? (Looking at the docs it seems to support grouping.)
• How can we best make current platform-features available like supplying a header cell identifier on iOS?
• Are there any favourable implementations of sections based RecyclerViews on Android?

RFC: Turn on Analyzers

Now that the main ReactiveUI repository is down to 0 pull requests I want to take the opportunity to mostly do a non-public changing refactor to turn on three different analyzers

• https://github.com/DotNetAnalyzers/StyleCopAnalyzers
• https://www.nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers/
• https://www.nuget.org/packages/Roslynator.Analyzers/

The stylecop ones enforce Documentation for all our public facing code (an issue for our website) and will keep code consistent. The stylecop analyzer can enforce two different class variables naming scheme, that is where we have no prefix on the variable name, and use "this.myClassVariable = 20;" or use a _ prefix, eg "_myClassVariable = 20;"

The Microsoft FX Cop analyzers have a bunch of analyzers that used to live in the static analyzers, they tend to pick up things like not disposing objects correctly, Very common code mistakes. Some localization stuff as well.

The Roslynator Analyzers pick up very common coding practices, like use Method Groups instead of Lambda for example. These emulate a lot of the analysis that Resharper does.

The normal main point with these types of suggestions is they make PRs harder so something we can only do while our PR number is 0.

RFC: UWP View First gets rid of animation transition, how do we fix

As reported in #13 the UWP transitions don't flow nice with RxUI View First navigation, how do we fix?

RFC: Make ReactiveList obselete and promote DynamicData

This relates to reactiveui/ReactiveUI#1372

Summary: Move the ReactiveList based series of classes to the Legacy namespace and mark them obsolete and direct them to the DynamicData (DD) github page.

Reason: The ReactiveList classes are getting a bit clumsy and the DD framework is much more powerful. It has a API more inline with the Rx style of doing things. Roland Pheasant is also very active on the project. By making ReactiveList redundant it will allow the core developers and contributors to focus on the more critical functionality.

Side effects: The potential side effect is projects relying on the ReactiveList. Although the ReactiveList will still be available it's not immediately straight forward how to do the conversion. Also can be a impact on @RolandPheasant with a increased user base.

Application Performance Monitoring Integration

• Start Date: (fill me in with today's date, 2019-02-01)
• RFC PR: (leave this empty)
• ReactiveUI Issue: (leave this empty)

Application Performance Monitoring Integration

Summary

To offer Application Performance Monitoring integration similar to how the Logging integration works.

Motivation

Scenarios
As a developer I want to know how often a command\event subscription is used. The duration and success rate
As a developer I want to know of failures
As a developer I want to be able to group events by feature/subfeature (with subfeature recursion)

I appreciate the examples are focused at ReactiveCommand. But you could define a feature as being a view\viewmodel.
Part of this belongs at the splat level as the APM toolset could be a direct target of the ILogger, depending on the features offered by the APM library.

Detailed design

When I played with the concept I used a disposable class so start event happened at construction. End event happened as dispose. I could call the error method as required (Ie exception). Alternatively I could just use generic helper methods and never touch the IDisposable wrapper.

The idea would be either to have a feature usage tracking aware subclass to reactive object or allow an IEnableFeatureUsageTracking extension interface. You could then hook up a reactive command that is aware of the parent feature and allows specifying the subfeature details.

Possible consumers
Visual Studio App Center (with appreciation wpf\winforms etc still trailing on support)
New relic
Application insights
Exceptionless

There was an interface for the target framework to have flexibility on how it works

    public interface IFeatureUsageTrackingSession<out TReferenceType> : IFeatureUsageTrackingSession
    {
        TReferenceType FeatureReference { get; }

        TReferenceType ParentReference { get; }

        string FeatureName { get; }
    }

There were interfaces so ReactiveUI and other consumers wouldn't get bogged down in the design details of the target framework

    public interface IFeatureUsageTrackingSession : IDisposable
    {
        IFeatureUsageTrackingSession SubFeature(string description);

        void OnException(Exception exception);
    }

    public interface IEnableFeatureUsageTracking
    {
    }

A sample implementation for App Insights

namespace Splat.ApplicationInsights
{
    using System;
    using Microsoft.ApplicationInsights;
    using Microsoft.ApplicationInsights.DataContracts;

    public class ApplicationInsightsFeatureUsageTracking : IFeatureUsageTrackingSession<Guid>
    {
        private readonly TelemetryClient _telemetry;

        public ApplicationInsightsFeatureUsageTracking(string featureName) : this(featureName, Guid.Empty)
        {
        }

        internal ApplicationInsightsFeatureUsageTracking(string featureName, Guid parentReference)
        {
            this.FeatureName = featureName;
            this.FeatureReference = Guid.NewGuid();
            this.ParentReference = parentReference;
            this._telemetry = Locator.Current.GetService<TelemetryClient>();

            TrackEvent("Feature Usage Start");
        }

        public Guid FeatureReference { get; }

        public Guid ParentReference { get; }

        public string FeatureName { get; }

        public void Dispose()
        {
            TrackEvent("Feature Usage End");
        }

        public IFeatureUsageTrackingSession SubFeature(string description)
        {
            return new ApplicationInsightsFeatureUsageTracking(description, this.ParentReference);
        }

        public void OnException(Exception exception)
        {
            var telemetry = new ExceptionTelemetry(exception);
            PrepareEventData(telemetry);

            this._telemetry.TrackException(telemetry);
        }

        private void TrackEvent(string eventName)
        {
            var eventTelemetry = new EventTelemetry(eventName);
            PrepareEventData(eventTelemetry);

            this._telemetry.TrackEvent(eventTelemetry);
        }

        private void PrepareEventData<TTelemetry>(TTelemetry eventTelemetry) where TTelemetry : ISupportProperties
        {
            eventTelemetry.Properties.Add("Name", FeatureName);
            eventTelemetry.Properties.Add("Reference", FeatureReference.ToString());

            if (ParentReference != Guid.Empty)
            {
                eventTelemetry.Properties.Add("ParentReference", ParentReference.ToString());
            }
        }
    }
}

How we teach this

In terms of Splat have some wrappers that show simple usage. Doesn't necessarily need the IDisposable pattern.

        public static async Task SubFeatureAsync(
            this IFeatureUsageTrackingSession featureUsageTracking,
            string featureName,
            Task action)
        {
            using (var subFeature = featureUsageTracking.SubFeature(featureName))
            {
                try
                {
                    await action;
                }
                catch (Exception ex)
                {
                    subFeature.OnException(ex);

                    //re-throw so parent logic can deal with
                    throw;
                }
            }
        }

ReactiveUI integration into the ReactiveCommand itself. Or show how to use the Splat helpers inside the executing subscription. Draw back to this is multiple try\catch.

Aside from Feature Usage Tracking. There is also the error\crash reporting piece, we could report UnhandledExceptions at the RxApp level. You then have a training piece available that as part of testing and development people can use an APM tool to see the list of Exceptions getting down to the core.

Feature: The top level ViewModel.
SubFeature: ReactiveCommand, Event, Possibly even the IViewFor<>

It can be sold as an opt-in feature to new and existing users. Same way the logging works.

In terms of ReactiveCommands. do you want an optional string argument for the feature name that dictates if a command even uses this?

Drawbacks

• Adding an extra layer of integration to support.
• Users still need knowledge of the feature\subfeature structure and how to utilise the APM tool.
• Visual Studio App Center limits to 200 distinct named events.

source: https://docs.microsoft.com/en-us/appcenter/analytics/event-metrics
source: https://docs.microsoft.com/en-us/appcenter/sdk/analytics/uwp

Might need something like the code below. But dictating to users how to Feature Usage Tracking in a pre-defined format?

Analytics.TrackEvent("FeatureUsage", new Dictionary<string, string> {
	{ "Name", featureName },
	{ Reference, FeatureReference},
	{ ParentReference, ParentReference},
});

Alternatives

Offer interfaces but not the end integrations and patterns of implementations.
Or have ways to overload.

Unresolved questions

Is it actually useful \ desirable?
What level of integration for Splat\ReactiveUI?
How to avoid overcomplicating ReactiveObject and making this opt in? or just treat the inheriting classname as the default featurename? if so, use weaving etc rather than reflection?
People need to be aware of the costings of the APM tool they choose. This is around giving the facilities to make decisions based on what users are experiencing.

RFC: [Learning team] - Remove as much friction from the doc contribution process as possible

As a hobby developer and occasional user of RxUI (I love it!), I consider myself very new to this side of the project, i.e. actually contributing to it. I am now a member of the learning team, but I am as of this writing completely, 100% ignorant of how the process of contributing to the docs happens. That is why I am writing this RFC now - so that hopefully, I can make some relatively unbiased comments on stuff that would be nice to have to lower the barrier to contributing good docs.

As we all probably know, writing docs is not usually what OSS developers want to spend their time on. There is usually little intrinsic motivation in that until the project reaches a certain size and popularity. RxUI seems to be at a point where material that would help people understand the benefits of using the project needs a level-up. And it isn't just potential users we could be missing out on. Potential new project contributors are out there, but without helping them understand how to help RxUI, perhaps they'll spend their energy elsewhere.

Of course, there is Kent Boogaard's book (and in time, Geoffrey Huntley's course). I'm not advocating competing with it. In fact, I think the docs should recommend buying and reading it, with references to specific chapters, for a fuller understanding of RxUI. But we need to get people started first. If using RxUI depends on ordering and reading a physical book, many will choose a path of less resistance. We need to make them see the elegance of RxUI and WANT to use it and WANT to buy the book. :)

The point of this RFC then is to figure out what we can do to make it as easy as possible to contribute documentation, to update documentation with short iteration cycles, to create complete and awesome docs that are ready at the same moment a new feature is released. You get the point.

As an example, I don't know how documentation is written today, as in - the format. Html? Markdown? LaTeX? DocX?

Would it not be good if as much as possible of the documentation could be done via a simple-to-learn format such as markdown, and then figure out a way to link pages together on the web site?

Structure is needed, no doubt. But within a well defined structural constraint we could hopefully thrive and produce good learning material.

Another point; We're going to write docs for a project that helps programmers write awesome user interfaces. What do we need besides text? Two things that we're going to need are screenshots and source code listings. So let us make those easy to get right by default. There is probably some form of code formatting style online somewhere we can borrow to make our code examples look awesome. And we'll come up with some rules for screenshots to make our docs look like they were done on purpose and not like they just kinda happened. And we'll need some spell checking for the non-native english speakers among us like myself. Correcting language - both syntax, grammar, but also rewriting sentences to make it easier to understand - should be welcome.

Then there is the matter of the different platforms RxUI supports. I work primarily in WPF. I have an iPhone myself, but I never programmed for it, and my experience with Android is completely non-existent. How do we make sure a UWP user or an Xamarin Forms user feels welcome when they read the docs? Should we have a "Platform" dropdown in the upper left corner, and then some sort of modular structure to the docs, showing the parts relevant to what they're after?

In the same way that we have different platforms, we also have different languages. I understand we already have several multilingual people on the team. I'm norwegian myself and there are only about 5 million of us (and not all of us are RxUI users, believe it or not) and most of us read english fairly well, so that language isn't very relevant anyway. Of course, huge world languages such as spanish needs to be addressed. And there are users in countries like Germany and France that would prefer their own language if possible. On this subject, our primary constraint is people. As long as we don't have someone with the capability to write solid German, there is little we can do. But once we acquire that person (or preferrably, more of them), how do we get them going with a mountain of docs?

Documentation is a huge subject that could probably justify way more than a single RFC. But for the learning team to agree upon how to do their job would be a great start. :)

RFC: [Xamarin Forms] When should we adopt Xamarin Forms v3.0.0 as minver?

We have never really had any documented strategy as to when the version of Xamarin.Forms used by ReactiveUI should be bumped. Folks of @reactiveui/xamarin-forms-team can you please come together and work out:

• What our policy is? When do we update minver for Reactiveui.XamForms and ReactiveUI.Events.XamForms
• Update https://reactiveui.net/docs/guidelines/platform/xamarin-forms with guidance for consumers of what we support
• Create https://reactiveui.net/contribute/maintainers/platform-knowledge/xamarin-forms/ with instructions for maintainers how/when to adjust these numbers

reactiveui/ReactiveUI#1631 is ready to merge - the question is when?

funding: 3000USD payment to Geoffrey Huntley

@ghuntley maintained this project for many years and setup the open collective.

He left the project back in 2018 but the project still owes him a big thanks.

In part of our community paying it forward I would propose that we allow @ghuntley to withdraw $3000 from the open collective. This is similar to past occurrences for past work.

Please use emoji based on your opinion of this proposal.

RFC: Order more stickers via OpenCollective

Not much discussion is needed. I'm opening this for transparency sake. I have a bunch of stickers from #mvpsummit and but cannot find them at the moment. When I find them then I'll ship em down to @glennawatson.

Anyway, I heard that we didn't have stickers at XDS.

So hey @RLittlesII I can share with you via LastPass my StickerMule account and then you can reorder the stickers. The last order was 1000 stickers which cost about $214 USD. Once you have the invoice please submit the expense claim.

Are you okay with also sending em out to folks? Like big packs to meetup organizers and to contributors? You can expense the postage costs. I can share the data behind https://reactiveui.net/stickers with you.

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

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. :)

RFC: Stack Routing API

Add Stack Routing API

Summary

This RFC is based on https://github.com/reactiveui/ReactiveUI/issues/1107

The current implementation of RoutingState exposes navigation as a set of commands on an ObservableCollection<IRoutableViewModel>

Xamarin.Forms has built in navigation based on a stack data structure.

public interface INavigation
{
  IReadOnlyList<Page> ModalStack { get; }

  IReadOnlyList<Page> NavigationStack { get; }

  void InsertPageBefore(Page page, Page before);

  Task<Page> PopAsync();

  Task<Page> PopAsync(bool animated);

  Task<Page> PopModalAsync();

  Task<Page> PopModalAsync(bool animated);

  Task PopToRootAsync();

  Task PopToRootAsync(bool animated);

  Task PushAsync(Page page);

  Task PushAsync(Page page, bool animated);

  Task PushModalAsync(Page page);

  Task PushModalAsync(Page page, bool animated);

  void RemovePage(Page page);
}

Motivation

The current RoutingState currently has no support for the following concerns:

1. Animation
2. Navigation and Modal stack
3. Passing parameters on navigation

I am proposing we introduce a reactive abstraction base on Custom Routing in ReactiveUI. This would provide view model based navigation and better reflect stack navigation patterns.

public interface IRoutingStack
{
    IObservable<IImmutableList<IRoutableViewModel>> ModalStack { get; }

    IObservable<IImmutableList<IRoutableViewModel>> PageStack { get; }

    IView View { get; }

    IObservable<Unit> PopModal(bool animate = true);

    IObservable<Unit> PopPage(bool animate = true);

    IObservable<Unit> PopTo<TViewModel>() where TViewModel : IRoutableViewModel;

    IObservable<Unit> PopToRootPage(bool animate = true);

    IObservable<Unit> PushModal(IRoutableViewModel modal, string contract = null);

    IObservable<Unit> PushPage(IRoutableViewModel page, string contract = null, bool resetStack = false, bool animate = true);

    IObservable<IRoutableViewModel> TopModal();

    IObservable<IRoutableViewModel> TopPage();
}

Discussion

I know there are benefits to the current RoutingState implementation, I want to make this an option for stack based navigation platforms.

Questions

How do we handle platforms that don't have a concept of a modal stack?

If we implement passing parameters does it make sense for all platforms?

Do we allow consumers to implement their own IRoutingStack and register it for use with ReactiveUI?

Are there any performance concerns or improvements that could come from this change?

RFC: How to support DI containers other than Splat

How to support DI containers other than Splat
Summary
Users are finding one DI container a pain point. How should we handle more than one DI container while allowing Splat to be the default.

Motivation
Users tend to have their own DI engine, and we've had several confused users through the years. This came out of #13

Discussion
What should be our approach to allow it? Should we allow it?

RFC: Create SECURITY.md

Is your feature request related to a problem? Please describe.
Currently there is no way for people to report security vulnerabilities in any of the ReactiveUI packages.

Describe the solution you'd like
Add a SECUTIRY.md file as suggested by GitHub that lists versions that will get security patches and a way for people to securely send reports.

Describe suggestions on how to achieve the feature
I recommend creating a publishing a PGP key for someone to encrypt their communications before reporting them to us via [email protected]. They can then be discussed as an advisory in the repository's security section. Sample: dotnet/corefx

Additional context
https://github.com/features/security

RFC: Remove ReactiveCommand abstract base class

At the moment we have a abstract base class ReactiveCommand (without generics).

I propose we move all the explicit ICommand stuff into ReactiveCommand<TIn, TOut> and remove the ReactiveCommand abstract class.

This is because users are having binding issues with the abstract version of ReactiveCommand and our current thing we tell users is not to use the abstract ReactiveCommand class.

RFC: [Core Team] Standardise English dialect

Standardize English dialect usage for ReactiveUI

Summary

While working on the ReactiveUI Website, an issue was pointed out about the spelling of a word reactiveui/website#90. This started a conversation that I am sure has happened in the developer community for years. What are is the correct spellings of words across the English Dialects.

Motivation

When dealing with a globally distributed project, and english is not everyones first language, this becomes a challenge. For native English speakers it is challenge enough to spell certain words correctly. Add dialect into the mix and English becomes more confusing, as english is a vary colourful language. I believe that standardizing our publicly facing content will go a long way in helping consumption of documentation and communications.

Discussion

I would like the @reactiveui/core-team and @reactiveui/learning-team to come together and select an english dialect for spellings moving forward to reduce friction and consumption for non native english speakers.

Side Note

Notice in this communication I explicitly used the same word spelled different ways to point out the confusion.

RFC: Nuget Packages confusing to users with separate platforms

As mentioned in #13 the nuget package system is non-obvious to the user at the moment.

We've had several users get confused by the exceptions being generated.

What do we need to do to fix it?

RFC: What are pain points with the ReactiveUI project as a user?

What are your pain points at the moment with RxUI?

Tell me and reply to this issue.

RFC: What's the plan with the monies?

ReactiveUI potentially will raise close to $10,000USD this year through the generosity of our backers and corporate sponsors. This is amazing. Thank-you

https://github.com/reactiveui/reactiveui#backers

@glennawatson raised the question in Slack as to "what's thje plan with the money". My thoughts have been recorded over at https://twitter.com/GeoffreyHuntley/status/1026413749819691009 within the first 10 minutes where "pateron vs open-collective" are detailed.

Our opencollective page includes a high-level overview on how I originally envisioned how the money would be used but we haven't progressed into implementation plans. It's time.

The TL;DR is: Money should be used to improve developer accessibility of ReactiveUI - some ideas:

• Buying people @kentcb's book people are interested in helping (and actually do) improve our documentation.
• Hiring a designer to rebuild our website and create a branding style guide/design guidelines
• Hiring professional documentation authors (http://www.writethedocs.org/) to author the content
• Hiring professional documentation authors (http://www.writethedocs.org/) to edit content writing by others.

Let's keep discussions away from "if we pay maintainers/developers" at this stage because it's too premature. It's time to start delivering on promises to our financial supporters.

/cc
@reactiveui/learning-team
@reactiveui/core-team
@reactiveui/community

RFC: Contribute to dependency OpenCollective funds

Organisations such as Fody have started up a OpenCollective and have been asking for Open Source projects to start their own and fund them.

I think we should do a survey of our dependencies and where appropriate contribute to those OpenCollective's.

In terms of amount to contribute I think if possible we should contribute around $5 to $10 USD per month as a maximum price point, with amounts going over that amount getting approval from another RFCs.

We should only contribute (without producing another RFC) direct projects we rely on.

Given that our team members are at the forefront of promoting the sustainability of OpenSource we should start contributing where relevant to other projects.