Open wbwakeman opened 5 years ago
@wbwakeman this is a good idea. I can implement a decorator (something like @prerelease) that will indicate api functionality that is not guaranteed to be stable forever, but is available to to early users. Using this decorator would then divide the API into functionality that will "just work" vs opt-in satisfying our two user cases. Does this sound OK? (CC @NileGraddis )
@mabuice I recall you bringing this issue up during the SDKathon as well. Does this sound like a good idea?
Yes, that sounds like a sensible way to address this. I think how we address this should also address issues 629 and 630.
We might classify BehaviorOphysSession api users as "early" and "final". An example of a "final" user might be an external user that will only be accessing data from complete containers that has competed cell matching, been QC'ed and is valid. An "early" user might be Allen Institute analysts that are QC'ing data from recent experiments. This data has not been matched to other experiments.
The default analysis should "just work" for the external group. The "early" users may be required to do something extra to "opt-in" to access data or functionality that is not uncovered by default.