-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
717 lines (711 loc) · 43.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>Standardising UK Trusted Research Environments in the Open</title>
<link rel="stylesheet" href="reveal.js/dist/reset.css">
<link rel="stylesheet" href="reveal.js/dist/reveal.css">
<link rel="stylesheet" href="reveal.js/dist/theme/moon.css">
<!-- Theme used for syntax highlighted code -->
<link rel="stylesheet" href="reveal.js/plugin/highlight/monokai.css">
<!-- Font Awesome -->
<link rel="stylesheet" href="assets/fontawesome/css/all.css">
<style>
.highlight {
color: #859900;
}
.fragment.highlight-my-green {}
.fragment.highlight-my-green.visible {
color: #859900;
}
.fragment.blur {
filter: blur(8px);
}
.fragment.blur.visible {
filter: none;
}
.reveal h1, .reveal h2, .reveal h3, .reveal h4 {
text-transform: none;
}
div.columns{
display: flex;
gap: min(4vw, 1.5em);
}
div.column{
flex: auto;
overflow-x: auto;
}
</style>
</head>
<body>
<div class="reveal">
<div class="slides">
<section>
<h2>Standardising UK Trusted Research Environments in the Open</h2>
<img src="static/SATRE_dark.png" alt="SATRE project logo" width="300">
<p>Dr Christian Cole</p>
<p>Health Informatics Centre, University of Dundee</p>
<aside data-markdown class="notes">
- SATRE
- Project to create a standard architecture for TREs in the UK
- Standard is designed in the open by the community
- Talking about our approach and what we have learned
</aside>
</section>
<section>
<h2 class="fragment custom highlight-my-green">The Need for SATRE</h2>
<h2>Our Approach</h2>
<h2>Lessons Learned</h2>
<aside data-markdown class="notes">
- What value SATRE brings to the existing TRE landscape
- Our approach to working in the open
- Why we did this
- What it enables
- What we have learned about open work
- Advice for other projects
</aside>
</section>
<section>
<h3>The Need for TREs</h3>
<!-- Why TREs? -->
<ul>
<li>Huge potential <span class="highlight">benefits</span></li>
<li><span class="highlight">Enabling</span> researchers to work with sensitive data</li>
<li><span class="highlight">Enforcing</span> and <span class="highlight">encouraging</span> good security</li>
<li>Keeping the <span class="highlight">confidence</span> of data controllers, subjects and the public</li>
</ul>
<aside data-markdown class="notes">
- Working with sensitive data is important/necessary, huge impact
- Health data
- Administrative data
- Commercially sensitive data
- All personal data
- Research environment need to be productive and secure
- Remove the burden from researchers on maintaining security
- Particularly when data subjects are the public, we rely on their trust and consent
- LINK:
- TREs are not new
- SATRE isn't inventing TREs
</aside>
</section>
<section>
<h3>The Current TRE Landscape</h3>
<!-- The current state -->
<ul>
<li>Fragmented</li>
<li><span class="highlight">Diverse</span> approaches</li>
<li><span class="highlight">Narrow</span> focus</li>
<li>No TRE standard</li>
</ul>
<aside data-markdown class="notes">
- Fragmented, not coordinated
- Some commercial offerings
- Many universities/institutions building/operating their own TREs
- Variety of approaches
- Secure rooms
- Remote desktops (direct data access)
- Query based (no direct data acess)
- TREs may be fairly bespoke, focused on a particular use or domain
- No TRE standard
- No accepted definition of what a TRE is
- Existing standards (ISO27001, DSPT, DEA) do not make your infrastructure a TRE
- Some community groups to share expertise, coordinate, unify
- LINK:
- Current situation
- The need for TREs is clear
- But not much coordination or agreement on what is a TRE or what one should be
</aside>
</section>
<section>
<h3>A Standard Architecture</h3>
<!-- Why SATRE? -->
<ul>
<li>Define a TRE <span class="highlight">baseline</span></li>
<li>Co-created by the <span class="highlight">community</span></li>
<li>Supports <span class="highlight">accreditation</span></li>
<li>Move towards <span class="highlight">interoperability</span></li>
</ul>
<aside data-markdown class="notes">
- A mark of quality for UK TREs
- Enable comparison across TREs
- Encourage all TREs to raise standards
- Designed by the community
- Ensure buy in, which is necessary for adoption
- Includes designers, operators, users
- What is important
- Balance productivity and security
- Supports accreditation
- Could be used as the basis for an accreditation
- Self assessment or evidence based
- Encourage interoperability
- Potential for better research working easily across TREs
</aside>
</section>
<section>
<h2>The Need for SATRE</h2>
<h2 class="fragment custom highlight-my-green">Our Approach</h2>
<h2>Lessons Learned</h2>
<aside data-markdown class="notes">
- Have set the scene for SATRE
- Two key elements to our approach
- Broad collaboration to involve many skills and viewpoints
- Working in the open to enable comment and contribution
</aside>
</section>
<section>
<h3>Diverse Collaboration</h3>
<!--
- Name the "core" institutions
- Emphasise need for diverse opinions
- Explain how each org is involved in the TRE field
-->
<img src="static/dundee_dark.png" alt="The University of Dundee logo" width="200">
<img src="static/HIC_dark.png" alt="Health Informatics Centre logo" width="200">
<img src="static/logo_turing_dark.png" alt="The Alan Turing Institute logo" width="200">
<img src="static/RDS_dark.png" alt="Research Data Scotland logo" width="200">
<img src="static/ulster_dark.png" alt="Ulster University logo" width="200">
<img src="static/UCL_ARC.svg" alt="University College London Advanced Research Computing Centre logo" width="100">
<img src="static/DARE_UK.png" alt="Data and Analytics Research Environments UK logo" width="200">
<img src="static/HDRUK.webp" alt="Health Data Research UK logo" width="200">
<img src="static/team/JB.jpg" alt="Public team member Jill Beggs" width="100">
<img src="static/team/AC.jpg" alt="Public team member Antony Chuter" width="100">
<aside data-markdown class="notes">
- Group of institutions with an active interest in trusted research
- Consensus is critical for adoption
- Building on our experience and reputation(?)
- Demonstrating that this is a collaborative effort, not one group dictating to others
- TRE creators
- Dundee, Turing, UCL
- TRE operators
- Dundee/HIC, Turing, UCL
- Application of TREs in healthcare
- Dundee/HIC, RDS, HDR UK
- Members of the public (Lay participants)
- Expertise in PIE
</aside>
</section>
<section>
<h3>Working in the Open</h3>
<!--
- What working in the open means
- What is open
- Hint at the benefits, this is the foundation of our collaborative approach
-->
<section>
<!-- <iframe src="https://github.com/sa-tre" height="450" width="800"></iframe> -->
<a href="https://github.com/sa-tre">
<img src="static/SATRE_GitHub_org.png" alt="The SATRE GitHub organisation web page" width="800">
</a>
<a href="https://github.com/sa-tre"><code>github.com/sa-tre</code></a>
</section>
<section>
<iframe src="https://satre-specification.readthedocs.io/en/latest/" height="450" width="1000"></iframe>
<a href="https://satre-specification.readthedocs.io"><code>satre-specification.readthedocs.io</code></a>
</section>
<section>
<!-- <iframe src="https://medium.com/satre" height="450" width="800"></iframe> -->
<a href="https://medium.com/satre">
<img src="static/SATRE_Medium_blog.png" alt="The SATRE Medium blog article feed" width="800">
</a>
<a href="https://medium.com/satre"><code>medium.com/satre</code></a>
</section>
<aside data-markdown class="notes">
- As open as possible, as private as necessary
- Outputs and work in progress are public
- The main focus, the specification
- Is a public website
- Built automatically from a public repository
- Enables contributions through GitHub
- Openness also enhances communication and public outreach
- Medium blog
- LINK:
- Putting your work in a public place is not a solution in itself
- You also need to codify how to work
</aside>
</section>
<section>
<h3>Contribution Governance</h3>
<!--
- Just being open is not sufficient
- Specifics about the contribution rules/governance
- Why we made those decisions, how they support contribution
- Careful for overlap with Community cocreation
-->
<section>
<ul>
<li>Consensus through <span class="highlight">discussion</span> and <span class="highlight">feedback</span></li>
<li>Code of conduct to enforce <span class="highlight">community standards</span></li>
<li>Clear <span class="highlight">consensus mechanism</span>
<li>Open to contributions from <span class="highlight">anyone</span></li>
</ul>
</section>
<section>
<iframe src="https://satre-specification.readthedocs.io/en/latest/contributing/index.html" height="500" width="1000"></iframe>
</section>
<aside data-markdown class="notes">
- Build consensus through discussion and review
- Discussion issues
- PRs require approval
- CoC standards reassure and welcome contributors
- Consensus mechanism
- avoids disputes or strong personalities controlling the process
- helps coordinate many contributors
- lazy consensus
- explicit approval
- Link:
- This kind of governance enables contribution
- However, it does not guarantee it
- We have spoken about the rules, but not how we work
</aside>
</section>
<section>
<h3>Collaborative Work</h3>
<!--
- How we work together, more directly
- The importance of events to promote collaboration across institutions and with the community
-->
<ul>
<li>Collaboration Cafés, coworking, work package meetings</li>
<li>Synchronous events help <span class="highlight">focus</span> and <span class="highlight">reach agreement</span></li>
<li>Can <span class="highlight">directly support</span> community involvement</li>
<li>Asynchronous work <span class="highlight">respects time</span></li>
<li>We do <span class="highlight">both</span></li>
</ul>
<aside data-markdown class="notes">
- Collaboration Cafés foster discussion on narrow topics
- Weekly team and work package meetings
- Frequent ad-hoc coworking sessions
- Synchronous events can help focus effort on a particular topic
- Particularly important when engaging the community
- Unfair and unrealistic to expect long term dedication
- Asynchronous work saves time
- Reply when you are available
- Different time zones and commitments
- Link:
- Events and asynchronous tools, particularly collaboration cafés, help us engage people
- Many of these people will want to contribute
- We need to support them contributing
- In particular, many are unfamiliar with GitHub
</aside>
</section>
<section>
<h3>Community Co-creation</h3>
<!--
- How contributions from the community are supported and welcomed
-->
<ul>
<li><span class="highlight">Enabled</span> by working in the open</li>
<li><span class="highlight">Support and recognise</span> other contribution routes</li>
<li>Team members <span class="highlight">translate</span> non-GitHub contributions to Markdown</li>
<li>Contributions all end up on <span class="highlight">GitHub and the site</span></li>
</ul>
<aside data-markdown class="notes">
- Enabled by working in the open
- Critical for us to support those who don't use GitHub
- Not everyone is 'technical' and knows how
- Not reasonable to expect everyone to learn
- Other ways to contribute
- Form
- Email
- Collaboration Cafés (shared note taking)
- Public engagement events
- Team members/community members translate to GH items
- Contributions ultimately appear in GitHub and the specification site
- Contribution routes are all valid
- Maintains history
- Link:
- We have engaged and enabled collaborations from enthusiastic people
- We also worked to actively approach important stakeholder groups
</aside>
</section>
<section>
<h3>Stakeholder Focus</h3>
<!--
- Key stakeholders we identified, what they can bring, how we engage them
-->
<table class="reveal" style="text-align: center">
<tr>
<th style="text-align: center">strategic stakeholders</th>
<th style="text-align: center">builders and operators</th>
<th style="text-align: center">users</th>
</tr><tr>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="1">influential organisations</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="4">make or run TREs</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="7">work in TREs</td>
</tr><tr>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="2">set requirements</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="5">technical and process experts</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="8">focus on productivity</td>
</tr><tr>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="3">direct engagement</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="6">collaboration cafés, GitHub</td>
<td style="text-align: center" class="fragment custom blur" data-fragment-index="9">user testing sessions</td>
</tr>
</table>
<aside data-markdown class="notes">
- Active effort to involve key stakeholders
- Groups identified and engaged in different ways
- Recognising the different skills, domains of those groups
- Strategic stakeholders
- Influential in TRE space
- _E.g._ ONS, NHS
- Direct engagement
- Builder and operators
- Those who make or control TREs for their organisation
- Engaged mostly through collaboration cafés
- Invited to contribute directly
- TRE Users
- People who work in TREs
- Greater focus on productivity, familiarity, results
- User testing sessions
- Link:
- There is another key stakeholder group that we made a particular effort to enage
- The public
</aside>
</section>
<section>
<h3>Public Engagement</h3>
<!--
- Public engagement is critical to build trust
- Activities to engage the public
-->
<div class="columns">
<div class="column" style="width: 45%">
<ul>
<li>TREs rely on <span class="highlight">trust</span></li>
<li>Two <span class="highlight">public members</span></li>
<li>Public engagement sessions</li>
<li>Influenced <span class="highlight">specification</span> and <span class="highlight">processes</span></li>
</ul>
</div>
<div class="column" style="width: 55%">
<iframe src="static/PIE_infographic.pdf" width="800" height="600"></iframe>
</div>
</div>
<aside data-markdown class="notes">
- (Many) TREs rely on the trust of the public. Particularly public health data
- Engagement team including two public members
- Strong experience in PIE
- Act as advocates for the public
- Online and in-person engagement sessions
- Collaboration cafés
- Facilitated by PIE professionals
- Influenced specification
- In particular concerns about transparency are reflected
- Influenced processes
- The need for more contribution methods
</aside>
</section>
<section>
<h3>Leading by Example</h3>
<!--
- How we are using the spec
- Demonstrating good participation
-->
<div class="columns">
<div class="column" style="width: 40%">
<ul>
<li>Follow <span class="highlight">our own</span> rules</li>
<li><span class="highlight">Evaluating</span> our implementations</li>
<li>Commitment to bridge the gap</li>
</ul>
</div>
<div class="column" style="width: 60%">
<iframe src="https://satre-specification.readthedocs.io/en/latest/evaluations/alan_turing_institute.html" height="400" width="600"></iframe>
</div>
</div>
<aside data-markdown class="notes">
- We follow the governance and contribution guidelines
- We should collaborate on an equal footing with others
- Dundee and Turing are completing self evaluations
- Demonstrate how evaluation works (to help others)
- Holding ourselves to our own standards
- Being honest about our strengths and weaknesses
- Commitment to reduce the gap between our TREs and the standard
</aside>
</section>
<section>
<h3>Sustainability</h3>
<!--
- How we see the standard living beyond the end of the project
-->
<ul>
<li>Standard needs to <span class="highlight">live on</span></li>
<li>Laying the <span class="highlight">groundwork</span></li>
<li><span class="highlight">Dedicated time</span> needed for stewardship</li>
<li>Seeking <span class="highlight">future funding</span> and <span class="highlight">community support</span></li>
<li><span class="highlight">Using</span> the standard is <span class="highlight">contributing</span></li>
</ul>
<aside data-markdown class="notes">
- To be successful, the standard needs to live on
- Evaluations against the standard
- Building upon the standard
- Contributing to the standard
- We are laying the groundwork for a sustainable, community project
- Open documents
- Established governance
- Established community
- However, future funding needed
- Needed for stewardship
- Engagement
- Future
- Seeking funding for dedicated time
- DARE phase 2
- Support from Dundee, Turing
- Working with community leadership to adopt, maintain, build on the standard
</aside>
</section>
<section>
<h2>The Need for SATRE</h2>
<h2>Our Approach</h2>
<h2 class="fragment custom highlight-my-green">Lessons Learned</h2>
</section>
<section>
<h3>The Benefits of Working in the Open</h3>
<ul>
<li>Better <span class="highlight">engagement</span></li>
<li><span class="highlight">Transparency</span> and <span class="highlight">trust</span></li>
<!-- <li><span class="highlight">Start</span> open, stay open</li> -->
<li>Governance doesn't have to be <span class="highlight">perfect</span></li>
<li><span class="highlight">Recognising</span> contributions</li>
</ul>
<iframe src="https://satre-specification.readthedocs.io/en/latest/contributing/contributors.html#contributors" height="350" width="700"></iframe>
<aside data-markdown class="notes">
- Our key message
- Open working is not just beneficial to OSS
- Particularly important when you need engagement, trust
- An open project means
- People can see and comment on your work in progress
- There are clear routes to contribution
- Being able to see what you are doing
- Builds trust
- Shows you have good intentions
- You should start open, from the first contribution
- Good practice from the beginning
- Clear distinction between public and private (e.g. survey)
- Making a project open later is difficult
- Contribution process, code of conduct _etc._ helps people to contribute
- Codifying this takes time. It is OK to be good enough and change your processes when there is a need
- Link:
- We could have taken better advantage to get early feedback
</aside>
</section>
<section>
<h3>Get Feedback Early</h3>
<ul>
<li>Avoid wasted effort</li>
<li>105 <span class="highlight">survey responses</span> from 55 organisations</li>
<li>Could have been <span class="highlight">more effective</span></li>
<li>Take advantage of <span class="highlight">version control</span> and <span class="highlight">open working</span></li>
<li>Changes are <span class="highlight">more frequent</span> but take <span class="highlight">less time</span></li>
</ul>
<aside data-markdown class="notes">
- Wasted effort
- Trying to produce complete items without feedback
- Finding that what we had done was not right
- For example the survey
- Around two months to create, share, analyse, process results
- We are proud
- 105 responses, 55 organisations
- Strong feedback that survey wasn't particularly helpful, asking wrong questions, wrong focus
- Now we take advantage of version control and open working to get feedback earlier
- Open discussion about ideas early
- Propose changes and ask for feedback
- Use collaboration cafés to show what we are working on and improve
- More comfortable committing 'draft' items to development branch (releases remain)
- Community feedback leads to many, sometimes large changes
- Overall it saves effort as we do not invest in the wrong things
- LINK:
- Collaboration cafés are an excellent way to get feedback
</aside>
</section>
<section>
<h3>The Power of Collaboration Cafés</h3>
<ul>
<li>The <span class="highlight">best way</span> to get <span class="highlight">community input</span></li>
<li>Led <span class="highlight">directly</span> to <span class="highlight">significant changes</span></li>
<li>Preparation, promotion, processing</li>
<li><span class="highlight">Facilitators</span> are necessary</li>
</ul>
<aside data-markdown class="notes">
- Collaboration cafés have been the best way to get community input
- Breakout room discussions have led directly to significant changes
- Recognising the important of information governance
- Switch from feature focus to capability focus
- Modifying the specification
- Adjusting project governance and routes to contribution
- Changing evaluation process
- You need to prepare in advance. A collaboration café should have an agenda and materials prepared
- After a collaboration café the discussion needs to be summarised and translated into actions
- Facilitators keep discussion on topic, help ensure everyone has their say. Especially when many people attend
- LINK:
- We are proud of the number and diversity of people attending. Active promotion and engagement was very worth the investment
- It took a lot of effort to make them as successful as they were
</aside>
</section>
<section>
<h3>Effective Engagement Takes Effort</h3>
<!--
Collecting Hari's points
- collaboration is easier when there is a specific task
- masking the most of limited time
- strategic collaboration matters
Plus acknowledgement of the important of roles
-->
<ul>
<li>Provide <span class="highlight">scope and context</span></li>
<li>Make <span class="highlight">good use</span> of people's time</li>
<li>Be <span class="highlight">flexible</span> and <span class="highlight">accommodating</span></li>
<li>Lead by example</li>
<li>Value roles like PIE Professionals, Community Managers, Application Managers</li>
</ul>
<aside data-markdown class="notes">
- Our initial approach was "participant-driven", asking attendees what they wanted to talk about at events
- It was difficult for us to keep focus and it was difficult for collaborators to know how they could help
- Moved to preparing focused events, asking specific questions
- More productive and clear when our approach is not aligned with the community
- Time is limited, particularly when engaging with the public
- They are not paid to help us, we must respect their time and not waste it
- Focus on short and direct engagements with clear goals
- Don't expect people to devote time or be engaged over long periods
- You must enable people to contribute
- Not everyone can/will use GitHub
- Support how the community wants to work
- Help adapt contributions
- Your "core team" should be active and visible at collaboration events
- It is important to avoid an "us and them" perception
- Roles focused on community and engagement have been critical
- They bring expertise and a desire to do work RSEs (or other tech focused roles) lack
</aside>
</section>
<section>
<h3>Public Involvement Matters</h3>
<ul>
<li>Bring <span class="highlight">knowledge and perspectives</span> you may lack</li>
<li>Helps communicate your <span class="highlight">message</span></li>
<li>Public as valued, core team members ensure <span class="highlight">voice is heard</span></li>
<li>Recruiting the public is <span class="highlight">challenging</span></li>
</ul>
<aside data-markdown class="notes">
- Public bring valuable contributions that your "technical" team won't make
- PIE professionals know how to explain your work and make sure it is heard
- Public team members
- Ensure voice is heard
- Must be treated equally
- Recruiting the public is challenging
- Different commitments, childcare, work, holidays, caring
- Lack of clear incentive to contribute
- It takes thought and effort to engage
</aside>
</section>
<section>
<h2>Reflections</h2>
</section>
<section>
<h3>Reflections</h3>
<ul>
<li>Need for <span class="highlight">standardisation</span></li>
<li>Community <span class="highlight">consensus</span> is critical</li>
<li>It takes effort to <span class="highlight">engage the community</span></li>
</ul>
<p>We encourage others to adopt these processes whenever community involvement is important</p>
<!--
- There is a need for better standardisation in TREs
- We need community consensus and buy in for this to work
- We thought hard about how to achieve this
- We designed the project to enable this
- We have learned from mistakes
- Willing to make changes
- We learned what works particular well
- We encourage any project to adopt what worked well whenever community involvement is important
-->
</section>
<section>
<h3>Acknowledgements</h3>
<!--
- Funding
- UKRI via the DARE UK Phase 1 driver projects programme (SATRE)
- DARE UK
- Turing ELA funds for DSH redirected
- Same for Dundee?
- Effort
- The project team
- ALL contributors, on GitHub, collaboration cafés, survey, public engagement, stakeholders
-->
<section>
<!-- <p>Funded by UKRI via the DARE UK <a href="https://dareuk.org.uk/our-work/phase-1-driver-projects/">Phase 1 driver projects programme</a></p> -->
<p>This work is funded by UKRI Grant <code>MC_PC_23008</code> as part of <a href="https://dareuk.org.uk/our-work/phase-1-driver-projects/">Phase 1</a> of the DARE UK programme, delivered in partnership with HDR UK and ADR UK</p>
<div style="background-color: #fdf6e3">
<img src="static/DARE_UK_alpha.png" alt="DARE UK logo" width="200">
</br>
<img src="static/UKRI.webp" alt="UKRI logo" width="200">
<img src="static/HDRUK.webp" alt="HDRUK logo" width="200">
<img src="static/ADRUK.webp" alt="ADRUK logo" width="200">
</div>
<!-- <p>Turing effort partially supported by The Alan Turing Institute</p> -->
<p>Also supported by the Ecosystem Leadership Award under EPSRC Grant <code>EP/X03870X/1</code> and The Alan Turing Institute</p>
</section>
<section>
<!-- PI -->
<img src="static/team/CC.jpg" alt="Principle Investigator Chris Cole" width="100">
<img src="static/team/SC.png" alt="Co-Investigator Sonya Coleman" width="100">
<!-- Co-Is -->
<img src="static/team/JH.jpg" alt="Co-Investigator James Hetherington" width="100">
<img src="static/team/EJ.jpg" alt="Co-Investigator Emily Jefferson" width="100">
<img src="static/team/DK.png" alt="Co-Investigator Dermot Kerr" width="100">
<img src="static/team/MOR.jpg" alt="Co-Investigator Martin O'Reilly" width="100">
<img src="static/team/JQ.png" alt="Co-Investigator Justin Quinn" width="100">
<img src="static/team/JR.jpg" alt="Co-Investigator James Robinson" width="100">
<!-- <img src="static/team/LR.jpg" alt="Co-Investigator Layla Robinson" width="100"> -->
<img src="static/team/HS.jpg" alt="Co-Investigator Hari Sood" width="100">
<img src="static/team/COD.jpg" alt="Co-Investigator Cian O'Donovan" width="100">
<!-- Public members -->
<img src="static/team/JB.jpg" alt="Public member Jillian Beggs" width="100">
<img src="static/team/AC.jpg" alt="Public member Antony Chuter" width="100">
<!-- Team members -->
<img src="static/team/EC.jpg" alt="Team member Ed Chalstrey" width="100">
<img src="static/team/MC.png" alt="Team member Matt Craddock" width="100">
<img src="static/team/SL.jpg" alt="Team member Simon Li" width="100">
<img src="static/team/JM.jpg" alt="Team member Jim Madge" width="100">
<!-- <img src="static/team/TM.png" alt="Team member Tim Mitchin" width="100"> -->
<img src="static/team/DSP.png" alt="Team member David Sarmiento Perez" width="100">
<!-- <img src="static/team/NS.png" alt="Team member Nel Swanepol" width="100"> -->
</section>
<section>
<p>Everyone who has contributed</p>
</section>
</section>
<section>
<h3>Join Us</h3>
<h4>Read The Specification</h4>
<i class="fa-solid fa-book fa-xs"></i><a href="https://satre-specification.readthedocs.io"><code>satre-specification.readthedocs.io</code></a>
<h4>Read Our Blog Posts</h4>
<i class="fa-solid fa-blog fa-xs"></i><a href="https://medium.com/satre"><code>medium.com/satre</code></a>
<h4>Get Involved</h4>
<i class="fa-solid fa-users fa-xs"></i><a href="https://satre-specification.readthedocs.io/en/latest/contributing/index.html"><code>satre-specification.readthedocs.io/en/stable/contributing</code></a>
<!--
</br>
<a href="https://github.com/sa-tre"><code>github.com/sa-tre</code></a>
-->
</br>
<i class="fa-solid fa-envelope fa-xs"></i><a href="mailto:satre-contact@dundee.ac.uk"><code>satre-contact@dundee.ac.uk</code></a>
</section>
</div>
</div>
<script src="reveal.js/dist/reveal.js"></script>
<script src="reveal.js/plugin/notes/notes.js"></script>
<script src="reveal.js/plugin/markdown/markdown.js"></script>
<script src="reveal.js/plugin/highlight/highlight.js"></script>
<script>
// More info about initialization & config:
// - https://revealjs.com/initialization/
// - https://revealjs.com/config/
Reveal.initialize({
hash: true,
// Learn about plugins: https://revealjs.com/plugins/
plugins: [ RevealMarkdown, RevealHighlight, RevealNotes ]
});
</script>
</body>
</html>