m-mohr
commented
2 years ago I can see why this seems like a good idea from the implementation/service perspective in a federated platform. On the other hand, I'm not sure users would understand the differences. Actually, I'm not really sure either. Or is this meant to be only to be used by the aggregator? Also, would back-ends use them consistently? Only then this would be useful.
The question is whether there's enough benefit to add another flag to split into 3 or 4 categories while there is already the experimental flag? Experimental could be good enough from the user perspective to show a "warning" and then you can always add a more fine-grained classification already: either through the categories/keywords (for machines) and/or through the description (for users).
jdries
As a backend, we often want to publish processes and collections to our production endpoints, even if they are very immature. (For instance, if a beta user wants this, or simply if it's included in a software version that also carries more stable updates, or a project milestone demands it.)
On the user side, we also see users that are looking for an operational service (the default), whereas others like or have to experiment with things.
If backends advertise a maturity level, the aggregator can expose endpoints that filter on such a specific level. When the same collection is available on multiple backends, but one of them is marked as immature, it might also prefer the mature one.
There's currently an 'experimental' flag, but perhaps we need more categories? (Like 3 to 4?)
Proposal: prototype - incubating - integration - mature