Doc: add a page describing the RFC process step by step

[rouault]

CC @dbaston @elpaso

[elpaso]

Looks good to me, it clarifies that a candidate implementation is not required before the call for adoption.
That was my main concern about the current process: I find it risky that a candidate implementation must be provided along with the RFC submission: if the RFC is not approved or if the approved implementation is too far from the candidate implementation it can result in a huge waste of development time.
Of course when a RFC is submitted one should have a clear idea about the API changes and about the technical solutions but that can be presented as headers/classes or method signatures and pseudo-code instead of a working (buildable) implementation.

[rouault]

Looks good to me, it clarifies that a candidate implementation is not required before the call for adoption.

hum, not required, but personally, I could be "-0" if I don't see the code for something where I've doubts that the idea might be implemented or that we might have missed "details" that make it impractical. The interesting phase is the call for discussion. This is the point where the submitter should feel if it is worth investing time in making an implementation or not.

[elpaso]

Looks good to me, it clarifies that a candidate implementation is not required before the call for adoption.

hum, not required, but personally, I could be "-0" if I don't see the code for something where I've doubts that the idea might be implemented or that we might have missed "details" that make it impractical. The interesting phase is the call for discussion. This is the point where the submitter should feel if it is worth investing time in making an implementation or not.

Maybe we are just not understanding each other but we are saying the same thing: I think that during the discussion phase it should not be required that a working candidate implementation (working = C++ code that builds) is provided. Instead, it might be useful to see proposed API changes/additions in the form of class/methods/functions signatures and/or algorithms as pseudo-code.