As a newly named lead contributor, I suggest the following policies and future plans regarding RxJava.

RxJava 1.x

The unfortunate side-effect of Ben leaving was the slowing down of managing PRs and releases. I intend to speed this up again with the following policies:

Trivial PRs

Trivial PRs no longer require at least 2 👍 from contributors and can be merged by any of them on their own right. A PR is trivial if it is about typo fixes in the javadocs, test fixes or performance tests.

Since documentation expressiveness is a common place for lengthy arguments, the merge first, discuss later policy should be in effect; disagreeing parties are welcome to post their follow-up PRs.

Bugfixes

If a PR aims to fix a bug without changing the public surface API, collaborators can merge them on their own right or ask for additional review from the other collaborators. In this latter case, an additional 👍 is required for merging.

If the bugfix involves surface API changes, at least 2 👍's are required. If the proposer of a PR is a collaborators, that automatically counts as 👍

If the bug (of any complexity) is related to other platforms, such as Android, or is a cross-library bug, such as with rxjava-string, and the fix itself is of some doubt, I propose accepting @JakeWharton's, @artem-zinnatullin's and @davidmoten's 👍 as equal to the 👍's of the core collaborators.

When a bug has been identified and the fix proposed, a patch release has to follow within a week for high impact bugs or within 2 weeks for medium impact bugs. For low impact bugs, the regular release cycle applies (see below). (Example high impact bug: crash in flatMap; medium impact bug: performance degradation in ReplaySubject; low impact bug: missing argument validation.)

If the proposed bug is not merged within the time limit due to lack of feedback or lengthy discussions, I reserve the right to be the final judge on the issue.

Performance enhancements

If a PR contains performance enhancements and no surface API changes, collaborators are allowed to merge the PR without the need for additional 👍 provided there is at least one other person (collaborator, the poster of the original issue or other contributors) confirming the improvements.

API enhancements

There are usually 2 complaints with RxJava's API: "it has too many methods/operators but doesn't have my operator".

On one hand, I'd like to avoid RxJava becoming a dumping ground for all sorts of exotic yet small impact operators. The existing extension points lift, compose and extend allow adding operators with minimal inconveniences.

On the other hand, past enhancement PRs were delayed quite significantly, due to lack of attention or too long discussions, hindering progress on releases and other PRs.

To avoid these problems, enhancement PRs require at least 2 👍 from the collaborators. If the proposer is also a collaborator, the PR still requires at least 2 👍 from the other collaborators.

If such a PR doesn't get the required 👍 (and thus merged) within two consecutive releases, the PR can be closed by any collaborator.

Issues

Issues identified as questions or discussions can be closed by collaborators after 30 calendar days of inactivity. Inactivity means the question appears to be answered or the OP didn't provide additional feedback.

Bug reports should be closed if the fix PR has been merged or rejected without any alternative fix.

Issues related to test failures on Travis CI should be closed if the failure doesn't appear within 60 calendar days again in PRs or in master builds.

Issues related to feature requests or enhancement proposals can be closed after 30 calendar days and if two or more 👎 has been signalled.

Patch releases

As features and bugfixes are merged in and no medium or high impact bugfix is among them, a patch release happen at most within 4 weeks. In the unlikely event there are no merges within this time period, the at most 4 week countdown starts when the next PR is merged.

Medium or high impact bugs and enhancements can be released sooner, provided at least 2 👍 is received for a release proposal.

Since a release involves updating the CHANGES.md, 👍 on the related issue and PRs all count towards the minimum 2. (I.e., no need to 👍 both the issue and the PR actually changing the file).

Release 1.2

The 1.1.x has accumulated quite a few deprecated APIs and I think most high and medium bugs (mostly backpressure related) have been ironed out.

Following the 1.0.x -> 1.1.0 switch before, I propose finishing up and releasing 1.1.7 in 4 weeks from now (15/7/2016) and then release 1.2 in 5 weeks from now (22/7/2016). Version 1.1.7 will have the API intact. Version 1.2 will have the deprecated API removed and beta/experimental APIs promoted/demoted. Suggestions for further deprecation should go through a regular PR before that.

I'll distribute a questionnaire regarding the API promotion/demotion to the collaborators and also publish it publicly.

RxJava 2.x

Although there is a working RxJava 2.x branch, its architecture is quite outdated.

The new architecture, as described in Design.md focuses on performance and reduction of object allocations whenever possible.

Switching to this new architecture requires changing how operators are instantiated in the first place. This change has the largest one-time impact for 2.x. Once done, applying the advanced operator-fusion to the operators can be done in smaller PRs thereafter.

Adding operator-fusion won't block release candidates and can happen incrementally.

This is my proposed schedule for 2.0:

• Update core architecture: till: 1/7/2016
• Agree on the maven group ID (Version 2.x Maven Central Identification #3170): till 15/7/2016
• Decide about operators: to drop, to port from 1.x or to change behavior: till: 5/8/2016
• Add missing javadoc: till 12/8/2016
• Synchronize unit tests from 1.x: till 19/08/2016
• Release Candidate 1 : 26/08/2016
• Release Candidate 2 : 23/09/2016
• Release Candidate 3 : 21/10/2016
• Release 2.0: 28/10/2016

Other responsibilities of mine

You may know I have been contributing to Project Reactor lately and also doing my research in the Reactive-Streams-Commons (Rsc) project. Since both Project Reactor and RxJava 2.x benefit from Rsc (and are basically cousins in their style anyway), I don't expect any duplicate work or split attention between these projects.

In addition, I don't consider Project Reactor to be a direct competition because its dependency on Java 8 and the choice of supported operators (some missing, others extra).

Lastly, I'm also working under their umbrella on porting Rsc/Reactor to JavaScript/TypeScript and .NET. These ports happen mainly for the reason that neither RxJS 5 nor Rx.NET 3 seems to care about the advancements made in RxJava (and in Rsc): synchronous cancellation, backpressure or the Reactive-Streams design in general (not to mention, operator-fusion). (As a side-effect, implementing operators in .NET already revealed a few concurrency-related bugs in the Java implementation.)

Although tedious at times, I don't expect any interference on this regard and can focus on leading RxJava.