You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dropping in a copy of our request (originally posted on Slack on September 27th):
Hi @timfrazee! A belated follow-up, but we wanted to thank you for the demo and walkthrough of your testing development work. We really appreciated seeing how you’ve been thoughtfully approaching the Rikolti data testing architecture.
We’re very excited about the fixture generation approach you’ve designed! We believe this will be really valuable for Rikolti and would appreciate it if you are able to prioritize development time on this work. One thing we’d like to note is that the mapper testing suite will likely require more fixture generator subclasses than you may anticipate, due to the number of data sources (CCA Vault, Islandora, ContentDM, etc) and the range of data shape attributed to each of those data sources.
As an approach to navigate the complexity, we’d like to propose building out fixture generators to specify three concrete data shapes starting with content_dm, and progressing on to csudh, and finally cca_vault in order to test the oai.content_dm mapper, the oai.content_dm.csudh mapper (or other interesting content_dm subclass), and the oai.cca_vault mapper (or other interesting OAI-based shape not found within the content_dm branch of mappers). This proposed approach should serve as a good starting point into working with a variety of data shapes. Please feel free to let us know if you have any questions about this.
Thank you also for your overview of the validator validator. While we appreciate the potential utility of this, we don’t see this as an immediate priority for our Rikolti development work and would like you to stop development work on this. We would like to make sure you are able to focus your Rikolti time on the fixture generation approach you demonstrated.
Next steps: As Amy requested Monday, would you be able to split the fixture generation work into a separate branch?
Proposed timeline: We’re curious if you might be able to complete work on the ContentDM fixture generator such that the codebase is ready to run tests against the ContentDM mapper by the end of next week (Oct 6).
Thanks so much, and please feel free to reach out if you have any questions!
The text was updated successfully, but these errors were encountered:
Dropping in a copy of our request (originally posted on Slack on September 27th):
Hi @timfrazee! A belated follow-up, but we wanted to thank you for the demo and walkthrough of your testing development work. We really appreciated seeing how you’ve been thoughtfully approaching the Rikolti data testing architecture.
We’re very excited about the fixture generation approach you’ve designed! We believe this will be really valuable for Rikolti and would appreciate it if you are able to prioritize development time on this work. One thing we’d like to note is that the mapper testing suite will likely require more fixture generator subclasses than you may anticipate, due to the number of data sources (
CCA Vault
,Islandora
,ContentDM
, etc) and the range of data shape attributed to each of those data sources.As an approach to navigate the complexity, we’d like to propose building out fixture generators to specify three concrete data shapes starting with
content_dm
, and progressing on tocsudh
, and finallycca_vault
in order to test theoai.content_dm
mapper, theoai.content_dm.csudh
mapper (or other interestingcontent_dm
subclass), and theoai.cca_vault mapper
(or other interesting OAI-based shape not found within the content_dm branch of mappers). This proposed approach should serve as a good starting point into working with a variety of data shapes. Please feel free to let us know if you have any questions about this.Thank you also for your overview of the validator validator. While we appreciate the potential utility of this, we don’t see this as an immediate priority for our Rikolti development work and would like you to stop development work on this. We would like to make sure you are able to focus your Rikolti time on the fixture generation approach you demonstrated.
Next steps: As Amy requested Monday, would you be able to split the fixture generation work into a separate branch?
Proposed timeline: We’re curious if you might be able to complete work on the ContentDM fixture generator such that the codebase is ready to run tests against the ContentDM mapper by the end of next week (Oct 6).
Thanks so much, and please feel free to reach out if you have any questions!
The text was updated successfully, but these errors were encountered: