drym-org/dia

Resources for DIA

dia's Issues

Ability to cross reference analysis and appraisal files

Extracted from #2 (comment)

It would be nice to have scripts that could leverage the correspondence between analysis and appraisal data files to detect when changes have been made to any component of each line item, and output the differences.

E.g.

* [Name] A contribution was made

and

* [Name] A big contribution was made [23%]

... if they are in the same position in their respective files should be detected as a local modification of this kind (i.e. the verbiage of the contribution was modified here at the appraisal stage. But it could also be a change in the list of contributors). I think we should be able to do this since the corresponding files would have the same number of lines and the same contents (except with the addition of the allocation block in the appraisal file).

Update instructions on running scripts

Extracted from #2 (comment)

The README should be updated to include instructions on things like:

• how to structure a new repo for DIA for some project
• how to enter the appraisal data using the tree-structured syntax/language we decide on (#5 )
• how to anonymize/deanonymize data
• how to run the scripts to generate the attributions output

Precedent recommender system

In conducting DIA, using precedents is both expedient and also leads to more fairness and unity in the application of standards, as applying those precedents in new contexts can reveal fresh information and nuances or invalid assumptions in those precedents, and can thus lead to revision and fine-tuning of these precedents, with the improvements applying equally to all (even retroactively, via backpropagation). Therefore, it would be useful to be able to identify relevant precedents when appraising a new project to aid the DIA analyst.

For this purpose, we could create a dataset of projects together with metadata such as the ideas in their idea tree. Then, construct a structured database from this dataset (for instance, a graph database using something like Neo4j, with project nodes connected to idea nodes), and then provide a recommendation facility that allows us to find related projects. It could use a simple collaborative filtering algorithm, e.g. "for this project, given the ideas it entails, what other projects are the most similar in terms of exhibiting those ideas?"

I think this document should have examples

https://drym-org.github.io/dia/For_project_contributors.html

I might take a crack at it tomorrow, but I think this document needs code snippets examples of how that would work in the system. If I wanted to use this system, I think a toy example worked through would help me understand.

Add user documentation

In addition to the basic mechanics of setting things up and running various scripts that will be in the README, we also need general user documentation that describes the overall process of DIA, how to do it, any learnings from Qi DIA or other instances of DIA that haven't been captured elsewhere, etc. that will be useful to DIA participants and help us be more effective and efficient.

As a start, we should move the DIA.scrbl file here from the foundation repo, since this file describes a specific process that we are following to do DIA now. The general ideas and goals are already captured in the Attribution_Model document and that is more appropriate in the foundation repo.

Use `.dia` extension instead of `.md`

Make any changes to scripts to expect this extension, and also change the existing DIA repos to use the new extension.

Standardize data syntax and include contributors

Extracted from #2 (comment)

There are 4 entities that we'd like the data language syntax to capture explicitly:

• hierarchy/position in the tree
• contributor(s)
• contribution
• allocation

Of these, only contributors isn't already captured in the current syntax / scripts.

Incorporating a little more structure into the syntax could simplify parsing -- for instance, we could use:

  * [comma, separated, contributors] An anonymized contribution was done [allocation]

This would avoid excessive regex parsing to get contributors.

The [] allocation block at the end can be considered optional in the syntax so that we can leave it out at the analysis stage, instead of having an empty block at the end of every line.

Use the module languages in the source data files directly

Extracted from #2 (comment)

Currently the module languages use a pointer to the input data files via a specified path, and the tree-structured data is then parsed from these data files.

Instead, #lang abe/... could be in the source data file directly, and it could have a custom extension instead of .md. We could declare the generated identifiers (like capital-attributions) as part of the syntax of the module language.

Script to anonymize/deanonymize appraisal data

Extracted from #2 (comment)

Based on the proposed syntax change in #5 :

  * [comma, separated, contributors] An anonymized contribution was done [allocation]

... it would be great to have a CLI script to (1) anonymize and (2) deanonymize a provided input file that uses this syntax.

This could be done by just stripping/adding the contributors portion (note that we can't do this with the current syntax as we need to change from active voice to passive voice, etc.).