Node: ELIXIR Luxembourg
Authors: Hana Marčetić and Vilem Ded, data steward liaisons
Topics: Why strategy, Starting point
Use the data management strategy to write down boundaries that are currently handled case by case. This can make decisions about roles, resources, products and representation easier to explain and repeat.
It’s worth mentioning the question of where we, as Luxembourg Centre of Systems Biomedicine (LCSB), end and where we, as ELIXIR Luxembourg, begin. Because our Node lived inside one single organisation for so long, and because an ELIXIR Node is not really a legal entity (it is more of an internal project for us), our operations and responsibilities as LCSB and as the Node have become quite intertwined over the years. Most of the time this is just how things are for us, and we do not really notice.
We are not always sure whether a virtual machine or support we are providing is coming from us as LCSB or from us as LCSB being ELIXIR. When we build a piece of software, its publication is on awkward pause till it is decided whether it should live in our LCSB GitLab or our ELIXIR Luxembourg GitHub. When joining meetings, we cannot decide which hat to wear that day, LCSB, the University, or ELIXIR, and which slide template goes with it. Onboarding has a similar feel for us: at some point joining LCSB and joining the Node become two different things, but exactly where that point sits is more of a vibe than a rule. The same goes with roles, let’s say an LCSB data steward and an ELIXIR data steward, it is usually the same one of us with two hats. When it is not, the difference tends to surface only when something concrete depends on it.
At presence, we resolve all of this case by case and the work gets done. But because we have never written the boundary down, we reason through every new situation from scratch. A Node data management strategy would give us a place to put that boundary on paper, so the small decisions about resources, products, roles and representation have somewhere to land.