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
{{ message }}
This repository has been archived by the owner on Dec 11, 2023. It is now read-only.
The existence of a queryable DiGraph (ProvDAG.dag) gives us the power to identify bugs (software, system, or user-originated) at the analysis level. Providing centralized infrastructure where developers can register known-buggy situations could help improve the reliability of QIIME 2 Results, and reduce both user and developer time spent diagnosing problems.
The text was updated successfully, but these errors were encountered:
It might be useful to think about bugs in terms of what scale of data we need to identify them.
A bug might be identifiable
without considering action.yaml data
from a single Action
from multiple Actions captured within a single Result
from multiple Results only.
The two middle points seem the most likely, and are probably the most valuable to prioritize in development. (e.g. should bug-checking occur while creating ProvNodes, or higher up, at the parser level). The final point is probably best addressed by querying the full ProvDAG once parsing is finished, which might render failures later than is convenient for users with large Result collections.
The existence of a queryable DiGraph (
ProvDAG.dag
) gives us the power to identify bugs (software, system, or user-originated) at the analysis level. Providing centralized infrastructure where developers can register known-buggy situations could help improve the reliability of QIIME 2 Results, and reduce both user and developer time spent diagnosing problems.The text was updated successfully, but these errors were encountered: