Add list of implemented processes and their status

[clausmichele]

How could we keep track of the currently implemented openEO processes of this project? It would be nice to know:

• What is implemented and fully working
• What is implemented but still lacking some functionalities
• What is under development
• What is planned to be implemented soon

In this way it would be much easier to contribute.

[LukeWeidenwalker]

What is implemented and fully working

This hasn't always been the case in this project, but once #40 and #50 are fully reviewed and merged, the main branch should only ever contain processes that are sufficiently tested to be described as "fully working".

What is implemented but still lacking some functionalities

I've been using a mix of github issues and TODO comments in the code to indicate such situations. Semantics being roughly:

• Github issue: "This is a problem and we'll definitely look into this as and when we have time"
• TODO comment: "This is something that could be done here, but no commitment to actually doing it"
  There's also the experimental folder in the code, this is also an attempt at communicating the maturity of the processes in there.

Rather than cataloging and documenting missing features in general, I'd prefer we simply open these as github issues as we find them (like you did with #27)! The expectation should be that every process that we have in the main branch is either fully functional or that there exists an issue describing what is missing/not working + there are appropriate warnings being logged in the code to clearly communicate this at runtime. I don't really want to manually maintain a big list of which processes are at what maturity, as I expect that to become outdated quite easily.

What is under development
What is planned to be implemented soon

Right now is kind of a special situation because we're working towards implementing the core profile of processes. We're already tracking this work in our internal JIRA, so I didn't want to spend the time to create extra Github issues for all of these, but I do agree that it would be useful to have at least some github issue representation of what's being worked on. Will add those for all the efforts that are currently ongoing. Once I've done that and if there's not already an issue/PR for something, it's fairly safe to assume that no one is working on it. In which case contributors can just create the issue and assign themselves.

Are there any processes in particular that you'd be interested in contributing atm?

Let me know if this helps!

[clausmichele]

Thanks for the complete reply Lukas. I also agree that having a simple list is not ideal but I wanted to discuss about different possibilities and approaches.

It's also fine for me to handle through GitHub issues the problems related to specific processes.

Anyway, I am quite open to possible contributions. Recently I noticed that the filter_spatial, filter_bbox and filter_temporal processes are missing and I wanted to know if I could go on with a PR or wait, if there's already something in progress.
So, it would be really nice if you could add to GitHub your internal JIRA issues, which would allow me to decide what do do!

[LukeWeidenwalker]

Added the missing issues and assigned those that we're currently working on - #75 is the one for filtering, happy to review when you have something! :)