CITCOM-project / CITCOM-project/CausalTestingFramework
Do we need the `Scenario` or `Variable` classes anymore?
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 20
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Description
The Variable classes (Input, Output, Meta) were made to support test data generation (i.e. to generate inputs for the system), but this never really came to fruition. Since then, they've just hung around without providing much functionality. We could probably just use string names now, since we never differentiate between the different variable types. If we ever did want to provide different functionality based on variable type (e.g. input and output), then this could be recorded as metadata in the causal DAG (both in the DOT file representation and in the CausalDAG class).
The Scenario class was made to hold the Variables and the "modelling scenario": a query on the data, e.g. "location = UK". While I do think it's important to keep the query functionality at both the DAG level (so the user doesn't have to pre-filter their data) and the edge level (to allow for low-effort adjustment of categorical variables), I think we can manage this more easily through the new improved CausalTestingFramework class.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace usages of the Scenario, Variable, Input, Output, and Meta classes, then inspect CausalDAG, its DOT representation, and CausalTestingFramework to understand how queries and variable names currently flow through the framework. Done means the obsolete abstractions are removed or consolidated without losing DAG-level and edge-level query functionality, with affected tests updated accordingly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- testing-qa
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100