├── .all-contributorsrc ├── .github ├── ISSUE_TEMPLATE │ ├── ISSUE_TEMPLATE.md │ ├── issue_template.yml │ ├── onboarding.md │ └── project-ram-discussion.yml └── workflows │ └── add_issue_to_project.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── new_starter_onboarding ├── communities_to_join.md ├── objectives_setting.md └── sessions │ ├── 1_day_one_checklist.md │ ├── 2_ram_life.md │ ├── 3_people_and_teams.md │ └── 4_github.md └── resources ├── case_studies ├── asg │ ├── 1-pagers │ │ ├── Equadratures.pdf │ │ ├── Fleet Monitoring v3_compressed.pdf │ │ └── VoD.pdf │ ├── ab-street.md │ ├── dt-fleets.md │ ├── energyflex.md │ └── value_of_data.md ├── case_study_template.md └── glossy_template.md ├── discussions └── participatory and public engagement techniques.md ├── events └── event_checklist.md ├── innovation └── spinout_resources.md ├── pitchfest ├── comms-templates.md ├── index.md └── pitchfest-2023.md ├── project_ram ├── RAM_1pager.md ├── framework │ ├── ram-rhombus-0.1.svg │ ├── ram-rhombus-0.2.svg │ └── ram-rhombus-0.3.svg ├── interviews │ ├── index.md │ ├── interview_notes.md │ └── interview_template.md └── project_impact_metrics.md ├── stakeholder_workshops ├── requirements_gathering.md └── stakeholder_workshops.md ├── team_strategy ├── facilitator_notes.md ├── index.md └── strategy_case_studies │ └── index.md └── training_materials └── mkdocs_workshop_recap.md /.all-contributorsrc: -------------------------------------------------------------------------------- 1 | { 2 | "files": [ 3 | "README.md" 4 | ], 5 | "imageSize": 100, 6 | "commit": false, 7 | "contributors": [ 8 | { 9 | "login": "malvikasharan", 10 | "name": "Malvika Sharan", 11 | "avatar_url": "https://avatars.githubusercontent.com/u/5370471?v=4", 12 | "profile": "http://malvikasharan.github.io/", 13 | "contributions": [ 14 | "ideas", 15 | "content" 16 | ] 17 | }, 18 | { 19 | "login": "EKaroune", 20 | "name": "Emma Karoune", 21 | "avatar_url": "https://avatars.githubusercontent.com/u/58147174?v=4", 22 | "profile": "https://github.com/EKaroune", 23 | "contributions": [ 24 | "ideas", 25 | "doc" 26 | ] 27 | }, 28 | { 29 | "login": "aleesteele", 30 | "name": "Anne Lee Steele", 31 | "avatar_url": "https://avatars.githubusercontent.com/u/18509789?v=4", 32 | "profile": "http://www.aleesteele.com", 33 | "contributions": [ 34 | "ideas", 35 | "doc" 36 | ] 37 | }, 38 | { 39 | "login": "vhellon", 40 | "name": "Vicky Hellon", 41 | "avatar_url": "https://avatars.githubusercontent.com/u/93144591?v=4", 42 | "profile": "https://github.com/vhellon", 43 | "contributions": [ 44 | "ideas", 45 | "doc" 46 | ] 47 | }, 48 | { 49 | "login": "dingaaling", 50 | "name": "Jennifer Ding", 51 | "avatar_url": "https://avatars.githubusercontent.com/u/5104098?v=4", 52 | "profile": "http://jending.com", 53 | "contributions": [ 54 | "content", 55 | "doc", 56 | "ideas" 57 | ] 58 | } 59 | ], 60 | "contributorsPerLine": 7, 61 | "projectName": "reproducible-project-template", 62 | "projectOwner": "alan-turing-institute", 63 | "repoType": "github", 64 | "repoHost": "https://github.com", 65 | "skipCi": true 66 | } 67 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\u2728 General" 3 | about: Have an idea for the project? 4 | title: 5 | labels: 6 | assignees: '' 7 | 8 | --- 9 | 10 | 13 | ### Summary 14 | 15 | * [Replace this sentence with a description of the change or addition you are proposing or the question you're asking. Please provide as much context as possible and link to related issues and/or pull requests] 16 | 17 | ### What needs to be done? 18 | 19 | 20 | 21 | - [ ] Task-1 22 | - [ ] Task-2 23 | - [ ] ... 24 | 25 | 26 | ### Who can help? 27 | 28 | * [List skills required to complete tasks under this issue] 29 | * [Tag people with @username if you know someone who can help] 30 | 31 | --- 32 | 33 | ### Updates 34 | 35 | * [Replace this sentence to provide a status summary after the issue has been opened. To avoid others from reading through the full thread of comments, please share updates (e.g. decisions taken) regularly.] 36 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/issue_template.yml: -------------------------------------------------------------------------------- 1 | name: "Add task to project board" 2 | description: Add an issue to the public RAM repo 3 | title: "New issue" 4 | labels: [add_to_project] 5 | body: 6 | - type: markdown 7 | attributes: 8 | value: | 9 | Use this form to submit an issue to the RAM repo that will appear as a task on the project board. Create an issue any time you wish to add a new file to the repo or make major changes. 10 | - type: textarea 11 | id: description 12 | attributes: 13 | label: Provide a description 14 | description: What are you adding/changing and why? 15 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/onboarding.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Onboarding" 3 | about: An issue to track onboarding of a new RAM team member 4 | title: 5 | labels: [onboarding] 6 | assignees: '' 7 | 8 | --- 9 | 10 | # [INSERT NAME] Onboarding 11 | 12 | - **Start date**: 13 | - **RAM 'buddy'**: 14 | - **RAM projects/programmes**: 15 | 16 | Welcome to the RAM Team, [insert name] 💚 17 | Please use this issue to keep track of your onboarding tasks. 18 | Once everything's been done, you can close this issue and dive fully into everything RAM 🏊‍♀️ 19 | 20 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/project-ram-discussion.yml: -------------------------------------------------------------------------------- 1 | name: Project RAM Discussion 2 | description: Start a discussion about project RAM. 3 | title: "[Discussion]: " 4 | labels: ["project ram"] 5 | body: 6 | - type: markdown 7 | attributes: 8 | value: | 9 | This issue is for starting a discussion about Project RAM. 10 | 11 | It could include discussing changing the framework, changing our interview process and content, or something else! 12 | - type: input 13 | id: summary 14 | attributes: 15 | label: Summary 16 | description: Please write a brief summary of the point you would like to discuss. 17 | validations: 18 | required: true 19 | - type: textarea 20 | id: detail 21 | attributes: 22 | label: Detail 23 | description: Please explain the point you would like to discuss. Feel free to include references that may be useful. 24 | validations: 25 | required: true 26 | - type: textarea 27 | id: output 28 | attributes: 29 | label: Intended Output 30 | description: What do you hope will happen as a result of this discussion? 31 | validations: 32 | required: false 33 | - type: textarea 34 | id: tags 35 | attributes: 36 | label: Who can help 37 | description: Tag anyone who you think will be interested or who can help by typing `@` followed by their GitHub username. 38 | validations: 39 | required: false -------------------------------------------------------------------------------- /.github/workflows/add_issue_to_project.yml: -------------------------------------------------------------------------------- 1 | name: Add new issues to project board 2 | 3 | on: 4 | issues: 5 | types: 6 | - opened 7 | 8 | jobs: 9 | add-to-project: 10 | name: Add issue to project 11 | runs-on: ubuntu-latest 12 | steps: 13 | - uses: actions/add-to-project@v0.3.0 14 | with: 15 | project-url: https://github.com/orgs/alan-turing-institute/projects/38/ 16 | github-token: ${{ secrets.PAT_for_project }} 17 | labeled: add_to_project 18 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # 2 | 3 | # Byte-compiled / optimized / DLL files 4 | __pycache__/ 5 | *.py[cod] 6 | *$py.class 7 | 8 | *.DS_Store* 9 | 10 | # C extensions 11 | *.so 12 | 13 | # Distribution / packaging 14 | .Python 15 | build/ 16 | develop-eggs/ 17 | dist/ 18 | downloads/ 19 | eggs/ 20 | .eggs/ 21 | lib/ 22 | lib64/ 23 | parts/ 24 | sdist/ 25 | var/ 26 | wheels/ 27 | pip-wheel-metadata/ 28 | share/python-wheels/ 29 | *.egg-info/ 30 | .installed.cfg 31 | *.egg 32 | MANIFEST 33 | 34 | # PyInstaller 35 | # Usually these files are written by a python script from a template 36 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 37 | *.manifest 38 | *.spec 39 | 40 | # Installer logs 41 | pip-log.txt 42 | pip-delete-this-directory.txt 43 | 44 | # Unit test / coverage reports 45 | htmlcov/ 46 | .tox/ 47 | .nox/ 48 | .coverage 49 | .coverage.* 50 | .cache 51 | nosetests.xml 52 | coverage.xml 53 | *.cover 54 | *.py,cover 55 | .hypothesis/ 56 | .pytest_cache/ 57 | 58 | # Translations 59 | *.mo 60 | *.pot 61 | 62 | # Django stuff: 63 | *.log 64 | local_settings.py 65 | db.sqlite3 66 | db.sqlite3-journal 67 | 68 | # Flask stuff: 69 | instance/ 70 | .webassets-cache 71 | 72 | # Scrapy stuff: 73 | .scrapy 74 | 75 | # Sphinx documentation 76 | docs/_build/ 77 | 78 | # PyBuilder 79 | target/ 80 | 81 | # Jupyter Notebook 82 | .ipynb_checkpoints 83 | 84 | # IPython 85 | profile_default/ 86 | ipython_config.py 87 | 88 | # pyenv 89 | .python-version 90 | 91 | # pipenv 92 | # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. 93 | # However, in case of collaboration, if having platform-specific dependencies or dependencies 94 | # having no cross-platform support, pipenv may install dependencies that don't work, or not 95 | # install all needed dependencies. 96 | #Pipfile.lock 97 | 98 | # PEP 582; used by e.g. github.com/David-OConnor/pyflow 99 | __pypackages__/ 100 | 101 | # Celery stuff 102 | celerybeat-schedule 103 | celerybeat.pid 104 | 105 | # SageMath parsed files 106 | *.sage.py 107 | 108 | # Environments 109 | .env 110 | .venv 111 | env/ 112 | venv/ 113 | ENV/ 114 | env.bak/ 115 | venv.bak/ 116 | 117 | # Spyder project settings 118 | .spyderproject 119 | .spyproject 120 | 121 | # Rope project settings 122 | .ropeproject 123 | 124 | # mkdocs documentation 125 | /site 126 | 127 | # mypy 128 | .mypy_cache/ 129 | .dmypy.json 130 | dmypy.json 131 | 132 | # Pyre type checker 133 | .pyre/ 134 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | > Code of Conduct, commonly abbreviated as “CoC”, is a set of rules outlining the social norms, rules, & responsibilities of an individual project, party or organization. 4 | 5 | This Code of Conduct document outlines our expectations for 6 | participants within the team as well as this online repository (project). 7 | We also provide steps to reporting any concern, uncomfortable situation 8 | or unacceptable behaviour by other participants. 9 | We are committed to providing a welcoming, collaborative and inspiring experience 10 | for all and expect our code of conduct to be honoured. 11 | 12 | 13 | The Code of Conduct used in this document is selected from the options provided by GitHub that reuses Contributor Covenant's version (add a new file -> name that `CODE_OF_CONDUCT.md` -> click on 'Choose a code of conduct template' -> select from the options that best suits the requirements in your project). 14 | image 15 | 16 | We have further adopted the language and content that reflects our values and needs in the project. 17 | To learn more about why we recommend creating a CODE_OF_CONDUCT.md file, please read the [Participation Guidelines](https://the-turing-way.netlify.app/project-design/project-repo/project-repo-participation.html) chapter in *The Turing Way* Guide for Project Design. 18 | It is recommended to select and adapt a well established Code of Conduct. Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your project. 19 | *The Turing Way* [Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/main/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further. 20 | 21 | 22 | ## Our Pledge 23 | 24 | We as members, contributors, and leaders pledge to make participation in our 25 | community a harassment-free experience for everyone, regardless of age, body 26 | size, visible or invisible disability, ethnicity, sex characteristics, gender 27 | identity and expression, level of experience, education, socio-economic status, 28 | nationality, personal appearance, race, religion, or sexual identity 29 | and orientation. 30 | 31 | We pledge to act and interact in ways that contribute to an open, welcoming, 32 | diverse, inclusive, and healthy community. 33 | 34 | ### Diversity Statement 35 | 36 | We encourage everyone to participate and are committed to building a project 37 | for all. Although we will fail at times, we seek to treat everyone both as 38 | fairly and equally as possible. Whenever a member has made a mistake, we 39 | expect them to take responsibility for it. If someone has been harmed or 40 | offended, it is our responsibility to listen carefully and respectfully, and do 41 | our best to right the wrong. 42 | 43 | Although this list cannot be exhaustive, we explicitly honour diversity in age, 44 | gender, gender identity or expression, culture, ethnicity, language, national 45 | origin, political beliefs, profession, race, religion, sexual orientation, 46 | socioeconomic status, and technical ability. We will not tolerate discrimination 47 | based on any of the protected characteristics above, including participants with 48 | disabilities. 49 | 50 | ## Our Standards 51 | 52 | Examples of behaviour that contributes to a positive environment for our 53 | community include: 54 | 55 | * Demonstrating empathy and kindness toward other people 56 | * Being respectful of differing opinions, viewpoints, and experiences 57 | * Giving and gracefully accepting constructive feedback 58 | * Accepting responsibility and apologizing to those affected by our mistakes, 59 | and learning from the experience 60 | * Focusing on what is best not just for us as individuals, but for the 61 | overall community 62 | 63 | Examples of unacceptable behaviour include: 64 | 65 | * Trolling, insulting or derogatory comments, and personal or political attacks 66 | * Public or private harassment 67 | * Publishing others' private information, such as a physical or email 68 | address, without their explicit permission 69 | * Other conduct which could reasonably be considered inappropriate in a 70 | professional setting 71 | * The use of sexualised language or imagery, and sexual attention or 72 | advances of any kind 73 | 74 | ## Scope 75 | 76 | This Code of Conduct applies to all members participating in the activities, 77 | events and processes taking place within the **Open Research Community Building Team**. 78 | Specifically, our Code of Conduct applies to any conduct: 79 | - in interactions within the team/community 80 | - at any team activity, communication or event 81 | - outside the team activity when a team member is representing projects associated with the team 82 | - by members outside the team engaging on the Open Community Building GitHub repository. 83 | 84 | This Code of Conduct also applies when 85 | an individual is officially representing the community in public spaces. 86 | Examples of representing our community include using an official e-mail address, 87 | posting via an official social media account, or acting as an appointed 88 | a representative at an online or offline event. 89 | 90 | ## Enforcement 91 | 92 | Instances of harassing, abusive, or otherwise unacceptable behaviour should be 93 | reported to the community leaders responsible for enforcement. 94 | 95 | All reports will be reviewed and investigated promptly and fairly. 96 | 97 | All community leaders are obligated to respect the privacy and security of the 98 | reporter of any incident. 99 | Together we strive to foster an environment where everyone feels valued, respected, and included. 100 | 101 | 102 | Community leaders are responsible for clarifying and enforcing our standards of 103 | acceptable behaviour and will take appropriate and fair corrective, restorative and 104 | action in response to any behaviour that they deem inappropriate, threatening, offensive, 105 | or harmful. 106 | 107 | ### Enforcement Responsibilities 108 | 109 | Community leaders have the right and responsibility to remove, edit, or reject 110 | comments, commits, code, wiki edits, issues, and other contributions that are 111 | not aligned to this Code of Conduct, and will communicate reasons for moderation 112 | decisions when appropriate. 113 | 114 | ## Reporting Incident 115 | 116 | If you experience or witness unacceptable behaviour, or have any other concerns, please report it 117 | by contacting one of the team leads: Aida Mehonic, Alden Conner, or Jennifer Ding. They may involve 118 | the Tools, Practices and Systems Programme Director, Kirstie Whitaker when incidents are perceived 119 | as difficult (not straightforward) except when any potential conflict of interest may arise. 120 | 121 | To report an issue involving the team lead, please email directly to the Tools, Practices and Systems 122 | Programme Director, Kirstie Whitaker (email: kwhitaker@turing.ac.uk). 123 | 124 | In your report please include: 125 | 126 | - Your contact information. 127 | 128 | - Names (real, nicknames, or pseudonyms) of any individuals involved. If there 129 | are additional witnesses, please include them as well. Your account of what 130 | occurred, and if you believe the incident is ongoing. If there is a publicly 131 | available record (e.g. a mailing list archive or a public IRC logger), please 132 | include a link. 133 | 134 | - Any additional information that may be helpful. 135 | 136 | We will respect confidentiality requests all the time for the purpose of protecting individuals who have been harmed. 137 | 138 | ### Terminology 139 | 140 | * Reporter: Person reporting an incident. 141 | * Reportee: Person being reported. 142 | 143 | ## Report Handling Process 144 | 145 | After receiving a report, the community leaders (or person handling the report), team lead or programme director in this case, will review the incident report and follow this process to determine the cause and consequences that violated this Code of Conduct and take further actions: 146 | 147 | Community leaders will reach out to the reporter to ask for further information if the submitted report is not complete or needs some additional context. 148 | Community leaders will also ensure that person impacted or harmed by the reported incident is safe and identify how they can be further supported. 149 | 150 | A meeting with the reportee will be scheduled where the person handling the report will discuss four questions: 151 | - What happened? 152 | - What were you thinking at the time? 153 | - Who has been affected by what you have done? In what way? 154 | - What do you think you need to do to make things right? 155 | 156 | When the incident in question inflicted harm on another person, additional 157 | questions will be asked on behalf of the person(s) harmed: 158 | - What did you think when you realized what had happened? 159 | - What impact has this incident had on you and others? 160 | - What do you think needs to happen to make things right? 161 | 162 | The person handling the report may follow up with reportee or reporter after this discussion 163 | with any additional questions to help them reach a resolution. 164 | 165 | ### Resolutions 166 | 167 | Here are examples of possible resolutions to a report. 168 | This list is not comprehensive, and any action necessary to reach a fair resolution will be taken as needed. 169 | Possible resolutions to an incident include: 170 | 171 | - a private communication from community leaders, providing 172 | clarity around the nature of the violation and an explanation of why the 173 | behaviour was inappropriate. 174 | - an apology to the person harmed or the team as a whole 175 | - an action plan for the reportee to improve their awareness and correct future behaviours 176 | - if confirmed by the person reporting, reportee will have no interaction with the people involved, including unsolicited interaction with 177 | those enforcing the Code of Conduct, for a specified period. This includes avoiding interactions in community spaces as well as external channels like social media. 178 | - not publishing the content that violated the Code of Conduct, until necessary changes have been made and agreed upon by the person handling the report. 179 | - An imposed suspension, such as asking reportee to “take a week off” from the GitHub repo or team activity. 180 | - a stronger warning with consequences for continued behaviour. 181 | 182 | The person handling the report will maintain records of all reports so that they may be reviewed if stronger measures are required when repeated violations occur by the same individual as well as to improve our Code of Conduct for future participation. 183 | 184 | Once a resolution is agreed upon, but before it is enacted, the person handling the report will contact the reporter and any other affected parties to explain the proposed resolution. 185 | They will ask if this resolution is acceptable and must note feedback for the record. However, they are not required to act on this feedback. 186 | 187 | The reportee will be contacted via email informing them of the resolution. 188 | A final meeting may be conducted if necessary. 189 | 190 | ### Conflict of Interest 191 | 192 | All reports will be kept confidential with details shared only with people involved in report handling. 193 | If a person handling the report (team lead or programme director) is linked with the ongoing issue, they will declare their Conflict of Interest and remove themselves from any discussion related to the report handling. 194 | Resolution action may also include identifying appropriate members from within the Open Research Community Building Team if more support for the person handling the report is needed. 195 | 196 | ## Attribution 197 | 198 | This code of conduct is based on the Open Code of Conduct from the [TODO Group](https://github.com/todogroup/opencodeofconduct/), [The Carpentries Code of Conduct](https://docs.carpentries.org/topic_folders/policies/index_coc.html) and [Contributor Covenant 199 | version 2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct.html). 200 | 201 | The report handling process has been derived from the Eastern University 202 | Academic Charter School (EUACS) Student Restorative Justice based Code of Conduct derived from the work of Ted Wachtel 203 | at International Institute for Restorative Practices (IIRP). 204 | Restorative Practice Principles are based on Amstutz and Mullet (2005). Restorative Discipline for Schools, pp. 25-26. 205 | 206 | Community Impact Guidelines are inspired by [Mozilla's code of conduct 207 | enforcement ladder](https://github.com/mozilla/diversity). 208 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to contribute? 2 | 3 | Thank you for taking the time to contribute to this project. 🎉 4 | 5 | 6 | 7 | When reusing this repository please replace the content highlighted in bold with the information that best represents your project. 8 | As a template, this repository can be directly copied to start a new project with standard files and processes required in any collaborative data science and research project. 9 | Although we also use open research practices by sharing this repository public for further reuse in different projects, users can select the appropriate license and access levels for their collaborators. 10 | 11 | To learn more about why we recommend creating a `CONTRIBUTING.md` file, please read the [Contributors and Communication Pathways chapter](https://the-turing-way.netlify.app/project-design/project-repo/project-repo-contributors.html) in *The Turing Way* Guide for Project Design. 12 | 13 | 14 | 15 | The **Reproducible Project Template** repository is developed under ***[The Turing Way](https://github.com/alan-turing-institute/the-turing-way)* to demonstrate the practical integration of reproducibility practices on the collaborative or shared online repository**. 16 | 17 | This project is being developed **openly** and invites contributions from **anyone interested** in reproducible data science who would like to get involved. 18 | You can suggest topics to include in this repository, report mistakes/bugs, create Pull Requests to fix an error, offer resources or help develop or review the training materials. 19 | 20 | We have a [Code of Conduct](./CODE_OF_CONDUCT.md) that applies to all the activities related to this project. 21 | 22 | ⭐️ You are acknowledged for all kinds of contributions 23 | --- 24 | 25 | In this repository, we use the [All Contributors Bot](https://allcontributors.org/) that help us recognise all contributors, even when they don't directly contribute on the repository. 26 | You can find all [emoji/Type keywords](https://allcontributors.org/docs/en/emoji-key) representing the types of contribution. 27 | 28 | To add a contributor, comment on Issue or Pull Request (where the contributor is involved) using this message for @all-contributors: 29 | `@all-contributors please add @ for ` 30 | 31 | ## Whatever is your availability, there is a way to contribute to this GitHub repository. 32 | 33 | 👋 I'm busy, I only have 5 minute 34 | --- 35 | 36 | Look through our currently open [issues](../../issues) to troubleshoot an issue or participate in an ongoing discussion by commenting. 37 | You can also share this repository with someone who might be interested to get involved. 38 | 39 | ⏳ I've got 15 minutes - tell me what I should do 40 | --- 41 | 42 | You can read our [README](./README.md) file to find details and the next milestones in the project. 43 | You can also read different issues in this repository and comment where you would like to be involved. 44 | 45 | 🎉 It's my life's mission to enable reproducibility in data science and research 46 | --- 47 | 48 | Please share feedback on the contents proposed for setting up an online collaborative repository for data science and research. 49 | You are encouraged to review the material as we collaboratively develop them and get involved where you can. 50 | Please open a GitHub issue to suggest a new topic, contribute code, or let us know about errors/bugs. 51 | 52 | 🛠 I am ready to contribute 53 | --- 54 | 55 | - For open tasks in this repository, please see the [Issues section](../../issues). 56 | - Raise mistakes, errors or missing information on this repository by opening a [Pull Request](../../pulls) 57 | - Read details on [how to open a Pull Request](https://opensource.guide/how-to-contribute/#opening-a-pull-request) 58 | - Submit trivial fixes (for example, a typo, a broken link or an obvious error) 59 | - Start work on a contribution that is already listed as an issue or something you’ve already discussed 60 | - A Pull Request doesn’t have to represent finished work. It’s usually better to open a Pull Request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later. 61 | 62 | 📫 Contact 63 | --- 64 | 65 | This project is maintained by the members of the **[Open Research Community Building Team](https://github.com/alan-turing-institute/open-community-building)**. 66 | For any organisation related queries or concerns, you can directly reach out to **Malvika Sharan by emailing [msharan@turing.ac.uk](mailto:msharan@turing.ac.uk)**. 67 | 68 | ♻️ License 69 | --- 70 | 71 | This work is licensed under the **MIT license (code) and Creative Commons Attribution 4.0 International license (for documentation)**. 72 | 73 | You are free to share and adapt the material for any purpose, even commercially, 74 | as long as you provide attribution (give appropriate credit, provide a link to the license, 75 | and indicate if changes were made) in any reasonable manner, but not in any way that suggests the 76 | licensor endorses you or your use, and with no additional restrictions. 77 | 78 | 79 | For a more detailed contribution guideline, please check out *[The Turing Way's CONTRIBUTING.md file](https://github.com/alan-turing-institute/the-turing-way/blob/main/CONTRIBUTING.md)*. 80 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # MIT (software) and Creative Commons (documentation/content) License 2 | 3 | 4 | To learn more about why we recommend using a LICENSE.md file, please read the [Creating Project Repositories](https://the-turing-way.netlify.app/project-design/project-repo.html) in The Turing Way Guide for Project Design. 5 | To identify and select an appropriate license for the content in your project, please read the [Licensing](https://the-turing-way.netlify.app/reproducible-research/licensing.html#) chapter in The Turing Way Guide to Reproducible Research. 6 | 7 | 8 | ## MIT License 9 | 10 | Copyright (c) 2021 The Alan Turing Institute 11 | 12 | Permission is hereby granted, free of charge, to any person obtaining a copy 13 | of this software and associated documentation files (the "Software"), to deal 14 | in the Software without restriction, including without limitation the rights 15 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 16 | copies of the Software, and to permit persons to whom the Software is 17 | furnished to do so, subject to the following conditions: 18 | 19 | The above copyright notice and this permission notice shall be included in all 20 | copies or substantial portions of the Software. 21 | 22 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 23 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 24 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 25 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 26 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 27 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 28 | SOFTWARE. 29 | 30 | ## Attribution 4.0 International 31 | 32 | Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible. 33 | 34 | ### Using Creative Commons Public Licenses 35 | 36 | Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses. 37 | 38 | * __Considerations for licensors:__ Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. [More considerations for licensors](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensors). 39 | 40 | * __Considerations for the public:__ By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. [More considerations for the public](http://wiki.creativecommons.org/Considerations_for_licensors_and_licensees#Considerations_for_licensees). 41 | 42 | ## Creative Commons Attribution 4.0 International Public License 43 | 44 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 45 | 46 | ### Section 1 – Definitions. 47 | 48 | a. __Adapted Material__ means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 49 | 50 | b. __Adapter's License__ means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 51 | 52 | c. __Copyright and Similar Rights__ means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 53 | 54 | d. __Effective Technological Measures__ means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 55 | 56 | e. __Exceptions and Limitations__ means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 57 | 58 | f. __Licensed Material__ means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 59 | 60 | g. __Licensed Rights__ means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 61 | 62 | h. __Licensor__ means the individual(s) or entity(ies) granting rights under this Public License. 63 | 64 | i. __Share__ means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 65 | 66 | j. __Sui Generis Database Rights__ means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 67 | 68 | k. __You__ means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 69 | 70 | ### Section 2 – Scope. 71 | 72 | a. ___License grant.___ 73 | 74 | 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 75 | 76 | A. reproduce and Share the Licensed Material, in whole or in part; and 77 | 78 | B. produce, reproduce, and Share Adapted Material. 79 | 80 | 2. __Exceptions and Limitations.__ For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 81 | 82 | 3. __Term.__ The term of this Public License is specified in Section 6(a). 83 | 84 | 4. __Media and formats; technical modifications allowed.__ The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 85 | 86 | 5. __Downstream recipients.__ 87 | 88 | A. __Offer from the Licensor – Licensed Material.__ Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 89 | 90 | B. __No downstream restrictions.__ You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 91 | 92 | 6. __No endorsement.__ Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 93 | 94 | b. ___Other rights.___ 95 | 96 | 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 97 | 98 | 2. Patent and trademark rights are not licensed under this Public License. 99 | 100 | 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 101 | 102 | ### Section 3 – License Conditions. 103 | 104 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 105 | 106 | a. ___Attribution.___ 107 | 108 | 1. If You Share the Licensed Material (including in modified form), You must: 109 | 110 | A. retain the following if it is supplied by the Licensor with the Licensed Material: 111 | 112 | i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 113 | 114 | ii. a copyright notice; 115 | 116 | iii. a notice that refers to this Public License; 117 | 118 | iv. a notice that refers to the disclaimer of warranties; 119 | 120 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 121 | 122 | B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 123 | 124 | C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 125 | 126 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 127 | 128 | 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 129 | 130 | 4. If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. 131 | 132 | ### Section 4 – Sui Generis Database Rights. 133 | 134 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 135 | 136 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 137 | 138 | b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and 139 | 140 | c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 141 | 142 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 143 | 144 | ### Section 5 – Disclaimer of Warranties and Limitation of Liability. 145 | 146 | a. __Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.__ 147 | 148 | b. __To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.__ 149 | 150 | c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 151 | 152 | ### Section 6 – Term and Termination. 153 | 154 | a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 155 | 156 | b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 157 | 158 | 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 159 | 160 | 2. upon express reinstatement by the Licensor. 161 | 162 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 163 | 164 | c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 165 | 166 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 167 | 168 | ### Section 7 – Other Terms and Conditions. 169 | 170 | a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 171 | 172 | b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 173 | 174 | ### Section 8 – Interpretation. 175 | 176 | a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 177 | 178 | b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 179 | 180 | c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 181 | 182 | d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 183 | 184 | > Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the [CC0 Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/legalcode). Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at [creativecommons.org/policies](http://creativecommons.org/policies), Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses. 185 | > 186 | > Creative Commons may be contacted at creativecommons.org 187 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Research Application Management Team repository 2 | 3 | [![All Contributors](https://img.shields.io/badge/all_contributors-5-orange.svg?style=flat-square)](#contributors-) 4 | 5 | 6 | ## About this Repository 7 | 8 | This repository includes resources recommended created by the Alan Turing Institute's Research Application Management team. Learn more about our team and what Research Application Managers do at the Turing [here](https://www.turing.ac.uk/research/research-programmes/tools-practices-and-systems/research-application-management). 9 | 10 | The [`resources` folder](https://github.com/alan-turing-institute/research-application-management/tree/main/resources) includes case studies and templates for RAM outputs including strategy sessions and stakeholder workshops. 11 | 12 | The [`new_starter_onboarding` folder](https://github.com/alan-turing-institute/research-application-management/tree/main/new_starter_onboarding) includes checklists for RAM onboarding sessions, designed to be covered during a new employee's first two weeks. 13 | 14 | This repository follows the recommendations and guidance provided in *[The Turing Way](https://the-turing-way.netlify.app/welcome)* handbook to data science. 15 | 16 | **Maintainers** 17 | 18 | This repository is developed and maintained by the Research Application Management team under the Tools, Practices and Systems Research Programme at The Alan Turing Institute. 19 | 20 | *Please create [an issue](../../issues) to share references or ideas related to the development of this project.* 21 | 22 | 📫 Contact 23 | --- 24 | 25 | For any organisation related queries or concerns, you can directly reach out to the RAM team by emailing [RAM@turing.ac.uk](mailto:RAM@turing.ac.uk). 26 | 27 | ♻️ License 28 | --- 29 | 30 | This work is licensed under the MIT license (code) and Creative Commons Attribution 4.0 International license (for documentation). 31 | You are free to share and adapt the material for any purpose, even commercially, 32 | as long as you provide attribution (give appropriate credit, provide a link to the license, 33 | and indicate if changes were made) in any reasonable manner, but not in any way that suggests the 34 | licensor endorses you or your use, and with no additional restrictions. 35 | 36 | ## Contributors ✨ 37 | 38 | Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)): 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 |

Aida Mehonic
🐏
Alden Conner
🐏
Jennifer Ding
🐏
Hari Sood
🐏
Shakir Laher
🐏
Cami Rincon
🐏
Kalle Westerling
🐏
Sophie Arana
🐏
Fran Gomez Medina
🐏
58 | 59 | 60 | 61 | 62 | 63 | 64 | This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome! 65 | -------------------------------------------------------------------------------- /new_starter_onboarding/communities_to_join.md: -------------------------------------------------------------------------------- 1 | # Suggested Communities to Join 2 | 3 | ## Mailing Lists / Newsletters 4 | ### Within ATI 5 | - [The Alan Turing Institute Mailing Lists](https://www.turing.ac.uk/contact-us/join-our-mailing-lists) 6 | - [The Turing Way Mailing List](https://tinyletter.com/TuringWay) 7 | ### Outside ATI 8 | - Open Data Institute [The Week in Data](https://theodi.org/knowledge-opinion/the-week-in-data/) 9 | - Edinburgh's [Centre for Technomoral Futures](https://www.technomoralfutures.uk/#newsletter-sign-up) 10 | 11 | ## Slack Groups 12 | ### Within ATI 13 | - The Turing Way 14 | - Turing Commons 15 | - Learning at the Turing 16 | 17 | ### Outside ATI 18 | - 19 | -------------------------------------------------------------------------------- /new_starter_onboarding/objectives_setting.md: -------------------------------------------------------------------------------- 1 | # Objective Setting 2 | 3 | ## Probation 4 | 5 | In the first six months at Turing, new starters are in a probationary period for which they will 6 | set goals for review at the end of probation. 7 | To learn more about the Probation process and timelines, 8 | see this [Mathison document](https://mathison.turing.ac.uk/page/2466). 9 | 10 | The target is for the new starter to set 3-5 objectives within week 1-3 with an assessment 11 | at the 5 months mark. 12 | These should each be aligned with a Turing 2.0 principle 13 | It is recommended to use the [SMART goals framework](https://en.wikipedia.org/wiki/SMART_criteria). 14 | 15 | ### Example RAM Objectives for Probation 16 | 17 | These objectives were created by new RAMs in the AI for Science and Government (ASG) programme. 18 | 19 | 1. Contribute to Turing research impact through stakeholder communication and engagement activities 20 | - Facilitate the publication of 1-2 impact stories with the Comms team 21 | - Organise workshop with external stakeholder 22 | 23 | 2. Scope and kickstart 2-3 RAM engagements across the programme 24 | - Meet with multiple researchers in the programme to assess readiness for RAM engagement 25 | - Make connections within the programme and beyond in the wider Turing network 26 | 27 | 3. Upskill on RAM, TPS, and TTW ways of working & identify opportunities to feed back 28 | - Open issues and begin contributing to the RAM and TTW repos 29 | - Co-create workshop to bring RAM or TTW practices and values to other Turing programmes and communities 30 | 31 | ## Appraisal 32 | 33 | Every year, Turing runs an appraisal process which consists of objective setting for performance review and is part of any performance-related pay discussion. 34 | Objectives are set in September and will be reviewed again in May of the next year, and it is suggested to set 3-5 objectives each aligned with a Turing 2.0 principle. 35 | That process consists of a self evaluation on Cezanne, line manager evaluation on Cezanne, and performance review meeting with the line manager. 36 | To learn more about theses processes, see the Mathison documentation on [Appraisal](https://mathison.turing.ac.uk/Interact/Pages/Section/ContentListing.aspx?subsection=3715) and [Performance Review](https://mathison.turing.ac.uk/page/2319). 37 | 38 | It is recommended to use the [SMART goals framework](https://en.wikipedia.org/wiki/SMART_criteria). 39 | Please note that this may not be the exact same list as your own professional goals, which may 40 | come up in discussion with your line manager as well, but is simply used to assess your work 41 | against programme and Institute level goals. 42 | 43 | The May appraisal cycle is also an opportunity to review and set personal development goals, but these should be in scope for conversations with your line manager throughout the year. 44 | 45 | ### Example RAM Objectives for Appraisal 46 | 47 | 1. Expand Turing research impact with 2-3 industry or government stakeholders 48 | - Further develop working relationship with stakeholder groups by organising 1-2 stakeholder workshops 49 | - Identify 1-2 new opportunities to collaborate with potential Turing partners 50 | 2. Expand impact of RAM team within and beyond the Turing 51 | - Contribute 1-2 new tools to RAM repository of reusable templates and open infrastructure tools 52 | - Give 1-2 external presentations on the RAM team 53 | 3. Contribute to open & responsible AI work and thought leadership 54 | - Organise 1-2 events on open source AI which highlight Turing additionality and convene a diverse audience 55 | - Write 1 paper to present at conference featuring work at The Turing 56 | 57 | ## Turing 2.0 Principles 58 | 59 | Each objective should be aligned to one of these principles: 60 | - Build and deliver Turing 2.0 61 | - Deliver measurable impact to solve real world challenges 62 | - Be innovative to always add value 63 | - Progress our stated EDI priorities 64 | - Secure longer term diversified income 65 | - Build and embed resilience 66 | -------------------------------------------------------------------------------- /new_starter_onboarding/sessions/1_day_one_checklist.md: -------------------------------------------------------------------------------- 1 | # Day 1 onboarding checklist 2 | 3 | This document provides checklists to cover the logistical items that will enable onboarding of a new RAM member! 4 | This session should probably be one of the first sessions the new team member does - it's best to schedule a meeting with an existing team member to go through the list of sign-ups and answer any questions, but the line manager and new team member should also use this checklist to confirm that all of these items have been completed by the end of the first week. The remaining sessions will cover many of these topics in more detail. 5 | 6 | Time required: 1 hour 7 | 8 | ## Onboarding checklist - review together 9 | - [ ] Introduce [Mathison](https://mathison.turing.ac.uk) 10 | - [ ] Join Slack (link in Mathison sidebar) 11 | - [ ] Github account 12 | - [ ] Hackmd account 13 | - [ ] Introduce [Turing learning platform](https://turing.learnupon.com/dashboard) 14 | - [ ] Demonstrate how to book rooms through the calendar 15 | 16 | ## New hire checklist 17 | - [ ] [Request new researcher profile](https://turingcomplete.topdesk.net/tas/public/ssp/content/serviceflow?unid=35b8d40067004f9484c9fb06ade41d65) 18 | - [ ] Review [work from home policy](https://mathison.turing.ac.uk/page/2218?SearchId=258433&utm_source=interact&utm_medium=general_search&utm_term=work%20from%20home#!) 19 | 20 | ## Line manager checklist 21 | - [ ] Add new team member to ram@turing.ac.uk email distribution 22 | -------------------------------------------------------------------------------- /new_starter_onboarding/sessions/2_ram_life.md: -------------------------------------------------------------------------------- 1 | # Session 2: RAM life onboarding 2 | 3 | This file contains the information to cover in the RAM life onboarding session for a new RAM member! 4 | This session should probably be one of the first sessions the new team member does 5 | 6 | Time required: 1 hour 7 | 8 | ## Line manager checklist 9 | - [ ] Add to necessary Github repos 10 | - Github will be covered in session 4 11 | - [ ] Confirm SharePoint access 12 | 13 | ## Onboarding checklist - review together 14 | 15 | RAM meetings 16 | - [ ] Discuss RAM team meeting schedule/format 17 | - [ ] Discuss RAM co-working format 18 | - [ ] Discuss chairing responsibilities and how to find and edit the correct meeting hackmd 19 | - [ ] Demonstrate how to view and edit RAM calendar 20 | 21 | Slack 22 | - [ ] Review Slack channels 23 | - [ ] Check for calendar invites to TPS events (Collab cafe, coffees, team meeting, etc.) and Turing events (Town Halls, etc.) 24 | - These will be introduced in more detail in session 3 25 | 26 | RAM team intro 27 | - [ ] [RAMs in 2023](https://docs.google.com/presentation/d/1vHxs9iDhqpjbFXXOc-KCMNoj32I6nVngkH1Vu21taig/edit?usp=sharing) 28 | - [ ] Introduce the [RAM repo](https://github.com/alan-turing-institute/research-application-management) 29 | - If required, discuss resources for learning Github 30 | - [ ] Review content in the [RAM SharePoint](https://thealanturininstitute.sharepoint.com/sites/RAM/Shared%20Documents/Forms/AllItems.aspx) 31 | - [ ] Review [Facilitating Stakeholder Engagement chapter](https://the-turing-way.netlify.app/collaboration/stakeholder-engagement.html) and resources like the TPS Stakeholder map (link in chapter) 32 | 33 | ## Optional extras 34 | - Set up a website editing training session 35 | - Set up a CRM training session 36 | -------------------------------------------------------------------------------- /new_starter_onboarding/sessions/3_people_and_teams.md: -------------------------------------------------------------------------------- 1 | # People & teams onboarding session 2 | 3 | This file contains the information to cover in the people & teams onboarding session for a new RAM member! 4 | This session should probably be one of the first sessions the new team member does 5 | 6 | Time required: 1 hour 7 | 8 | ## Line manager checklist 9 | - [ ] Introduce new starter in the TPS-team Slack channel 10 | - [ ] Find a TPS Team coffee chat in the week they are starting that a majority of the team can make to say hi - ideally this would be on their first day but could be a different day if needed! 11 | - [ ] Ensure someone from the project teams they'll be joining is set-up to onboard them to the project, and will help them meet everyone on the team 12 | - [ ] Make a list of people for new starter to meet & set up coffee chats with in the first few weeks 13 | 14 | ## Review together 15 | 16 | ### TPS (10 mins) 17 | - [ ] Introduce [TPS](https://www.turing.ac.uk/research/research-programmes/tools-practices-and-systems), including the [impact story](https://www.turing.ac.uk/research/impact-stories/changing-culture-data-science) 18 | - [ ] Introduce TPS coffee chats and team coffee chats 19 | - [ ] People to know in TPS 20 | - [ ] Show them the [team members intro slide deck](https://docs.google.com/presentation/d/1g-plncmi00FK97QuYDfqq7oPzUmL0xkHm1hy4X81IX8/edit?usp=sharing) and ask them to create their own slide 21 | - [ ] Show them the [TPS team notes of notes](https://hackmd.io/@whitakerlab/note-of-notes) 22 | 23 | ### The Turing Way (10 mins) 24 | - [ ] Introduce the [Turing Way](https://the-turing-way.netlify.app/welcome) 25 | - [ ] Ensure they are added to the relevant Turing Way meetings 26 | - Coworking (Weekly Monday 11am) 27 | - Collaboration cafes (1st and 3rd Wednesday 3-5pm) 28 | - Core team meeting (Quarterly Friday 3pm) 29 | - [ ] Add them to the Slack workspace and get them to introduce themselves in `#introductions` 30 | 31 | ### Turing teams (15 mins) 32 | - [ ] Highlight the different groups in Turing the RAM team spends time collaborating with 33 | - [ ] Introduce them to the groups below and help them reach out to the respective contacts to set up an introductory chat 34 | - Partnerships 35 | - Impact 36 | - Events, including the [Events hub](https://mathison.turing.ac.uk/Interact/Pages/Section/Default.aspx?Section=3924&utm_source=interact&utm_medium=quick_search&utm_term=events+draft) on Mathison 37 | 38 | ### Other Slack channels (5 mins) 39 | - [ ] Alert them to all the different slack channels you can join at Turing (by hovering over `Channels` and clicking `+` -> `Browse channels`) 40 | - [ ] Let them know how they can manage their slack notifications - and probably turn on notifications for the RAM channel 41 | 42 | ### Team social (5 min) 43 | - [ ] Explore a time when they are free the newly expanded RAM team can go on a social together! A drink after work or lunch, or anything else that makes sense! 44 | -------------------------------------------------------------------------------- /new_starter_onboarding/sessions/4_github.md: -------------------------------------------------------------------------------- 1 | # GitHub onboarding session 2 | 3 | This file contains the information to cover in the GitHub onboarding session for a new RAM member! 4 | This session should probably take place after the sessions introducing them to TPS-associated projects, like the Turing Way and Whitaker Lab, as well as 'RAM life' 5 | 6 | Time required: 45 mins 7 | 8 | ## Before the session 9 | * Find out which projects they're working on. Ensure that, as part of the projects' onboarding plans, they have set aside specific time to introduce them to the GitHub repos the project works with. 10 | 11 | ## During the session 12 | 13 | * Make sure they have a GitHub account (create one if required). 14 | * Get them to sign up to become a member of the Alan Turing Institute Organisation on GitHub via [this form](https://turingcomplete.topdesk.net/tas/public/ssp/content/serviceflow?unid=3844fabf8b1c45ca9028758a350ff230&from=c56ec576-4ee8-4b07-8bde-9f9f45b6d561&openedFromService=true) 15 | * If they're not familiar with GitHub, help them to organise a GitHub onboarding/training session. A good place to start is reach out to the Turing Way team to see whether any Intro to GitHub sessions are running soon - if not there are recordings of sessions they can watch! 16 | * Introduce them to the main repos they will need to familairise themselves with on a RAM side: 17 | - **[Turing Way](https://github.com/alan-turing-institute/the-turing-way)** 18 | - Add them as a collaborator 19 | - Introduce the book 20 | - Tasks for them to complete: 21 | - Read through the README, CONTRIBUTING, CODE_OF_CONDUCT (and more if it interests them!) 22 | - Add their name to `contributors.md` 23 | - **[RAM Repo](https://github.com/alan-turing-institute/research-application-management)** 24 | - Add them to the repo 25 | - Walk through the project board 26 | - Describe what the repo is for 27 | - **[Reproducible project template](https://github.com/alan-turing-institute/reproducible-project-template)** 28 | - Introduce them to this template, and why it could be useful to them on their projects 29 | * Help them coordinate GitHub onboarding sessions for their projects 30 | -------------------------------------------------------------------------------- /resources/case_studies/asg/1-pagers/Equadratures.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/research-application-management/16af73c43e12290fa581ea75ef11be752edc278f/resources/case_studies/asg/1-pagers/Equadratures.pdf -------------------------------------------------------------------------------- /resources/case_studies/asg/1-pagers/Fleet Monitoring v3_compressed.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/research-application-management/16af73c43e12290fa581ea75ef11be752edc278f/resources/case_studies/asg/1-pagers/Fleet Monitoring v3_compressed.pdf -------------------------------------------------------------------------------- /resources/case_studies/asg/1-pagers/VoD.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alan-turing-institute/research-application-management/16af73c43e12290fa581ea75ef11be752edc278f/resources/case_studies/asg/1-pagers/VoD.pdf -------------------------------------------------------------------------------- /resources/case_studies/asg/ab-street.md: -------------------------------------------------------------------------------- 1 | # AB street 2 | 3 | [Project Page](http://ltn.abstreet.org/) 4 | 5 | ### RAM engagement: May 2022 - March 2023 6 | 7 | ## Description: 8 | * A/B street has created an online tool that can help residents and planners have a shared canvas for discussing potential street-level changes, 9 | such as planting street trees or installing a model filter to encourage cycling and walking. 10 | 11 | ## Impact Highlights 12 | * Integration in Bristol City Council LTN public consultation in Autumn 2022 13 | * Creating training material for city council members and the general public 14 | * EDT highlight: A/B street's LTN tool allows for testing urban planning interventions on an interactive interface representing a digital twin of 15 | traffic levels within a city. The technology simulates the impact of traffic re-routing if different street-level changes were made (e.g. modal filter, 16 | bollards, conversion to one-way street). This tool allows planners to take into consideration the city-level impacts of specific changes to evaluate 17 | the network effects on transportation across across a street, neighbourhood, and city. 18 | 19 | ## Stakeholder engagement 20 | * Create materials for use of tool in Bristol City Council public consultation ([intro video](https://www.youtube.com/watch?v=m22WP62yyZ0), [tutorial video](https://www.youtube.com/watch?v=j64ZtDfGPCY), [user guide](https://docs.google.com/presentation/d/1vU4xITmd9PMX4QJi0xP5ZJVpuWE9rpE3SvvYdq9_xb8/edit?usp=sharing)) 21 | * Facilitate AI UK Workshop ([notes](https://docs.google.com/document/d/1xPcY50wf0VaxRy9AMXSoLKYI01BOpSiFMwkgNrFhFgg/edit#heading=h.6avkr0nu6axo)) 22 | 23 | ## Public-facing outputs 24 | * [Intro video for Bristol City Council public consultation]() 25 | * [AI UK Workshop Video](https://www.youtube.com/watch?v=5e1nroJHcBE&list=PLuD_SqLtxSdVEUsCYlb5XjWm9D6WuNKEz&index=6) 26 | -------------------------------------------------------------------------------- /resources/case_studies/asg/dt-fleets.md: -------------------------------------------------------------------------------- 1 | # DTs for Fleet Modelling 2 | 3 | [Project page](https://github.com/labull/EngineeringPatternRecognition/blob/main/Knowledge-transfer-in-engineering-fleets.ipynb) 4 | 5 | ### RAM engagement: January 2022 - March 2023 6 | 7 | ## Description: 8 | * Method to improve the predictive capability of asset management algorithms by learning from d ata recorded from an entire fleet - rather than individual systems. By considering populations as a whole, such as trucks in a transportation network or turbines in a wind farm, the data available 9 | for training can be (in effect) extended. This mode of inference can improve the predictive performance while reducing the uncertainty in the models that approximate fleet status 10 | 11 | ## Impact Highlights 12 | * RAM creation of 1-pager to share with external stakeholders 13 | * EDT highlight: By constructing digital twins of distributed fleets, 14 | Fleet Monitoring delivers enhanced asset management through better performance and efficiency for the entire population. 15 | Fleet Monitoring is collaborating with Scania to support survival analysis and prognostics for their truck fleets, 16 | reducing down-time and maintenance costs. By sharing data between turbines, Fleet Monitoring can help wind farms improve their power output predictions 17 | for reliable performance monitoring and forecasting. 18 | 19 | ## Stakeholder engagement 20 | * Facilitate AI UK 2022 Workshop ([notes](https://docs.google.com/document/d/1RpHiux5uHtWqhTlwLvUCbyRVWGQ_FohYlAAOzAp4y9g/edit#)) 21 | * Meeting with Visualwind Managing Director for feedback 22 | 23 | ## Public-facing outputs 24 | * [1-pager](https://github.com/alan-turing-institute/research-application-management/blob/case_study_repo/docs/case_studies/asg/1-pagers/Fleet%20Monitoring%20v3_compressed.pdf) 25 | * [AI UK 2022 Lightning Talk](https://www.youtube.com/watch?v=EVTJDvRNMfs&list=PLuD_SqLtxSdV29ArDt6Yorez73Mmz-Jyb&index=9) 26 | * [AI UK 2022 Workshop](https://www.youtube.com/watch?v=MQ88wg9-WqQ&list=PLuD_SqLtxSdVEUsCYlb5XjWm9D6WuNKEz&index=8) 27 | -------------------------------------------------------------------------------- /resources/case_studies/asg/energyflex.md: -------------------------------------------------------------------------------- 1 | # EnergyFlex 2 | 3 | [Project Page](https://www.turing.ac.uk/research/research-projects/simulating-energy-efficiency-opportunities-households) 4 | 5 | ## RAM engagement: February 2022 - September 2022 6 | 7 | ## Impact Highlights 8 | * EnergyFlex has created a microsimulation tool that can model individual households in a local area and estimate energy consumption and socio-economic context at a high resolution. The tool is co-designed with public/private housing stakeholders to address challenges faced by local government, developers, and other stakeholders in implementing energy retrofits and decarbonisation efforts 9 | * EnergyFlex model is available on DAFNI 10 | * EDT highlight: EnergyFlex has integrated building & energy datasets in order to create a representative model or "digital twin" of the UK's housing stock for microsimulation. The building-level granularity allows for targeted energy retrofit analysis so policymakers can experiment with different interventions and quantify the impact at local, regional, and national scales. 11 | 12 | ## Stakeholder engagement 13 | * Facilitate AI UK 2022 Panel with stakeholders from Cambridge U, Parity Projects, and Cambridge Centre for Housing and Planning Research ([notes](https://docs.google.com/document/d/1pDDuoISwnVpP-955YYVKNIuaBlBR-l1TrqNpYTVRdUM/edit#heading=h.6avkr0nu6axo)) 14 | * Introduction to LOTI 15 | * Pilots with Haringey Council, BEIS 16 | 17 | ## Public-facing outputs 18 | * [Webpage](https://www.turing.ac.uk/research/research-projects/simulating-energy-efficiency-opportunities-households) 19 | * [AI UK 2022 Lightning Talk](https://www.youtube.com/watch?v=TuDsTOjZI-g) 20 | * [AI UK 2022 Panel](https://www.youtube.com/watch?v=dHJyMyFdMDs) 21 | -------------------------------------------------------------------------------- /resources/case_studies/asg/value_of_data.md: -------------------------------------------------------------------------------- 1 | # Quantifying the Expected Value of Data 2 | 3 | [Project Page]() 4 | 5 | ### RAM engagement: June 2022 - March 2023 6 | 7 | ## Description: 8 | * There are an increasing number of techologies for data collection from engineering assets - but how much data is required, 9 | how good does it need to be, and how much should engineers be willing to pay for it? Using ‘Value of Information’ (VoI) analysis, 10 | it is possible to understand how and to what extent prospective data is expected to support decision making. 11 | 12 | ## Impact Highlights 13 | * RAM creation of 1-pager to share with external stakeholders 14 | * EDT highlight: Research directions like Value of Information provide supporting tools in the Digital Twins ecosystem, particularly for 15 | applications requiring decision-making under uncertainty around a major asset or system like the built enviornment. This decision process can help 16 | quantify the expected value of data collection for a given project, answering questions like "A strain gauge has stopped functioning in my bridge - 17 | should I replace it?" or "How much should I be willing to pay for a smart meter?" 18 | 19 | ## Stakeholder engagement 20 | * 21 | 22 | ## Public-facing outputs 23 | * [1-pager]([https://github.com/alan-turing-institute/research-application-management/blob/case_study_repo/docs/case_studies/asg/1-pagers/Fleet%20Monitoring%20v3_compressed.pdf](https://github.com/alan-turing-institute/research-application-management/blob/case_study_repo/docs/case_studies/asg/1-pagers/VoD.pdf)) 24 | * Computational document 25 | -------------------------------------------------------------------------------- /resources/case_studies/case_study_template.md: -------------------------------------------------------------------------------- 1 | # [PROJECT NAME] 2 | [Project page](LINK) 3 | 4 | #### RAM engagement timeline: MONTH YYYY - MONTH YYYY 5 | 6 | ## Description 7 | 8 | 9 | ## Impact highlights 10 | * 11 | * 12 | 13 | ## Stakeholder engagement 14 | * EXAMPLE: Facilitate Workshop ([notes](LINK)) 15 | * 16 | 17 | ## Public-facing outputs 18 | * EXAMPLE: [1-pager](LINK) 19 | * EXAMPLE: [AI UK Workshop Video](LINK) 20 | -------------------------------------------------------------------------------- /resources/case_studies/glossy_template.md: -------------------------------------------------------------------------------- 1 | # Resources for creating project glossies 2 | 3 | 1. [Figma Template](https://www.figma.com/file/LDVJKmEVUAwgzlCWlwFJVI/Turing-RAM-Glossy-Templates?node-id=0%3A1) for 1-page glossies 4 | 2. Examples 5 | - https://www.figma.com/proto/pgZWeVQl98PzezhUTdJwvo/fleet-modelling?node-id=8%3A2&scaling=min-zoom&page-id=0%3A1 6 | - https://www.figma.com/proto/zoymIhp0wM15dpDTQnDgAW/eq?node-id=48%3A2&scaling=min-zoom&page-id=0%3A1 7 | -------------------------------------------------------------------------------- /resources/discussions/participatory and public engagement techniques.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /resources/events/event_checklist.md: -------------------------------------------------------------------------------- 1 | # RAM Event Checklist 2 | 3 | Here is a checklist of steps to take and resources to refer to when organising a Turing event. 4 | 5 | ## Setting up the Event 6 | 1. Decide whether or not you need the support of the Events team (usually for a large, high profile event with external audience included). (If yes, work with RPM to submit [Events and engagement request form](https://mathison.turing.ac.uk/Interact/Pages/Content/Document.aspx?id=2334&SearchId=18818&utm_source=interact&utm_medium=quick_search&utm_term=event)) 7 | 2. Decide whether or not the event has an in-person component. (If yes, notify Events team and contact Facilities to reserve room). 8 | 3. Work with RPM to create [Zoom event registration page](https://support.zoom.us/hc/en-us/articles/211579443-Scheduling-a-meeting-with-registration). 9 | 4. Decide whether or not you need an event page on the Turing website. (If yes, work with [website team](https://mathison.turing.ac.uk/Interact/Pages/Content/Document.aspx?id=2323&SearchId=18827&utm_source=interact&utm_medium=general_search&utm_term=website+template) to fill out website template and share speaker bio/photos if they do not have a Turing profile already). 10 | 5. Promote event link / registration info through Slack, Twitter, LinkedIn and other distribution channels. (If you require Turing support, contact the [marketing team](https://mathison.turing.ac.uk/Interact/Pages/Content/Document.aspx?id=2325&SearchId=18852&utm_source=interact&utm_medium=general_search&utm_term=social+media)). 11 | 12 | ## Preparing for the Event 13 | 6. Ensure speakers have the correct meeting joining info and can join earlier to test microphone/slides, if needed. 14 | 7. If there is a Zoom component, make sure the settings are appropriate. (e.g. speakers as "Hosts", chat permissions, microphone permissions) 15 | 8. If you need a Slido or other Q&A/discussion tool, work with Events to set it up. 16 | 9. Review the Events [Content Moderation Guidance](https://thealanturininstitute.sharepoint.com/:w:/s/ee/Ec7MKsPEP6hJt00df8EhEQwBPOaCdDM1FVG4oxjnS_sOSg) for advice and resources on how to address different disruptive situations. 17 | 10. Decide whether or not you will record the event and notify audience if you do. 18 | 19 | ## After the Event 20 | 21 | 11. If you plan to publish a video, collect a signed Speaker Release from all speakers, make the video downloadable so Video team can accept it and add request for deadline. Send this and the request to publish the video to the Turing Video team. 22 | -------------------------------------------------------------------------------- /resources/innovation/spinout_resources.md: -------------------------------------------------------------------------------- 1 | # Spinout Resources 2 | 3 | ## Incubator programmes 4 | A good way to find support and connect with relevant people and organzations is to join an incubator programme such as Google's [Summer of Code](https://summerofcode.withgoogle.com), [Open Life Science](https://openlifesci.org/), or Code for Science and Society's [Incubator](https://www.codeforsociety.org/incubator/). 5 | These are only three examples out of many programmes, and you may find that a domain or field-specific programme is more aligned with your needs and values, so it's worth doing some research and speaking to your peers to find the best fit. 6 | Participating in an incubator programme has several advantages including growing your network and community through dedicated mentorship and support; however, these programmes are not the only means of connecting with others in your field. 7 | Once you have identified the areas of your project that require support, you can reach out to your colleagues and collaborators to discuss options for sustaining your project. 8 | 9 | ## Connecting with the wider ecosystem 10 | Often, research projects coming out of academia might have an active contributor base but don't have access to the computing infrastructure and support resources required to maintain the project in the long term. 11 | In that case, you may want to consider embedding the project into a larger pre-existing open source project or product. 12 | By exploring connections within your community, whether through an incubator program or your existing network, you may find organizations that are interested in incorporating your work into an existing, stable infrastructure. 13 | 14 | If you are looking to build a community and find users and contributors, you can contribute your work to an ecosystem that hosts and supports code for related applications. 15 | One example is [Scientific Python](https://scientific-python.org), which provides a platform where you can make your code widely available to a broad audience and invite contributors from an established community. 16 | 17 | ## Raising funding 18 | If you think your project is ready to be spun out into an independent enterprise, there is a wide range of possibilities for funding and supporting a non-profit or commercial organization based around open source software. 19 | Some projects turn to their communities to raise funds through donations or crowdsourcing campaigns. 20 | Others may look to government grants or other grand funding from philanthropic organisations such as the [Linux Foundation](https://www.linuxfoundation.org/projects/hosting) or [Chan Zuckerberg Initiative](https://chanzuckerberg.com/). 21 | Finally, if your project generates revenue, you may consider raising funding from a private investor or company, or join a funded startup incubator programme such as [Y Combinator](https://www.ycombinator.com/). 22 | -------------------------------------------------------------------------------- /resources/pitchfest/comms-templates.md: -------------------------------------------------------------------------------- 1 | # Comms templates 2 | Find here comms and outreach templates for different groups for PitchFest, 3 | These were used at the Alan Turing Institute to reach different people, please amend and use for your own purposes/groups! 4 | 5 | ## PitchFest 2022 6 | 7 | ### Outreach 8 | - Slack 9 | - General 10 | - Office hours 11 | 12 | ### Finalists 13 | - Info + actions 14 | 15 | ### Non finalists 16 | - Feedback 17 | -------------------------------------------------------------------------------- /resources/pitchfest/index.md: -------------------------------------------------------------------------------- 1 | # PitchFest 2 | 3 | This file contains all the information required to run a 'PitchFest' competition, similar to that run by the Alan Turing Institute at AI UK. 4 | 5 | ## What is PitchFest 6 | 7 | 8 | ## Resources 9 | ### Guides 10 | - PitchFest 2023 write-up 11 | 12 | -------------------------------------------------------------------------------- /resources/pitchfest/pitchfest-2023.md: -------------------------------------------------------------------------------- 1 | # PitchFest 2023 2 | 3 | This page contains a write-up of all the steps that made up PitchFest 2023, run by the Alan Turing Institute at AI UK 2023. 4 | 5 | Please feel free to use this as a guide to set up and run your own PitchFest! 6 | However, please don't take the below as a rigid script - this was our first year running it and we learned a lot to improve for future years. 7 | This is highlighted by a 'potential improvements' heading under each section below. 8 | 9 | ## Overview 10 | PitchFest broadly consisted of the following steps, which will be broken down below: 11 | - [Preparation](#preparation) 12 | - [Call for applications](#call-for-applications) 13 | - [Closing applications and judging process](#closing-applications-and-judging-process) 14 | - [Finalist training](#finalist-training) 15 | - [Finalist reheasal session](#finalist-reheasal-session) 16 | - [PitchFest event at AIUK](#pitchfest-event-at-aiuk) 17 | - [Wrapping up and next steps](#wrapping-up-and-next-steps) 18 | 19 | ### Preparation 20 | #### Summary 21 | 22 | The first step was to scope out what PitchFest looks like. 23 | This included considerations for: 24 | - The application process 25 | - The judging criteria 26 | - The event timeline 27 | - The judges 28 | - The prizes 29 | 30 | The end output for this stage was the creation of a [PitchFest one pager](https://www.turing.ac.uk/pitchfest-share-your-research-world) to which all applications were directed. 31 | 32 | ##### Application process 33 | Applicants needed to submit their application via Google Form that contained: 34 | - Their name (required) 35 | - Their Turing role or affiliation (required, only Turing people could apply for PitchFest 2023) 36 | - Pitch title (required) 37 | - Association with a Turing research project (optional) 38 | - Other people involved with the pitch (optional) 39 | - Pitch (required, submission either via text or link to a video or audio recording) 40 | - Any other information (optional) 41 | 42 | ##### Judging criteria 43 | The judging criteria were determined by the RAM team, and were: 44 | - **Accessibility and communication**: The audience at AI UK is broad with a diverse range of attendees coming from various backgrounds. Is the pitch appropriate for the audience while also being as inclusive and accessible as possible? 45 | - **Real-world application**: As the national institute for data science and AI, it’s crucial to ensure our research outputs are being applied to solve real-world problems. Does the pitch clearly lay out the motivations for the work and identify real-world applications? 46 | - **Future directions**: The Turing seeks to build open source infrastructure that is accessible to all. Does the project reflect the principles of openness, reproducibility, and co-creation that ensure a sustainable and meaningful research output? 47 | 48 | ##### The event timeline 49 | This was decided by working back from AIUK, to determine how much time we needed for each step. The final timeline was: 50 | - **January 23**: Call for pitches open 51 | - **February 17**: Submissions close 52 | - **February 24**: Finalists notified 53 | - **February 27 / March 6**: Training sessions for finalists 54 | - **March 14**: Rehearsal in Enigma 55 | 56 | ##### Judges 57 | Sourcing the judges was undertaken by the events nad parternships team, leveraging Turing's pre-existing network. 58 | Suitaible judges were identified who: 59 | - Represented different sectors (academia, private, public) 60 | - Were senior in their respective industries 61 | 62 | It was important to source an initial list of judges to include in the one pager. 63 | Further work was done with these judges as the event went on (see below) 64 | 65 | ##### Prizes 66 | An intiail list of prizes was identified for the winner. As there was no budget for this year's PitchFest, the prize list was focus on skill development, and spotlighting in Turing comms. 67 | 68 | Prizes included: 69 | - Public comms (including an announcement and blog post) on your research project 70 | - A mentoring session with the RAM team exploring impact & engagement 71 | - A Turing swag bag 72 | - The glory of winning the first-ever Turing PitchFest! 73 | 74 | Eventually a Turing bust was created as the trophy for the winner, which went down really well, this should be included in the future! 75 | 76 | The focus of PitchFest should be friendly competition, and the chance to learn how to pitch your work to a broad audience - for all those who take part. 77 | We therefore feel it important to not make the prize too large/swanky, as it may end up promoting the wrong message. 78 | 79 | #### Tasks 80 | - [ ] Create a one pager/application form that contains all relevant information, which included the following tasks: 81 | - [ ] Finalise and communicate the application process 82 | - [ ] Create an application form 83 | - [ ] Decide upon judging criteria 84 | - [ ] Decide event timeline 85 | - [ ] Identify and confirm initial list of judges 86 | - [ ] Identify and confirm prizes for winner 87 | 88 | 89 | #### Potential improvements 90 | ##### Application process 91 | - This could possibly be opened up to people outside the Turing in the future 92 | - We ended up only having one person present per pitch - this should be made clear at the application stage 93 | - Creating an FAQs to live on the one pager from common questions we had would be beneficial 94 | - Text pithces didn't work. Video or audio submission should be mandatory. 95 | This should be open for longer so people have more time to apply 96 | - It might be good to share an example good and bad application so people know what they are aiming for (the RAM team should create these) 97 | 98 | ##### Judging criteria 99 | 100 | ##### Event timeline 101 | - Everything felt a bit rushed and last minute. Whilst the application window was long enough, there could have been more time for finalist training, the rehearsal in Enigma and the main event. More details below. 102 | 103 | ##### Judges 104 | - The judges list ebbed and flowed as people became more or less available, beyond the initial application window. Confirming and cementing judges ahead of time would be preferable. 105 | 106 | ##### Prizes 107 | - With some more funding and preparation time better prizes could be offered, e.g. networking or skill development opportunities. However these should not be so large as to create too intense a competition, or risk excluding non-winners from good development opportunities. 108 | - We may also want to consider layered prizes, e.g. opportunities for those who apply, the finalists and the winner. 109 | 110 | ### Call for applications 111 | You can see [our collection of comms templates here](./comms-templates.md) 112 | 113 | #### Summary 114 | This part of the process was mainly focused on Outreach to possible applicants. 115 | 116 | PitchFest 2023 was open to anybody with a Turing affiliation, including any researchers working on a Turing project, Turing Fellows, and Enrichments Students. 117 | Researchers could apply either individually or as a project team. 118 | 119 | The main outreach focused on: 120 | - Posting in relevant Turing Slack channels 121 | - Asking PMU to forward the opportunity on 122 | - Hosting Office hours for anyone that had questions 123 | - Individual reachout to enrichment students via Slack 124 | 125 | We had a range of people apply, but decided to focus upon enrichment students specifically, as we felt they would be most receptive to the opportunity. 126 | Nevertheless, we had applications (17 in total) from both enrichment students and Turing researchers. 127 | 128 | All people that applied would probably be classified as early career researchers. 129 | This is what we expected, and may influence who you choose to reach out to! 130 | 131 | ##### Slack channel posting 132 | We had some general comms options that we shared in key Slack channels. 133 | 134 | You can see templates [here](./comms-templates.md). 135 | This may feel a little bit spam-y - remember that this is a cool opportunity that people should know about! 136 | 137 | ##### PMU outreach 138 | This was a more strategic attempt to get outreach across the Institute, asking the PMU team to share details of PitchFest with their respective programmes and project teams. 139 | 140 | This is worth doing, though it is hard to tell how much more impactful this is than using open channels like Slack. 141 | 142 | Templates [here](./comms-templates.md) 143 | 144 | ##### Office Hours 145 | We hosted Office hours twice during the application window. 146 | 147 | These were arranged quite ad-hoc, and basically involved us sitting in the kitchen of the Office and on a Zooom for people to come ask questions. 148 | 149 | Even though it was ad-hoc, there were still a handful of people who attended to ask questions about the application process so is worth doing. 150 | 151 | The second session we brought cookies to entice people to talk to us - which worked a treat! 152 | 153 | ##### Individual outreach 154 | One of the more effective strategies was to reach out individually to approx 100 enrichment students, using people who were part of the enrichment students channel on Slack. 155 | 156 | Although a manual time sink (unless you want to write a script for it...) it felt worth it from an individual engagement perspective. 157 | 158 | #### Tasks 159 | - [ ] Identify target audience and methods for engagement 160 | - [ ] Create comms templates so anybody on the team can do outreach 161 | - [ ] Create engagement tracker to determine who you have reached out to 162 | - [ ] Schedule at least one office hour for potential applicants to drop in to. 163 | 164 | #### Potential improvements 165 | - We didn't ask people how they heard about PitchFest. It may be good to include this as a question to answer on the application form. 166 | - A bit more planning and outreach for the Office Hours would likely be worth it. 167 | - Some more creative forms of outreach could be good. Or additional opportunities like Turing Town hall, advertising video etc. 168 | - If we decide to include non-Turing people, a lot more thought will be needed for this part of the process. 169 | 170 | 171 | ### Closing applications and judging process 172 | #### Summary 173 | After applications closed we went through the judging process. 174 | 175 | Firstly we thanked everybody who applied for applying, and let them know the timelines for when we would let them know of finalists. 176 | 177 | For the assessment process, we used a rubrik based on the judging criteria to initially shortlist the applications. 178 | At least two members of the team should be involved in this process. 179 | We then had a discussion as a team as to who our finalist would be. 180 | 181 | Once we had chosen the finalists, we emailed them with further information and instructions, mainly confirming: 182 | - They wanted to take part 183 | - They were free to be in person at AI UK 184 | - They signed up for finalist training (see below) 185 | - They could attend the practice event (see below) 186 | 187 | For all non Finalists, we emailed them with some further opportunities, including: 188 | - Possibly recording their pitch more formally after AIUK 189 | - Offering 50% off for AI UK 190 | - Feedback on their pitch 191 | 192 | 193 | #### Tasks 194 | - [ ] Close the application form 195 | - [ ] Email all those who have applied with further details about the judging process 196 | - [ ] Set aside time with the RAM and events team to shortlist finalists 197 | 198 | #### Potential improvements 199 | - Our judging criteria didn't quite deliver on exactly what we were looking for - having more testing of the judging criteria (e.g. maybe RAMs submit their own pitches and we learn from that what we're looking for) would make the process a lot more auditable 200 | - Mainly from a timing perspective we didn't follow up with formal recordings for those who applied. We should be careful to only offer what we wan deliver on! 201 | - You may want to create a more formal judging panel beyond your specific team 202 | 203 | ### Finalist training 204 | #### Summary 205 | We ran 1-1 training sessions for finalists over the course of a week. 206 | 207 | Finalists booked 30 minute slots over [Calendly](https://calendly.com/pitchfest/30min?month=2023-09). 208 | 209 | The structure of the session was: 210 | - Remind them of the judging criteria 211 | - Have them practice their pitch 212 | - Give group feedback in the room 213 | - Have them practice again 214 | - Cover next steps 215 | 216 | ##### Judging criteria 217 | We reminded them of the judging criteria, and how judging would work on the day at AIUK (judges provide feedback, audience votes for favourite). 218 | 219 | ##### Practicing their pitch 220 | Almost all finalists were nervous about doing this. 221 | However, we helped them understand the importance of starting to practice the pitch, and that its uncomfortable to do it for the first time but the best way to improve it quickly. 222 | We also timed the pitches to get pitchers used to the idea of being under time pressure. 223 | 224 | Some of them practiced more than once. 225 | This is definitely a case of reading the room and providing the appropriate level of support/feedback to pitchers. 226 | 227 | ##### Group feedback 228 | We started this part by asking the pitchers themselves how they thought the pitch went (what was good, what could be improved etc.). 229 | We then went around the room and shared some thoughts on how the pitch could be improved. 230 | 231 | This feedback ranged from delivery style, to restructuring the content, to suggesting including/dropping content. 232 | 233 | ##### Next steps 234 | Next steps included: 235 | - Working on asynchronous improvements to scripts on Google Docs (collaboratively with the RAM team) 236 | - Preparing for the rehearsal session 237 | - Making ourselves available for any final support questions in Collaboration Cafes 238 | 239 | We also emailed participants with key feedback from the session to help them improve their pitch 240 | 241 | #### Tasks 242 | - [ ] Get finalists to book into a training session 243 | - [ ] Plan the structure of the training sessions 244 | - [ ] Setup additional support mechanisms (e.g. script editing) 245 | - [ ] Record feedback on participants' pitches that can be shared with them afterwards 246 | 247 | #### Potential improvements 248 | - These sessions could benefit from being longer - perhaps 45 mins per participant 249 | - Ideally everyone should be in the room for this. Online can work but it's not the same, and participants need to practice pitching with an audience. 250 | - We provided ad hoc feedback on the day, which worked well. However RAMs going in with a more in-depth/expert knowledge on what makes a good presentation, that we can both feedback to pitchers and share resources with them, would be next level 251 | - Improving the scripts asynchronously was done as a last minute improvement, however was on of the most important bits of support we offered! Time should be given for this to be done properly, maybe over a week or two, with conscious input and feedback from a range of people. 252 | - After the fact, pitchers mentioned how they worked and shaped the pitch with their project teams. More structured feedback opportunities from project teams/experts could be introduced here to really take pitches to the next level 253 | 254 | ### Finalist reheasal session 255 | #### Summary 256 | The rehearsal session was hsoted in Enigma for 1.5 hours the week before AI UK. 257 | 258 | We required all participants to learn their pitches off by heart, and be present in the Office for the session. 259 | The tone of the session was a fun, safe space for pitches to practice their pitches and get feedback from other participants, and others in the room. 260 | 261 | We brought some snacks and kept it casual. 262 | We gave a brief intro presentation about what to expect at AI UK, before giving each participant a chance to give their pitch. 263 | We then opened the floor to feedback from those in the room, before giving participants the chance to practice their pitches again. 264 | 265 | This event should be hybrid so people can join online. 266 | 267 | #### Tasks 268 | - [ ] Book a big room for the rehearsal 269 | - [ ] Prepare the tone of the session (e.g. snacks, initial presentation etc.). Keeping the tone light and informal worked really well. 270 | - [ ] Ensure the right people are in the room to providfe feedback 271 | - [ ] Ensure you have an online facilitator 272 | 273 | #### Potential improvements 274 | - Due to the short-term warning, we didn't have many people attend the session who weren't involved in PitchFest. In the end this created quite a nice, safe environment for all participants to support each other. However, a possible improvement may be to get more people in the room to listen to pitches, and possibly someone senior from Turing. Another option is to have two rehearsal sessions, one with just the participants and a few others (keep the supportive, safe atmosphere) and one with a lot more Turing people (to practice the public speaking element). This could be a day event - morning with just the pitchers, lunch, afternoon with other Turing people. 275 | - More time should be given to plan and promote this 276 | 277 | ### PitchFest event at AIUK 278 | #### Summary 279 | The big day! 280 | 281 | Hopefully you would have a lot of event support for the day. 282 | We required all pitchers, judges and the host to arrive 30 minutes early back stage to be mic'ed up and prepare for their pitches. 283 | 284 | Participants gave their presentations in front of a static slide (they are not allowed any slides themselves). 285 | This was followed by feedback from a selection of the expert judging panel 286 | 287 | Audience vote was then cast by Slido, with the winner given on a folded piece of paper to the host. 288 | While the auidence was voting the judges were consulted on what makes a good pitch, good research, and what they understand impact to mean. 289 | 290 | The winner was then provided with a trophy, before giving a little speech. 291 | 292 | It would be good to sit in the front row to be available to help with any last minute preparations 293 | 294 | 295 | #### Tasks 296 | - [ ] Prepare posts to go out on institutional and personal socials 297 | - [ ] Create a one pager for judges to understand what is required from them, and also a cheat sheet for them on the day to score/keep notes on each pitch 298 | - [ ] Create a one pager/script for the host 299 | - [ ] Prepare the slides to go behind the pitchers 300 | - [ ] Be on hand to help with any last minute logistics 301 | - [ ] Prepare Slido for voting 302 | 303 | #### Potential improvements 304 | - It would've been good to have a space afterwards for everyone to come talk to the finalists. This could be a stall at AI UK, or some kind of reception outside the main room. It would be good for the RAM team to also be there to answer any questions 305 | - (A bit selfish), but it might be good to plug the RAM team/your team during the event - perhaps in the period when the audience is voting. 306 | - It would've been good to practice once with Pitchers on the stage itself before the event, so they could familiarise themselves with where to stand and also get a feel for the size of the room/audience 307 | - A prize for all finalists would be good - maybe PitchFest T-shirts? 308 | - For outreach ahead of time, it would be cool to hae some slides/graphics on the finalists that can be shared publicly to build hype, and give them some exposure 309 | - Judges should be given more time to be booked into PitchFest, and told what they will need to do 310 | - It might be cool to have last year's winner be a judge at the next one! 311 | 312 | ### Wrapping up and next steps 313 | #### Summary 314 | There were a few things we actioned after the event, including: 315 | - A debrief with the finalists 316 | - A debrief with the organising team 317 | - Comms through the Turing network about the winner 318 | 319 | ##### Debrief with finalists 320 | This was really important to get finalists feedback on how the process went, what could be improved for next time and also to get some stories of their experience we could use for promotion (which we never did) 321 | 322 | ##### Debrief with organising team 323 | Hopefully obvious, key to do this soon after the event whilst it's still on everyone's minds and you can record possible improvements 324 | 325 | ##### Comms through Turing networks 326 | Make sure you know what this will look like ahead of time 327 | 328 | #### Tasks 329 | - [ ] Decide what you will offer all participants (winner, finalists, non-finalists) ahead of time 330 | - [ ] Ensure all processes are in place to deliver on these offerings 331 | - [ ] Hold debrief sessions with both finalists and the organising team soon after the event to capture feedback 332 | - [ ] Claim back all relevant expenses 333 | 334 | #### Potential improvements 335 | - We ran out of steam a bit at this stage. Figuring out what we can offer finalists and participants ahead of time and planning for it is a critical improvement for next time 336 | - It would've been cool to do a blog post/article or something on PitchFest that we could've shared with people afterwards, including quotes from those who took part. This would embed PitchFest and its awesomeness further in the public psyche 337 | - Some things became difficult to organise (e.g. recording all pitches and sharing them on the Turing YT) because we didn't organise them in advance. Making sure this is all prepared in advance is important, otherwise you risk letting this slide like we did. 338 | -------------------------------------------------------------------------------- /resources/project_ram/RAM_1pager.md: -------------------------------------------------------------------------------- 1 | # Research Application Management 2 | ## Amplifying Sustainability and Impact of research outputs 3 | 4 | The [RAM role](https://the-turing-way.netlify.app/collaboration/research-infrastructure-roles/ram.html) was pioneered at the Turing in order to **fill the gap** between academic knowledge generation and practical tool creation. 5 | RAMs collaborate with research teams to make their research output **more relevant** for a broad audience within and beyond the scope of the original research field. 6 | By focusing on the **user perspective**, RAMs increase the **sustainability** and the **impact** of research outputs. 7 | 8 | Are you a researcher interested in amplifying the impact of your work? Engage with the RAM team at any stage of your project, but the earlier, the better. We'll integrate impact into your project plan from the start. Check out our impact matrix below to see if your project could benefit from working with a RAM. 9 | 10 | ## What project impact have RAMs delivered? 11 | * Open sourcing the [Data Safe Haven](https://www.turing.ac.uk/research/research-projects/data-safe-havens-cloud), bringing the community together to co-create [a reference TRE architecture](https://github.com/sa-tre/satre-specification) and creating a [national community for Trusted Research Environments](https://github.com/uk-tre/website) 12 | * Integrating A/B street for [use in a Bristol City Council public consultation tool](https://www.turing.ac.uk/blog/street-smart-putting-neighbourhood-design-hands-bristol-residents) to empower residents to design and assess street-level interventions in their neighbourhoods 13 | * Delivering cross-sector workshops with government and industry stakeholders in 'Health' and 'Autonomy' fields on behalf of the [AI Standards Hub](https://aistandardshub.org/) 14 | * Creating [PitchFest at AI UK](https://www.turing.ac.uk/news/first-pitchfest-winner-announced-ai-uk-2023) to upskill Early Career Researchers to communicate the impact of their research to a public audience 15 | * Co-authoring public-facing whitepapers on Turing's [Environment & Sustainability](https://www.turing.ac.uk/news/publications/tackling-climate-change-data-science-and-ai) and [Digital Twins](https://www.turing.ac.uk/news/publications/towards-ecosystems-connected-digital-twins-address-global-challenges) research 16 | 17 | ## What makes for an impactful RAM engagement? 18 | In our **RAM impact matrix**, we consider multiple dimensions of a research project and team to prioritise engagement across Turing's research projects: 19 | * **Applicability**: How much potential does the research project have for real-world use? 20 | * **Capability**: To what extent does the team have the skills to translate their research to real-world use? 21 | * **Values**: How much does the team's approach to research align with our focus areas within the [Tools, Practices, and Systems (TPS) programme](https://www.turing.ac.uk/research/research-programmes/tools-practices-and-systems)? (e.g. interoperable open source tools, interdisciplinary collaboration, participatory co-creation) 22 | * **Practices**: How ready is the team to adopt RAM ways of working? 23 | 24 | ![RAM impact matrix](https://github.com/alan-turing-institute/research-application-management/assets/5104098/1c18c514-02c2-434e-abc1-dfcdff3769ba) 25 | 26 | ## What do RAMs bring to research teams? 27 | 28 | Effective research has the potential to do more than answer a specific research question. For a project to maximise its impact, the team should consider questions like: 29 | - Who might use this research when it is completed, and how might they benefit from it? 30 | - Who will be affected by the research, and what outcomes would they like to see? 31 | - Does the research project consider sustainability beyond a specific funding window? 32 | - How does the work fit into the wider landscape of research in my field and other fields? 33 | 34 | The RAM skillset is focused on effectively exploring and answering these questions. Below are some examples of what this could entail: 35 | 36 | | Focus area | Motivation | Example activities | 37 | | ---------- | --------- | ------------------ | 38 | | End-to-end stakeholder engagement and co-creation | Ensuring that all impacted and involved people, particularly end users, are identified early, brought into the research project and actively considered when shaping outputs | Stakeholder mapping; stakeholder engagement pipelines; organising, facilitating and managing engagement activities; translating engagement outcomes to inform research | 39 | | Usability and accessiblity of research outputs | Ensuring that anybody who wants to can access and engage with the research outputs | Writing cleaner, easier to understand code; creating documentation, guides and educational resources to support core research outputs; open-sourcing research datasets, models, and other outputs (when possible) | 40 | | Delivering project strategy | Prioritising work to practically realise as much potential as possible from limited resources, funds and time | Facilitating the creation of a team strategy and project roadmap; identifying sustainability options beyond funding windows; identifying and implementing a target project pathway to maximise impact potential | 41 | 42 | A key characteristic of RAMs is our flexibility, as there is no one-size-fits-all approach to delivering impact for research project teams. RAMs will work to identify suitable pathways to sustainability and impact for any particular project, and leading on the implementation of that target pathway. 43 | 44 | Learn more about our stakeholder engagement activities and access our insights [here](https://the-turing-way.netlify.app/collaboration/stakeholder-engagement.html). 45 | 46 | ## Get in Touch 47 | To learn more about RAMs or how to apply RAM methodologies in your research project, get in touch with our team at RAM@turing.ac.uk. 48 | 49 | -------------------------------------------------------------------------------- /resources/project_ram/framework/ram-rhombus-0.1.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 |
Governance
Governance
Ways of working
Ways of work...
Team structure
Team structu...
OPERATIONAL ALIGNMENT
OPERATIONA...
How much change can a RAM realistically implement? 
How much change can a RAM real...
PERFORMANCE
PERFORMANCE
How much is the team already delivering on RAM focus areas?
How much is the team already d...
VALUE ALIGNMENT
VALUE ALIG...
How much do the team embody RAM values?
How much do the team embody RA...
IMPACT POTENTIAL
IMPACT POT...
How much potential do we perceive for real-world use of the research?
How much potential do we perce...
Participatory science
Participator...
Co-creation
Co-creation
Reproducibility
Reproducibil...
Use cases
Use cases
Resources
Resources
Adaptability
Adaptability
Stakeholder landscape
Stakeholder...
Timescales
Timescales
Stakeholder engagement
Stakeholder...
Reusable outputs
Reusable out...
Accessible resources
Accessible r...
Project design
Project desi...Text is not SVG - cannot display 5 | -------------------------------------------------------------------------------- /resources/project_ram/framework/ram-rhombus-0.2.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 |
PRACTICES
PRACTICES
How ready are the team to adopt RAM ways of working?
How ready are the team to adop...
APPLICABILITY
APPLICABIL...
How much potential does the research have for real-world use?
How much potential does the rese...
CAPABILITY
CAPABILITY
To what extent does the team have the skills to translate their research for real-world use?
To what extent does the team h...
VALUES
VALUES
How much does the team's approach to research align with ours?
How much does the team's appro...Text is not SVG - cannot display -------------------------------------------------------------------------------- /resources/project_ram/framework/ram-rhombus-0.3.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 |
PRACTICES
PRACTICES
How ready are the team to adopt RAM ways of working?
How ready are the team to adop...
VALUES
VALUES
How much does the team's approach to research align with our focus areas within the TPS programme?
How much does the team's appro...
APPLICABILITY
APPLICABIL...
How much potential does the research project have for real-world use?
How much potential does the research...
CAPABILITY
CAPABILITY
To what extent does the team have the skills to translate their research to real-world use?
To what extent does the team h...Text is not SVG - cannot display -------------------------------------------------------------------------------- /resources/project_ram/interviews/index.md: -------------------------------------------------------------------------------- 1 | # RAM project interviews 2 | 3 | The aim of the interviews is two-fold: 4 | - To help us flesh out a framework for prioritising projects RAMs can work with 5 | - To gain a wider understanding of Turing research projects and their approaches to key questions (impact, values, governance etc.) 6 | 7 | The end-to-end process for carrying out interviews is: 8 | 9 | 1. [Identify project teams to interview](#identify-project-teams-to-interview) 10 | 2. [Schedule the interview](#schedule-the-interview) 11 | 3. [Carry out the interview](#carry-out-the-interview) 12 | 4. [Store the notes on this repo](#store-the-notes-on-this-repo) 13 | 5. [Analyse the notes](#analyse-the-notes) 14 | 6. [Carry out follow on actions](#carry-out-follow-on-actions) 15 | 16 | ## Identify project teams to interview 17 | 18 | The interviews, when taken all together, should provide a broadly representative view of the current research landscape at the Turing Institute. 19 | 20 | Check the [interview notes](./interview_notes.md) document to see which projects have already been interviewed - and don't interview them again! 21 | 22 | We should also be prioritising projects that: 23 | - Come from programmes we currently have not interviewed 24 | - Are doing very different work from projects we have already interviewed 25 | - Are both involved and not involved with RAMs and TPS already 26 | 27 | Whilst it could be useful to also interview people about projects that have now finished, that is beyond the scope of these interviews 28 | 29 | ## Schedule the interview 30 | 1 RAM should be enough to carry out each interview - however feel free to team up with more than one RAM if you think it would be helpful! 31 | 32 | We recommend minimum 30 minutes per interview. 33 | Whilst longer conversations can be scheduled, it would be better to ensure an interview takes place for 30 minutes than to risk missing an interview because the interviewee can't dedicate any more time 34 | 35 | ## Carry out the interview 36 | Use the [interview template](interview_template.md) to structure your conversation. 37 | 38 | These interviews are [semi-structured](https://delvetool.com/blog/semi-structured), meaning they don't have to follow verbatim the template - make a copy of the template and tweak it as you see fit for your interview, and don't worry about hitting all the questions if you don't have time! 39 | Just be sure to make a record of where you got to, and how the format/structure can be changed to maximise the usefulness of the interviews going forwards. 40 | 41 | All the content from the interivew should be captured in written notes. 42 | Check with the interviewee they are happy for you to take notes throughout the session. 43 | If they are also happy to be recorded, you may want to do this to help you with writing up notes afterwards. 44 | Ensure you check with the interviewee first, and make clear how the recording will be used (just by the RAM to transcribe any notes you missed during the session, and then they will be deleted) 45 | 46 | Also check whether the interviewee is happy for their anonymised notes to be made open, and record their response. 47 | 48 | ## Store the notes on this repo 49 | Ensure that any link to notes you share in the [interview notes doc](./interview_notes.md) is only accessible to the RAM team. 50 | 51 | Any public/open version of the notes must be stripped of all identifiers before being made open. 52 | 53 | ## Analyse the notes 54 | The analysis process for the notes should be undertaken by two RAMs. 55 | 56 | The RAMs should independently carry out [thematic analysis](https://delvetool.com/blog/thematicanalysis) on the interview. 57 | They should then come together to compare their analysis, before combining their work into one comprehensive analysis of the interview. 58 | A link to this analysis should be made available alongside the interview notes in the [interview notes file](./interview_notes.md) 59 | 60 | ## Carry out follow on actions 61 | The process of analysing the interviews will likely surface some ideas on how to improve/adapt the RAM framework and interview templates. 62 | Use the `Project RAM` issue template to start a discussion on these changes! 63 | -------------------------------------------------------------------------------- /resources/project_ram/interviews/interview_notes.md: -------------------------------------------------------------------------------- 1 | # Note of notes for Interviews 2 | 3 | ## Links 4 | - [2023_11_08_OpenLimb](https://thealanturininstitute-my.sharepoint.com/:w:/g/personal/fgomezmedina_turing_ac_uk/EeISQWEQBQVArIOQ7SUEwdUBHrllYqCkHPS4fWy9yx7iqg?e=93faTw) 5 | - [2023_21_08_UATP](https://hackmd.io/@jending12/HJr_6neTh) 6 | 7 | -------------------------------------------------------------------------------- /resources/project_ram/interviews/interview_template.md: -------------------------------------------------------------------------------- 1 | ## Method 2 | - Interview X number of Turing research projects to understand where they are currently at with key questions 3 | - Interview at least one person per project 4 | - Ideally the PI, but if hard to pin down anyone from the research team 5 | - 30 or 45 min semi-structured interviews 6 | - Interviews don't need to follow set question order/format 7 | 8 | ## General questions 9 | *Do some background research on the project to make this less formulaic and extractive* 10 | - Can you provide a _quick_ summary of your project? 11 | - Can you describe the current status of your project and what you are building towards? 12 | - Who your partners/key relationships are/were? 13 | - How much funding you have/had and where it comes from? 14 | - And how long your project is running for? 15 | - Your team make up (size and roles)? 16 | 17 | ## Impact potential 18 | - What motivates your research question? 19 | - Where do you hope your research will end up? 20 | - What does impact and/or success mean to you for your project? 21 | - What are you doing now to try to achieve this impact/success? 22 | - What is preventing you from achieving this impact? 23 | 24 | ## Operational Alignment 25 | - What is your current way of working? 26 | - What is your current governance structure for the project? 27 | - What roles do you see as important to have on your team? 28 | 29 | 30 | ## Values 31 | - How much do you think about/have you thought about 32 | - Open, reproducible outputs? 33 | - Co-creation with the end user? 34 | - Participatory science? 35 | - What is your approach to research and research outputs? 36 | - Do you follow any particular best practices/frameworks in your work? 37 | - 38 | - Are you willing to forego your work to incorporate it within a larger project? 39 | - Are you willing to have this research used in ways outside of your control? 40 | - Are you comfortable with 'free-riders'? 41 | - Are you willing to use pre-existing tools/platforms etc. to augment your project? 42 | 43 | ## Performance 44 | ### Audience 45 | - Do you know who your audience/users are? 46 | - Where those who will use it already are 47 | - Where those who regulate it already are 48 | - Where those that make decisions based on it already are 49 | - Where those that are impacted by it already are 50 | - Do you know where these people are? 51 | - Are you already engaged with these people and these places? 52 | - Do you know what people in these spaces need? 53 | - Does your work align with/relate to other community work? 54 | - Was the question for the research asked by this community or not? 55 | - Do you regularly communicate with your community? 56 | 57 | ### Accessibility & openness 58 | - Do you have documentation for people to learn about your project? 59 | - Do you have educational resources available for those interested to upskill and engage? 60 | - Do you proactively make openly available all aspects of your project that can be? 61 | 62 | ### Reusability 63 | - Are others able to pick up your projects easily? 64 | - Is it clear what skills and resources you need to pick up these projects? 65 | - Do you know what operating models could be used to sustain this work? 66 | - Are barriers to re-use factored in to your team's approach? 67 | 68 | ### Sustainability and scope 69 | - Do you know where your research ends and where next steps begin? 70 | - Does your aims/goals of the research match your funding windows/resources available? 71 | - Are you prepared for funding for your project to cease? 72 | - Do you know what your minimum, non-negotiable level of success is? 73 | - Do you know when the research project is officially done, and it's potential/impact has been realised? 74 | 75 | ### Governance 76 | - How can people outside the project team get involved with the project? 77 | - How will people be able to get involved once the project funding has finished? 78 | 79 | ### Project design 80 | - Do you have a project roadmap? 81 | - Do you have collaborative workspaces set up? Version control? 82 | - Do you have an organised and explicit way of working within your project team? 83 | - Do you know what outputs you are aiming for from your project? 84 | 85 | ### Thoughts 86 | #### How to pitch this 87 | - Forwarding TPS and RAM goals within the Institute 88 | - This is also a chance to share what the RAMs do and what we're here to do 89 | - They might just enjoy the process of telling people about their research 90 | - Can we do a bit of research on the side, and mention something that they are already struggling with 91 | 92 | -------------------------------------------------------------------------------- /resources/project_ram/project_impact_metrics.md: -------------------------------------------------------------------------------- 1 | # Project Impact Metrics 2 | 3 | ## Checklist 4 | 1. Identify organisational goals - Turing, Stakeholder(s), Research Team, Research Collaborators 5 | 2. Consider opportunities for overlapping priorities to define Project Goals 6 | 3. Create Project Goals tracking sheet 7 | 8 | ## Defining Metrics 9 | 10 | Here are a set of potential metrics to use for different kinds of stakeholders: 11 | 12 | ### General 13 | - [ ] **Before/After**: how does a specific task or experience compare before/after the project? 14 | - [ ] **Target Audience**: who benefits from this project and how? 15 | - [ ] **Stickiness**: do users/stakeholders of the project continue using the output? 16 | - [ ] **Net Promoter Score**: how does the project impact user/stakeholder perceptions of the Turing? 17 | 18 | ### Industry 19 | -[] **Revenue/Cost**: how does the project contribute to **reducing costs** or **increasing revenue**? 20 | -[] **Efficiency**: how does the project help save time, energy, or resources? 21 | 22 | #### Major Corporation 23 | - [ ] **Leadership Testimonial**: quote from C-suite or Director on the impact of the project on the company. 24 | 25 | #### Startup 26 | - [ ] 27 | 28 | ### Government 29 | - [ ] **Public Good**: how does the project contribute to the benefit of public space (e.g. streets, parks, environment), 30 | transportation systems, economic systems, experience of daily life, or anything else impacting the general public? 31 | - [ ] **Levelling up**: how does the project contribute to improving the skills and expertise of government/public sector players? 32 | 33 | #### National Government 34 | - [ ] **Policymaking**: how does the project support the shaping of national policy or guidance? 35 | 36 | #### Local Government 37 | - [ ] **Public Engagement (Resident)**: how does the project improve the experience of public interaction, dialogue, and understanding of local government? 38 | - [ ] **Public Engagement (Government)** how does the project improve local government 39 | 40 | ### Academia 41 | - [ ] **ECR Advancement**: how does the project highlight or spotlight the work of an ECR? 42 | 43 | #### UK University Partner 44 | - [ ] 45 | 46 | #### Non-UK University Partner 47 | - [ ] 48 | -------------------------------------------------------------------------------- /resources/stakeholder_workshops/requirements_gathering.md: -------------------------------------------------------------------------------- 1 | # Requirements Gathering Questionnaire 2 | Example: Alignment on "Case Study" Definition and Generation Process 3 | 4 | ## Form 5 | - What kind of document or media is the case study? 6 | - Where do users access the case study? 7 | - Can you walk me through the flow of how a user ideally consumes the case study? 8 | 9 | ## Content 10 | - What is the aim of your use case? 11 | - What are the core components of a case study? (e.g. title, overview, key considerations, prompts, datasheet, key individuals, image) 12 | - Who participates in contributing the core content? 13 | - Who else do you hope will contribute core content? 14 | - Can you walk me through the process of creating a case study 15 | - Which points are bottlenecks, if any? 16 | 17 | ## Stakeholders 18 | - Who is the target stakeholder for the case studies? 19 | - What currently draws them to the case study? What are their goals? 20 | - What do you hope they take away from the case study? 21 | 22 | ## General 23 | - What is the most successful case study to date? 24 | - What are your team's goals around case studies this year? 25 | - Why? And how do you measure success? 26 | - What case studies are on deck to be delivered this year? 27 | - Where do case studies exist after published? 28 | -------------------------------------------------------------------------------- /resources/stakeholder_workshops/stakeholder_workshops.md: -------------------------------------------------------------------------------- 1 | # Stakeholder Workshop Checklist 2 | 3 | **Pre-workshop:** At this stage all activities that need to happen before the workshop should be completed. 4 | * Identifying a group of participants (e.g., stakeholder mapping) 5 | * Obtaining specific contact details 6 | * Sending formal invitations with all neccessary information (e.g., background, purpose, obtaining consent, ethical considerations, location, etc) 7 | * Capturing all neccessary participant data in line with legal requirements (e.g., personal details, dietary requirements, etc) 8 | * Planning the workshop execution and post-workshops stages in line with the purpose, objectives and outcomes 9 | * Having contingency plans for identified risks (e.g., limited acceptances from participants) 10 | * Consider a location which is appropriate for all participants to be included taking into account any special requirements 11 | * Consider hybrid options for all inclusive participation 12 | * Have all digital tools and hardcopy resources ready with contingency plans in-place especially for technology failures 13 | * Be clear in how output will be captured from the participants (e.g., scribes, video/audio recordings, etc) 14 | 15 | **During workshop** 16 | 17 | * Setup equipment at the location according to the plan for the day (e.g., seating) 18 | * Test all technology and take stock of required resources prior to arrival of participants 19 | * Register attendees as they arrive and disseminate any resources (e.g., documentation, name badges, etc) 20 | * Where possible, actively engage all participants with opportunities to provide input, especially those who appear to be reluctant to engage 21 | * As the organiser, exercise a disciplined approach that adheres to the time-scales assigned to activities ensuring regular breaks 22 | * Consider the following activities as part of the workshop format: 23 | * Welcome & Introductions 24 | * Setting the scene, background, aims & objectives and logistics for the day 25 | * Presentation of pre-requisite knowledge through an appropriate format prior to engaging participants 26 | * Plenaries at the end of each session 27 | * Dedicated session for next steps 28 | * Final remarks from the organisers 29 | 30 | **Post-workshop** 31 | 32 | * Send a follow up survey requesting feedback 33 | * Where possible, forward resources used on the day 34 | * Once outcomes have been realised communicate these 35 | -------------------------------------------------------------------------------- /resources/team_strategy/facilitator_notes.md: -------------------------------------------------------------------------------- 1 | # Facilitator notes 2 | 3 | These notes are a comprehensive guide on how to use all our team strategy templates *as presented here*. 4 | They contain both information on how to run the sessions as presented operationally (Facilitator notes), as well as insights and lessons learned from the RAM team and contributors when using them (Insights). 5 | 6 | > :warning: **NOTE**: These templates are being dynamically built through direct usage across project teams and contexts. They are **not** a definitive source of truth on how to run successful strategy sessions for your team. They are more intended as starting points for you to amend/use as required. Any improvements or changes you make, please contribute them upstream back to this repository, so we can spread the love on effective team strategising! 7 | 8 | These notes are a deeper dive than other resources we have. For an overview of our approach, see [this page](./index.md) or our [subchapter in the Turing Way](https://the-turing-way.netlify.app/collaboration/stakeholder-engagement.html#strategy-alignment-workshops). 9 | 10 | ## Before any sessions 11 | 12 | ### :check_mark_button: Facilitator notes 13 | There are a number of things to make sure you have in place before undertaking any sessions. 14 | * **Schedule for all sessions**: You should know how many sessions you plan to run, when you plan to run them, and schedule these as much in advance as possible. This guide is designed for 4 x 2 hours sessions, which we recommend scheduling over approximately 1/1.5 months. However this will need to flex depending on the needs and availability of your team. One option would be to have an initial session, and afterwards determine what future sessions are required. 15 | * **Participant engagement and review**: The most important part of pre-session work. Ensure you understand the needs, wants and aims of your participants, as well as their approach to this work. If they are fully bought in and have time, you can likely run more, in depth sessions. If they are busy/not fully bought in, you might need to pick on or two key sessions to run. You should also get feedback on your proposed strategy plans ahead of any session, to ensure co-creation of team strategy from the very beginning. 16 | * **Number of facilitators**: We recommend ensuring there are at least two facilitators for any session - one to chair the session, and one to help with note-taking, assigning breakout rooms, identifying people who haven't shared much etc. 17 | 18 | ### :bulb: Insights 19 | * **Empowering/equal voices**: Set up the sessions from the very beginning to focus on empowerment of team members. This can include only speaking with a raised hand, setting a standard of maximum time to speak at one time (e.g. 2 minutes), prioritising those who have not shared much, having multiple ways to share thoughts (speaking, in a chat, on a document or note). Getting this wrong can mean people not buying into the strategy or feeling they are part of it, which can be disastrous for building a cohesive strategy. 20 | * **Focus on live facilitation**: This guide is relatively open and unstructured, with a strong focus on effective in-person facilitation. We find this to be a good approach, as it means momentum can be built live within the workshop, rather than asynchronously afterwards. However we understand this is more resource intensive, so please adapt the approach as best fits your need! 21 | * **Review only what was covered in sessions**: When synthesizing/clarifying discussions between sessions (see below), it is crucial to ensure no new context/information is created or included. This ensures that the team is fully involved with all aspects of how the strategy is created, and the process of creation is truly co-creative and transparent. 22 | * **Give conversations the time they need**: Linked to the point below, but we find it most effective to allow conversations the time they need - if there is strong disagreement, prioritise moving towards a place of alignment over getting all parts of the session completed. 23 | * **Checkpoints/don't revisit approach**: If alignment is reached, you should have natural checkpoints at the end of each session. If done effectively, it means you should be able to reach a new foundation after each session. It is always good to be able to revisit any checkpoints with fresh eyes. However, at some point it should be made explicit that this is the last point of revisiting, before moving on. Being firm on not revisiting old points beyond this will help ensure continued progress in each session. 24 | * **Asynchronous work**: Some tasks can be completed asynchronously. For this to be effective, the asynchronous work needs to be well defined. For instance, landing on a 'vision' statement in a workshop session that needs refining is a good candidate for asynchronous work (e.g. in a Slack thread), but 'define the team vision' with no anchor would not be. 25 | 26 | ## Session 1: Why 27 | *Recommended time: 2 hours* 28 | 29 | 30 | ### :page_facing_up: Facilitator notes 31 | 32 | * [Template HackMD](https://hackmd.io/W58xq3sfSzG5DgQvcZaGwQ) 33 | 34 | ### :bulb: Insights 35 | * **Importance as a foundation**: An agreed upon, strong 'North Star' is crucial for any strategy work to progress. Ensure you allow time for conversations, and spend time on language/wording to make sure everybody is happy. This is the most important session to have an agreed upon, clear output from. 36 | * **Managing conversation**: When you bring everyone back together, decide whether to allow people to continue to add thoughts, or to park cursors and focus on discussion. You can choose what works best for you as a facilitator, and what would work best for the team (some people may prefer to add thoughts via notes than to speak out loud). 37 | 38 | ### :writing_hand: Facilitator Review 39 | * Synthesize the session down into one final 'North Star' 40 | 41 | ## Session 2: How 42 | 43 | ### :check_mark_button: Overview 44 | **Aim**: 45 | **Structure**: 46 | 47 | ### :page_facing_up: Facilitator notes 48 | 49 | ### :bulb: Insights 50 | 51 | ## Session 3: What (part 1) 52 | 53 | ### :check_mark_button: Overview 54 | **Aim**: 55 | **Structure**: 56 | 57 | ### :page_facing_up: Facilitator notes 58 | 59 | ### :bulb: Insights 60 | 61 | ## Session 4: What (part 2) 62 | 63 | ### :check_mark_button: Overview 64 | **Aim**: 65 | **Structure**: 66 | 67 | ### :page_facing_up: Facilitator notes 68 | 69 | ### :bulb: Insights -------------------------------------------------------------------------------- /resources/team_strategy/index.md: -------------------------------------------------------------------------------- 1 | # Team strategy documentation 2 | 3 | ## Introduction 4 | 5 | The RAM team has developed some template documents, guidance and resources for running team strategy sessions. 6 | An overview of these sessions can also be found in [the Turing Way](https://the-turing-way.netlify.app/collaboration/stakeholder-engagement.html#strategy-alignment-workshops). 7 | 8 | This folder is a comprehensive collection of everything required to get started planning your own sessions, including: 9 | 10 | * [**Facilitator notes**](./facilitator_notes.md): Guidance on how to run each session 11 | * [**Miro notes**](./miro_notes.md): Guides on how to use our [Miro template](https://miro.com/app/board/uXjVMD7H9-Q=/) 12 | * [**Resources**](./resources.md): Links to all useful resources, including Miro, HackMD, presentations and more 13 | 14 | ## Overview 15 | ### Aims 16 | 17 | The aim of this session is to align a project under a shared team strategy. 18 | The output from these sessions should be a clear understanding of the team's vision, core focus areas (or 'pillars') and the work that needs to be done to achieve this vision. 19 | This could be in the form of a presentation, one pager, paper, blog post or something else. 20 | For the templates, we are using a presentation. 21 | 22 | In order for these sessions to be successful, it is important to focus on two main areas: 23 | 1. **Individual empowerment**: Providing the spaces, structures and opportunities for team members to share their, and understand others, core motivations and visions for the project. 24 | 2. **Team alignment**: Carving a path forward for the team that encompasses the core aims and desires of all team members. 25 | 26 | A team strategy can only be successfully implemented if there is buy-in across the team. 27 | Focusing on these two areas will ensure you run sessions that maximise the chance of a successful strategy being formed. 28 | 29 | ### Design 30 | 31 | This RAM exercise is infomred by Simon Sinek's [Golden Circle method](https://www.smartinsights.com/digital-marketing-strategy/online-value-proposition/start-with-why-creating-a-value-proposition-with-the-golden-circle-model/), where the team approaches their work in the following order: 32 | * **Why**: Why are we doing what we're doing? 33 | * This is the ultimate 'North Star' or 'vision' of the project - the fundamental, emotive reason the work is being done 34 | * **How**: How do we achieve our mission? 35 | * This question concerns the broad focus areas, or 'pillars' that setup up the project to achieve the vision 36 | * **What**: What do we actually do? 37 | * This question takes the why and the how, and identifies key activities teams can undertake to achieve their goals 38 | 39 | We think it is important to take these in order and identify work from the bottom up, rather than guessing at important work and assigning it top-down. 40 | 41 | #### Why 42 | This should be the most uncontroversial part of defining a team strategy. 43 | A team should be able to align themselves under a shared vision practicable and realisable in the real-world - if they can't achieve this they will not easily be able to determine what work is important to the project's aims and what isn't. 44 | It is worth having an entire session on the why, to ensure everyone is aligned. 45 | This will ensure the team has strong foundations to fall back on when answering more difficult questions in future sessions. 46 | 47 | Additionally, it can be helpful to distinguish between a team vision vs. a mission: 48 | - Vision is the emotive, long-term aspirations for the project, and the fundamental reason why the project exists 49 | - Mission is how to get there, a soft and broad pathway towards the vision 50 | 51 | It is likely this session will contain discussions around both the vision and the mission, which can be incorporated together into a guiding 'North Star' for the project. 52 | 53 | ##### Intended output 54 | * One sentence (or very short) vision and mission 55 | 56 | #### How 57 | This is the crucial step for turning the shared vision into clear pathways forward. 58 | It should include frank discussions on what work matters, what doesn't, and what feeds into the vision. 59 | This is likely to build upon themes/discussion points that arose in the 'Why' section. 60 | 61 | The aim fo the 'How' section is to determine the broad 'pillars' of the project - the areas of work the project team will focus on to help achieve their 'North Star'. 62 | The identification of more concrete work and activities within these pillars is part of the 'Why' Section. 63 | 64 | Whilst the 'why' is a sentence, the 'how' should be a visualiation or similarly simple presentation highlighting the key focus areas of a project, and how they relate to each other. 65 | For instance, are pillars connected in a hierarchy, stemming from one key focus area? Are they independedent (like a spider diagram) or are they all interconnected (like a Venn diagram). 66 | 67 | Once these pillars have been identified and agreed upon by the project team, the next part of this section is to identify 'measures of success' for each pillar. 68 | These are similar to 'Key Performance Indicators' (KPIs) - measures that allow the team to understand how well they are doing in each pillar. 69 | 70 | > :bulb: **RAM insight**: Especially in the research context, these measures do not have to be defined numerically (as KPIs often are). For instance, a 'measure of success' might be 'open communication spaces, which might not be best represented by 'number of new issues on GitHub' (are issues the best way to measure engagement) or 'number of users on Slack (are they contributing to discussions). If you can land on a numerical, definable measure, great! But be careful of [vanity metrics](https://review.firstround.com/im-sorry-but-those-are-vanity-metrics), and understand it is ok to not yet know how to best present your measure of success. 71 | 72 | These success measures will be crucial in helping identify activities the team should undertake. 73 | They should be categorised under one of the pillars - if there isn't one they belong under, is it the right measure for the project? Or if it is, do you have the right pillars? 74 | 75 | ##### Intended output 76 | * Visualiation/outline of 'pillars' that highlight key focus areas and their relationships 77 | * Clear 'measures of success' for each pillar 78 | 79 | #### What 80 | This activity will tie together previous discussions and lead to the identification of key activities for the project team to undertake. 81 | This is likely to be the most difficult of the three sections, as it requires relatively brutal prioritisation of work, allocating responsibilities and deciding ways of working. 82 | 83 | If done successfully, by the end of this session the team should be clear on what work needs to be done, how it fits into their identified pillars, and how it moves the project team towards their ultimate vision. 84 | 85 | This is also likely to be the most dynamic/flexible of the sections - whilst we recommend regular (for instance, quarterly) review of the full team strategy, it is crucial to regularly review the activities being undertaken and whether they are still right. 86 | This is especially important as certain activities will reveal new knowledge/insights that may reshape project priorities. 87 | 88 | Once activities have been identified and allocated amongst the team, it is important to set aside time to agree upon ways of working. 89 | This is very context dependent, and the granularity of this conversation can be tweaked based on the working patterns of the project team. 90 | Discussions to include here are what project management methodology (if any) the team will use (e.g. agile, scrum or something else), what meetings the team will have, where resources and documentation will be stored and shared, and more. 91 | 92 | ##### Intended outputs 93 | * Core project activities, and an understanding of how difficult they will be to action. These should be definable activities that can easily be marked as 'in progress' or 'completed' (for instance, 'greater engagement' would not be a good activity (hard to mark as completed), but 'establish a schedule of fortnightly community calls' would be better) 94 | * Responsibility mapping of activities - which activites sit with which team, and expected time/resource required to action them 95 | * Ways of working - identifying the patterns of working that will allow the team to efficiently and effectively action all established activities. 96 | 97 | ## RAM templates 98 | 99 | The RAM team are dynamically and iteratively building a set of templates for sessions using these design principles to reproduce, use, and contribute improvements to. 100 | If you wish to dive into these templates, check out: 101 | * [Facilitator notes](./facilitator_notes.md) - an in-depth guide to running sessions, including lessons learned and RAM insights 102 | * [Miro notes](./miro_notes.md) - documentation on how to use the [template Miro board](https://miro.com/app/board/uXjVMD7H9-Q=/) 103 | * [Resources](./resources.md) - links to template -------------------------------------------------------------------------------- /resources/team_strategy/strategy_case_studies/index.md: -------------------------------------------------------------------------------- 1 | # Team strategy case studies 2 | 3 | * Data Safe Haven (to be added) 4 | -------------------------------------------------------------------------------- /resources/training_materials/mkdocs_workshop_recap.md: -------------------------------------------------------------------------------- 1 | # MkDocs Workshop Recap 2 | 3 | **Date:** 8 December, 2023 4 | **Workshop Leader:** Kalle Westerling 5 | **Recording:** https://thealanturininstitute.sharepoint.com/:v:/s/RAM/EbXiTi9bFd5Ol-nJLTapQGMBTwz5nK01QzzXVNWwz5jXdg?e=vIVb6W 6 | 7 | --- 8 | 9 | ## Introduction 10 | The workshop began with an overview of MkDocs, comparing it with Sphinx and JupyterBook, and discussing its relationship with static site generators. 11 | 12 | ### Comparison with Sphinx and JupyterBook 13 | - **MkDocs:** [MkDocs Official Site](https://www.mkdocs.org/) 14 | - **Sphinx:** [Sphinx Documentation](https://www.sphinx-doc.org/en/master/) 15 | - **JupyterBook:** [JupyterBook Official Site](https://jupyterbook.org) (built on Sphinx: [JupyterBook and Sphinx](https://jupyterbook.org/en/stable/sphinx/index.html)) 16 | 17 | ### Static Site Generators 18 | We explored similarities and differences between MkDocs and static site generators: 19 | - [Jekyll](https://jekyllrb.com/) 20 | - [Hugo Quick Start Guide](https://gohugo.io/getting-started/quick-start/) 21 | 22 | ## MkDocs Setup and Usage 23 | We learned how to set up a basic MkDocs site and understood the difference between `mkdocs serve` and `mkdocs build`. 24 | 25 | ### Setting Up MkDocs 26 | Commands used for setting up: 27 | 28 | ``` 29 | $ mkdocs new test-mkdocs 30 | $ cd test-mkdocs 31 | $ code . 32 | $ mkdocs serve 33 | ``` 34 | 35 | *Note: The `code` command might require [installing VSCode in your PATH](https://safjan.com/add-vscode-to-path/). 36 | 37 | ### Understanding `mkdocs serve` vs `mkdocs build` 38 | - `mkdocs serve`: For live development and preview. Open https://localhost:8000 in your browser and it'll automatically reload when you update your local site. 39 | - `mkdocs build`: Generates static site output in the `site` folder, not updated in serve mode. 40 | 41 | ## Configuration and Theming 42 | We delved into configuring navigation and applying themes in MkDocs. 43 | 44 | ### Navigation Setup 45 | - Setting up navigation in `mkdocs.yml`: [MkDocs Navigation Configuration](https://www.mkdocs.org/user-guide/configuration/#nav). 46 | - MkDocs creates a structure from your files, but `nav` instruction can override this. 47 | 48 | ### Themes and Appearance 49 | - Experimented with `theme: readthedocs` and the [Material for MkDocs theme](https://squidfunk.github.io/mkdocs-material/). 50 | - Discussed the need to install themes before adding to the configuration. 51 | - Explored available themes: [MkDocs Themes Catalog](github.com/mkdocs/catalog#-theming). 52 | 53 | ### Managing Requirements 54 | - Importance of using virtual or conda environments. 55 | - Brief discussion on avoiding "requirement hell" with Anaconda. (Ultimately, Alden uninstalled Anaconda and reinstalled [Miniconda](https://docs.conda.io/projects/miniconda/en/latest/) instead.) 56 | 57 | ## GitHub Integration and Plugins 58 | Together, we learned to deploy their MkDocs site to GitHub and utilize plugins. 59 | 60 | ### Deploying to GitHub 61 | - Using `mkdocs gh-deploy` to publish to GitHub Pages ([GitHub Pages Documentation](https://pages.github.com/)). 62 | 63 | ### Using Plugins 64 | - Demonstration of the [`mkdocs-charts-plugin`](https://github.com/timvink/mkdocs-charts-plugin) for interactive charts. 65 | 66 | --- 67 | 68 | Sophie provided valuable insights on technical best practices throughout the workshop, emphasizing the importance of working within virtual or conda environments to manage dependencies effectively. 69 | --------------------------------------------------------------------------------