---
tags: retreat
---

# Collective Notes #

This document is for collective note-taking during the Retreat22 sessions.

## Introductions ##

* 'impact' is important to communicate in the humanities

## Projects \#1 & \#2 ##

@per GDPR, things are getting better/there is hope on the horizon
* be the computational thinker that the 'illiterate' does not
* new languages, Julia (@ross, moving from R to Julia, transfer cost)
* relation to Royal Library/web archive -- can we create best practice documentation? @arthur DK-RSEs should fight for changes to legislation (opinion pieces)
- pay to infomedia or not (should be sustainable, )
- @per change in legislation is happening
- @mathieu access to data from social media, specifically FB, is more critically
* understand how research works
* goal: create pervasive FAIR data management (automatic, )

@lene
* forgetting co-authorship
* vague specification of research question
* add dashboards to websites (university's web accessibility policy)
* vague specification of research questions
* requirements change management @mathieu, monthly all engineers help one afternoon on projects (only work that day)
* how to quantify support
* how to say NO, no more free hours
* undervaluing the complexity of the task
@kristian
* career model: 25\% employment in support \& 75\% in PhD
* from support to PhD, @kristoffer how do we enable this career path
* how to move development expertise to individual research project

@ross
* becoming a researcher/developing a reseach agenda after being the 'digital researcher'
* use our tools (ex. language models) as the object of research
- testing the outputs of language models against rigorous standards
- consequence of the ML turn (programming 2.0 $\sim$ software studies 2.0)
- reverse engineer political observation of language model (political bias of data) -- experimental bias analysis framework
* continuing as a bridge profile as senior researcher
* working with open source models (ex. Bloom vs. GPT-n)

@arthur
* how to motivate learners to learn about learning algos -- software that elicits thinking
* no/low-code tool for simple classifier training
* building software for teachers

@mathieu
* explicit about the roles in collaboration
* collaboration between visualization, analysis, and journalist/domain expert
* one map pr. day of French twitter sphere

## Infrastructure \#1 ##

* @all new slack workspace
* DECISION: how to share: Danish RSE -- GitHub --> new organization
* @kristian terms of membership requires open source
* @all who has responsibilities for web services, operations, updates of
* @all working with IT is a kafkaesque experience
* @kristian operations should reside at IT
* @mathieu ucloud is a data repository or platform for experimentation

## Education ##

* the courses/modules that no one wants to teach
* teaching high school
* core skills or state of the art
* @mathieu "means courses" motivation to participate: 1) upskill/competency development; 2) need tools to solve problem
* @ross contantly shifting goal posts - need to update teaching material every six months
* @knielbo we should build full trajectories that provide necessary skills and knowledge to students for their entire education (py101 -> culture data science)
* @all links for open repos of educational resources
* @mathieu hybridity, research/writing-papers and engineer/not-writing-papers,

## RDMS ##

## Career Management ##

* recruitment for teams
* manager career management
* forgetting co-authorship
* vague specification of research questions
* requirements change management
* do you want to publish
* the university owns all code and data

## DigHumLab \& Danish RSEs ##

* value: open data, goal: ensure changes to legislation for open access to data for research
* accountability for social media platforms
* terms of membership requires open source
* value: open source (for university, for the world)
* database of precedent for 'open x' for dealing with lawyers
* according to the _Vancouver Convention_, the right to an authorship is based on four main criteria, all of which must be met for the authorship to be legitimate: Significant contribution to the concept and design, or data collection or analysis and interpretation of data.
* UCloud is a promising tool

---
## Final Task ##

> **_NOTE:_** Values are like a compass that keep us headed in a desired direction and are distinct from goals. Goals are the specific ways you intend to execute your values. A goal is something that we aim for and check off once we have accomplished it. Being responsible is a value.

For each group, describe two to three values and the goal(-s) they direct Danish RSEs toward:

- Open is good. This means open science - but also openness as individuals and as a group.
- This means being receptive to those who are unfamiliar with what we do.
- It also means working together to teach and train students across the country.
- Research software engineering is _research_. Science is not just writing papers; it's also harvesting, processing, and analysing data.
- We should push for our work to be acknowledged both by way of co-authorship, but also in the context of different structures at universities.
- We should also push for RSE positions at universities to be recognised as VIP positions, or at least to have it recognised as a particular kind of technical position with specific
- We are regionally located but internationally focused. Both in terms of the composition of our group and our perspective.
- Building strong colloborations with colleagues in the Nordics and around the world.
- Visiting RSE schemes, "internships".
- Diversity is valuable. We come from interdisciplinary backgrounds and have contrasting goals. Some want only to work on technical problems; some want academic careers.
- There is no one-size-fits-all approach to being an RSE.

**The outer group**
- Open science and open source are core values of DRSE
- Focus: SSH
- *Recognition for engineering tasks in SSH research*
- Coding, tool development, engineering are essential parts of recent SSH research
- The group supports and works towards recognizing these tasks as research output (co-authorship, publication-like status of "products")
- We should act as representatives for this "movement" as a whole - represent the interests of scientific personel who engaged in engineering-like activities as a main part of their research.
- Best practice for RSE units (service, support, teaching, engineering) through knowledge-sharing and experiences ("ERFA-group")
- Facilitate and accelerate the use of existing, local service units
- Common point of contact for SSH RSE units at Danish universities
- Work towards creating room for members as DRSE to work on own reseach project
- *The DIGHUMLAB platform*
- Point of contact for RSE units in Denmark
- Point of contact for other RSE groups in Nordic countries
- Promote active research projects
- The DRSE is open for all who fit the RSE profile

## For DIGHUMLAB etc ##

Nendenstående er en sammenfatning af noterne ovenfor med det formål at definere og beskrive Danish RSE til https://dighumlab.org/danish-rse/ (Til diskussion og yderligere bidrag)

Danish RSE

Values:
- Open Science and Open Source are core values of Danish RSE
- The Danish RSE network supports and works towards recognition af engineering tasks (co-authorship or acknowledgement)

Goals:
- Danish RSE aim to set up a guide for Danish RSE’s based on the Vancouver Recommendations? (Maybe use an example and have uni-lawyer check it to make it very clear when you are a co-author or just contributor? (seems you can always demand to be acknowledged)) Should be something concrete (Own landing page) that RSE’s can refer to when in doubt or to convince researchers to comply.
- For RSE’s to become active contributors in formulating research questions to meet computational possibilities and restrictions.
- Enabling RSE career paths “From support to PhD” or for RSE positions at universities to be recognised as VIP positions, or at least to have it recognised as a particular kind of technical position (..)
- Stay in the loop concerning data management
- To formulate best practice for RSE units (service, support, teaching, engineering) through knowledge-sharing and experiences.

Who are we?
- We are research software engineers from the Danish universities. The initial RSE network established in 2022 grew from collaborations affiliated with DIGHUMLAB.
- We are regionally located but internationally focused. Both in terms of the composition of our group and our perspective. Building strong collaborations with colleagues in the Nordics (Nordic RSE) and around the world. Visiting RSE schemes, “internships”.

Who can join?
- The Danish RSE network is open to anyone who fits the profile. We come from interdisciplinary backgrounds, and some will want a career focusing on the technical aspects of the field while others aim for an academic career.
- The Danish RSE fokus is Humanities and Social Sciences (for now - what if members from other areas would like to join?)

Danish RSE on DIGHUMLAB.org
- Dighumlab will act as point of contact for RSE units in Denmark
- Dighumlab will act as point of contact for other RSE groups in Nordic countries
- Dighumlab will promote active research projects via website and social media and support the development of the Danish RSE network.

Vancouver Recommendations

Co-authorship is an ambiguous term that may give rise to vagueness, uncertainty and conflict. Not only does it tell us who is included, but also who is not included, but perhaps should have been. In addition, the order in which the authors are listed signals the role, rank and standing of each of them. In the eagerness to publish, it is easy to forget explicit and less explicit concerns that should be taken into consideration to demonstrate good ethical integrity.

According to the Vancouver criteria for authorship all co-authors should:
1. provide substantial contributions to the conception or design of the work; or the acquisition, analysis, or interpretation of data for the work; AND
2. draft the work or revise it critically for important intellectual content; AND
3. provide final approval of the version to be published; AND
4. agree to be accountable for all aspects of the work in ensuring that questions related to the accuracy or integrity of any part of the work are appropriately investigated and resolved.

Contributors who meet fewer than all 4 of the above criteria for authorship should not be listed as authors, but they should be acknowledged. Examples of activities that alone (without other contributions) do not qualify a contributor for authorship are acquisition of funding; general supervision of a research group or general administrative support; and writing assistance, technical editing, language editing, and proofreading. Those whose contributions do not justify authorship may be acknowledged individually or together as a group under a single heading (e.g. "Clinical Investigators" or "Participating Investigators"), and their contributions should be specified (e.g., "served as scientific advisors," "critically reviewed the study proposal," "collected data," "provided and cared for study patients," "participated in writing or technical editing of the manuscript").