Rxjs: Making two PRs when submitting fixes to the docs

[dzhavat]

Documentation Related To Component:

All

Please check those that apply

• [ ] typo
• [ ] documentation doesn't exist
• [ ] documentation needs clarification
• [ ] error(s) in example
• [ ] needs example

Description Of The Issue

After the latest releases from a few days ago, I noticed that the small fixes many people have been making as PRs to the docs are not shown in the official docs.

The reason for this is because most PRs target master branch and master right now is against v7, which doesn't have online docs just yet. So when a new 6.x release is cut, the docs are updated but most small fixes are not there. :(

All of these small fixes will appear once the final v7 is released. But this is too late because people still open issues about missing images, descriptions, examples and so on, even though some of these things are already fixed in master.

So how do we reconcile this?

My suggestion is to encourage people to make two PRs - one against master and one against 6.x branch, whenever the changes are related to stuff like spelling mistakes, deleting a duplicated word, fixing an example, etc. By doing that, whenever a new v6 release is cut, the docs will be updated as well.

Another solution is to have a next version of the docs like Angular but that will probably require more work.

Any thoughts on this?

[dzhavat]

If this proposal gets "accepted", I can also go through the commits in master since the first v7-alpha release and transfer the changes related to the docs on the 6.x branch.

Does this sound as something we're interested in merging on the 6.x branch?

[kwonoj]

Proper approach to tackle this should be having apps like https://github.com/electron/trop installed to automate cherrypick / backport process instead of manual PRs.

[dzhavat]

That's cool! Didn't know about it. How realistic is it thought that this will be added to the repo? And if it's added, can it port the already made fixes to the docs over to the 6.x branch?

[DiedrikDM]

Once the PR is merged into master trop would need to have a manual trigger on the PR to activate, if I read that correctly. So porting the already made fixes is possible but would require some manual triggers.
I can have a look at how this could be done, if you want me to?

[dzhavat]

That's great @DiedrikDM Before we can start with it, we need to have someone from the core team who can confirm that this is indeed needed and are willing to merge the related work.

[niklas-wortmann]

I'm actually heavily against the proposal of creating two prs, for several reasons:

• bloats pr list in github
• requested changes need to be applied in both pr (depending on branching concept of pr author) and therefore the one requested the changes needs to keep track of the changes in both pre.
• Cherry picking right now is a viable option from my point of view

Small side note: the Angular approach is way too heavy for us and also uses additional infrastructure (right now inside google) that we don't have :sadface

[dzhavat]

Fair points. It would've been nice to have the docs up-to date. There have been a lot of great improvements over the past several months but users will see them once the next stable version is released.

I think it's very late now to make an effort to port all changes made on master to v6. There are too many.

So maybe we should discuss the this strategy again when v7 is released and we have a clean slate.