set-up RAM knowledge base + workflow

[aranas]

Provide a description

The idea is that we can keep track of past, present & future projects with (potential for) RAM involvement

Past projects (This issue will be concluded when an MVP of the databse is in place including the following features):

• [x] single csv file with info on each project
• [x] workflow that converts csv into slide deck for RAM output (using revealjs)
• [ ] workflow that converts csv into report for TPS

Present projects Use-case atm is unclear. Do we interact enough among RAMs to have a need for this?

Future projects this is where the shared db could intersect with the RAM impact framework. e.g. a project that is not taken up yet, its score according to RAM impact framework could be recorded and the project could be re-visited at a later point in time.

[harisood]

@aranas I'm starting to do some outreach to different projects to interview. I'm thinking we need some kind of tracker to keep on top of who's talked to who...wondering if this should be in this csv file - or do you think separate?

[aranas]

@aranas I'm starting to do some outreach to different projects to interview. I'm thinking we need some kind of tracker to keep on top of who's talked to who...wondering if this should be in this csv file - or do you think separate?

Yes I think it would make sense to have all in one place! I can add columns for the tracking. Let's talk which fields we would want for this:

• project name
• contact name
• broader turing context (maybe programme / GC?)
• RAM
• Date of contact
• Link to interview notes

anything else?

[aranas]

also: For TRIC-DT we are using lists on sharepoint for tracking interactions with projects and this works nicely, it has the benefit of a more user-friendly interface, compared to having to update the csv (though I guess this depends on your workflow). Some questions that would help me decide how to set this up:

Are RAMs using / do you want to use sharepoint actively at all? Do you see a clear path to integrate a csv file format into your current workflow? Essentially I see two options, both having pros&cons.

1) Having the database on sharepoint means you update in the GUI and don't need to follow with a git add-commit-push cycle. But it would require us to then regularly go in and fetch the data from sharepoint to integrate with the csv-to-slides github workflow. 2) Database lives direclty on our github as csv file, but people might adapt a bit to interact with it.

[harisood]

anything else?

Maybe just an additional notes column but otherwise all g!

[harisood]

My take is we don't really use the SharePoint, and should probs avoid the 'syncing-in-multiple-places' issue. MB keep to GH and treat it as RAM upskilling to learn how to effectively update csv files?

[aldenc]

closing - removed from roadmap