[META] Leave placeholders when RFCs are moved?

[jwosty]

RFCs have their file location in this repo moved as a part of their lifecycle, particularly when they're completed, being moved from RFCs/ to a folder corresponding to the F# version in question (for example FSharp-8.0/). Unfortunately this leaves dead links, not only here on GitHub, but other places on the internet which can prove harder to mend (for example, I sometimes encounter these on StackOverflow). While some of us may know where to find the moved RFC, it's not always so clear to new visitors to this repo.

Therefore, I think that from now on, whenever we move an RFC, we should put a placeholder document in its place with a link to the new location. A simple script could probably be written to do this retroactively for all past RFCs.

[vzarytovskii]

The downside would be that it will be harder to find correct one by number (and preview folder will be bloated with everything which was there at any point)

[brianrourkeboll]

In theory people could use permalinks that point at specific commits — e.g., https://github.com/fsharp/fslang-design/blob/924184d335fed7b38553ece91c774d0621d55fb5/RFCs/FS-1011-warn-on-recursive-without-tail-call.md) — but (1) that admittedly puts the burden of an extra few clicks on the linker for Markdown files, and (2) someone following a permalink may end up seeing an outdated version of the file without realizing that a newer version exists.

If only GitHub searched a repo's history for a path that didn't currently exist on the repo's main branch (and that would thus otherwise 404) and, if that path ever previously existed in the repo, redirected to a permalink to the last commit where it did... 🙃

[jwosty]

This is also true. Unfortunately there are already plenty of links out there that don't use that technique. I also go back and forth whether or not to use it exactly for the reason you described.

Personally, I feel that the cost of bloating the preview folder is worth the benefit of avoiding the creation of dead links.

Maybe some kind of separate branch could be maintained which just takes whatever is on main minus all files which are just redirects (using an automated script of course)? So that you can still have access to an uncluttered view on the repo?

What do other RFC repos do? Surely someone else has solved this same problem?

[vzarytovskii]

I personally don't mind leaving them with back links, it will require a bunch of work though, and remembering doing it.

Worst case scenario, we can always delete excessive files at any point.

[smoothdeveloper]

@vzarytovskii there should be inside pressure towards the "PM of github 404 implementation".

I'd tend to think people who end up on 404 but are interested in what is in the RFC would go to the extent of searching the repository, but the 404 being the way it has always been must be the main deterrent here.

Having a 404 which says "hey you looked for file X, it has been deleted or moved, here are files with similar names in current revision" would solve the problem for us and make github better.

[smoothdeveloper]

other thing is, there could be a github feature which is passed as url argument, which says "prompt if this file has newer revision" so when a permalink is created, it could optionally generate the link with that argument.

I can become "PM of github 404 implementation" if you like 🙂