Establish proposal procedure

[m-mohr]

With new processes coming in, it's sometimes not easy to decide whether to make them core and release them as part of the "stable contract" or not. Currently an example is #192, which seems like a useful process, but alternatives are also discussed. Nevertheless, an openEO partner wants such a process and thus it's good to give implementers a broader choice for use cases, which they can built on as this leads to less dispersion. Also, the process should be implemented first, so that we can make changes if required and then afterwards we could push into core. Surely, these processes should all make clear by "experimental: true" that changes may occur.

Anyway, long story short: We should make a folder or branch for proposals or experimental processes that are in development and have some procedures around it. Do you agree?

[mkadunc]

Agree.

I think a separate folder without branching is the more efficient option, because it raises usability of the experimental features and encourages everyone to work towards developing them into 'production' processes.

[m-mohr]

I'm now working on a proposals folder in the normal branch structure, so in GitHub the proposals are separate. They will be shown on processes.openeo.org though. The tests will check proposals are flagged as experimental and all other processes are not experimental. Thus the proposals will have a larger warning flag on processes.openeo.org that they are experimental.

Guideline will be that processes will go core with at least two implementing orgranizations, otherwise to proposals. This will not apply for processes in core that may have not been implemented by two organizations yet.

[m-mohr]

Done