Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions

Foundational Competencies and Responsibilities of a... | F1000Research "use strict";function _typeof(t){return(_typeof="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t})(t)}!function(){var t=function(){var t,e,o=[],n=window,r=n;for(;r;){try{if(r.frames.__tcfapiLocator){t=r;break}}catch(t){}if(r===n.top)break;r=r.parent}t||(!function t(){var e=n.document,o=!!n.frames.__tcfapiLocator;if(!o)if(e.body){var r=e.createElement("iframe");r.style.cssText="display:none",r.name="__tcfapiLocator",e.body.appendChild(r)}else setTimeout(t,5);return!o}(),n.__tcfapi=function(){for(var t=arguments.length,n=new Array(t),r=0;r 3&&2===parseInt(n[1],10)&&"boolean"==typeof n[3]&&(e=n[3],"function"==typeof n[2]&&n[2]("set",!0)):"ping"===n[0]?"function"==typeof n[2]&&n[2]({gdprApplies:e,cmpLoaded:!1,cmpStatus:"stub"}):o.push(n)},n.addEventListener("message",(function(t){var e="string"==typeof t.data,o={};if(e)try{o=JSON.parse(t.data)}catch(t){}else o=t.data;var n="object"===_typeof(o)&&null!==o?o.__tcfapiCall:null;n&&window.__tcfapi(n.command,n.version,(function(o,r){var a={__tcfapiReturn:{returnValue:o,success:r,callId:n.callId}};t&&t.source&&t.source.postMessage&&t.source.postMessage(e?JSON.stringify(a):a,"*")}),n.parameter)}),!1))};"undefined"!=typeof module?module.exports=t:t()}(); dataLayer = dataLayer || []; // Standard GTM initialization - Google Consent Mode handles consent automatically (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl+ '>m_auth=hzk0Vc3qFsQYhCrIoHz68A>m_preview=env-1>m_cookies_win=x';f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-MWFK8L5J'); ;window.NREUM||(NREUM={});NREUM.init={distributed_tracing:{enabled:true},privacy:{cookies_enabled:true},ajax:{deny_list:["bam.nr-data.net"]}}; ;NREUM.loader_config={accountID:"438030",trustKey:"438030",agentID:"772317073",licenseKey:"97f8f67f26",applicationID:"772317073"} ;NREUM.info={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",licenseKey:"97f8f67f26",applicationID:"772317073",sa:1} ;/*! For license information please see nr-loader-spa-1.236.0.min.js.LICENSE.txt */ (()=>{"use strict";var e,t,r={5763:(e,t,r)=>{r.d(t,{P_:()=>l,Mt:()=>g,C5:()=>s,DL:()=>v,OP:()=>T,lF:()=>D,Yu:()=>y,Dg:()=>h,CX:()=>c,GE:()=>b,sU:()=>_});var n=r(8632),i=r(9567);const o={beacon:n.ce.beacon,errorBeacon:n.ce.errorBeacon,licenseKey:void 0,applicationID:void 0,sa:void 0,queueTime:void 0,applicationTime:void 0,ttGuid:void 0,user:void 0,account:void 0,product:void 0,extra:void 0,jsAttributes:{},userAttributes:void 0,atts:void 0,transactionName:void 0,tNamePlain:void 0},a={};function s(e){if(!e)throw new Error("All info objects require an agent identifier!");if(!a[e])throw new Error("Info for ".concat(e," was never set"));return a[e]}function c(e,t){if(!e)throw new Error("All info objects require an agent identifier!");a[e]=(0,i.D)(t,o),(0,n.Qy)(e,a[e],"info")}var u=r(7056);const d=()=>{const e={blockSelector:"[data-nr-block]",maskInputOptions:{password:!0}};return{allow_bfcache:!0,privacy:{cookies_enabled:!0},ajax:{deny_list:void 0,enabled:!0,harvestTimeSeconds:10},distributed_tracing:{enabled:void 0,exclude_newrelic_header:void 0,cors_use_newrelic_header:void 0,cors_use_tracecontext_headers:void 0,allowed_origins:void 0},session:{domain:void 0,expiresMs:u.oD,inactiveMs:u.Hb},ssl:void 0,obfuscate:void 0,jserrors:{enabled:!0,harvestTimeSeconds:10},metrics:{enabled:!0},page_action:{enabled:!0,harvestTimeSeconds:30},page_view_event:{enabled:!0},page_view_timing:{enabled:!0,harvestTimeSeconds:30,long_task:!1},session_trace:{enabled:!0,harvestTimeSeconds:10},harvest:{tooManyRequestsDelay:60},session_replay:{enabled:!1,harvestTimeSeconds:60,sampleRate:.1,errorSampleRate:.1,maskTextSelector:"*",maskAllInputs:!0,get blockClass(){return"nr-block"},get ignoreClass(){return"nr-ignore"},get maskTextClass(){return"nr-mask"},get blockSelector(){return e.blockSelector},set blockSelector(t){e.blockSelector+=",".concat(t)},get maskInputOptions(){return e.maskInputOptions},set maskInputOptions(t){e.maskInputOptions={...t,password:!0}}},spa:{enabled:!0,harvestTimeSeconds:10}}},f={};function l(e){if(!e)throw new Error("All configuration objects require an agent identifier!");if(!f[e])throw new Error("Configuration for ".concat(e," was never set"));return f[e]}function h(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");f[e]=(0,i.D)(t,d()),(0,n.Qy)(e,f[e],"config")}function g(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");var r=l(e);if(r){for(var n=t.split("."),i=0;i {r.d(t,{D:()=>i});var n=r(50);function i(e,t){try{if(!e||"object"!=typeof e)return(0,n.Z)("Setting a Configurable requires an object as input");if(!t||"object"!=typeof t)return(0,n.Z)("Setting a Configurable requires a model to set its initial properties");const r=Object.create(Object.getPrototypeOf(t),Object.getOwnPropertyDescriptors(t)),o=0===Object.keys(r).length?e:r;for(let a in o)if(void 0!==e[a])try{"object"==typeof e[a]&&"object"==typeof t[a]?r[a]=i(e[a],t[a]):r[a]=e[a]}catch(e){(0,n.Z)("An error occurred while setting a property of a Configurable",e)}return r}catch(e){(0,n.Z)("An error occured while setting a Configurable",e)}}},6818:(e,t,r)=>{r.d(t,{Re:()=>i,gF:()=>o,q4:()=>n});const n="1.236.0",i="PROD",o="CDN"},385:(e,t,r)=>{r.d(t,{FN:()=>a,IF:()=>u,Nk:()=>f,Tt:()=>s,_A:()=>o,il:()=>n,pL:()=>c,v6:()=>i,w1:()=>d});const n="undefined"!=typeof window&&!!window.document,i="undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self.navigator instanceof WorkerNavigator||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis.navigator instanceof WorkerNavigator),o=n?window:"undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis),a=""+o?.location,s=/iPad|iPhone|iPod/.test(navigator.userAgent),c=s&&"undefined"==typeof SharedWorker,u=(()=>{const e=navigator.userAgent.match(/Firefox[/\s](\d+\.\d+)/);return Array.isArray(e)&&e.length>=2?+e[1]:0})(),d=Boolean(n&&window.document.documentMode),f=!!navigator.sendBeacon},1117:(e,t,r)=>{r.d(t,{w:()=>o});var n=r(50);const i={agentIdentifier:"",ee:void 0};class o{constructor(e){try{if("object"!=typeof e)return(0,n.Z)("shared context requires an object as input");this.sharedContext={},Object.assign(this.sharedContext,i),Object.entries(e).forEach((e=>{let[t,r]=e;Object.keys(i).includes(t)&&(this.sharedContext[t]=r)}))}catch(e){(0,n.Z)("An error occured while setting SharedContext",e)}}}},8e3:(e,t,r)=>{r.d(t,{L:()=>d,R:()=>c});var n=r(2177),i=r(1284),o=r(4322),a=r(3325);const s={};function c(e,t){const r={staged:!1,priority:a.p[t]||0};u(e),s[e].get(t)||s[e].set(t,r)}function u(e){e&&(s[e]||(s[e]=new Map))}function d(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"",t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:"feature";if(u(e),!e||!s[e].get(t))return a(t);s[e].get(t).staged=!0;const r=[...s[e]];function a(t){const r=e?n.ee.get(e):n.ee,a=o.X.handlers;if(r.backlog&&a){var s=r.backlog[t],c=a[t];if(c){for(var u=0;s&&u {let[t,r]=e;return r.staged}))&&(r.sort(((e,t)=>e[1].priority-t[1].priority)),r.forEach((e=>{let[t]=e;a(t)})))}function f(e,t){var r=e[1];(0,i.D)(t[r],(function(t,r){var n=e[0];if(r[0]===n){var i=r[1],o=e[3],a=e[2];i.apply(o,a)}}))}},2177:(e,t,r)=>{r.d(t,{c:()=>f,ee:()=>u});var n=r(8632),i=r(2210),o=r(1284),a=r(5763),s="nr@context";let c=(0,n.fP)();var u;function d(){}function f(e){return(0,i.X)(e,s,l)}function l(){return new d}function h(){u.aborted=!0,u.backlog={}}c.ee?u=c.ee:(u=function e(t,r){var n={},c={},f={},g=!1;try{g=16===r.length&&(0,a.OP)(r).isolatedBacklog}catch(e){}var p={on:b,addEventListener:b,removeEventListener:y,emit:v,get:x,listeners:w,context:m,buffer:A,abort:h,aborted:!1,isBuffering:E,debugId:r,backlog:g?{}:t&&"object"==typeof t.backlog?t.backlog:{}};return p;function m(e){return e&&e instanceof d?e:e?(0,i.X)(e,s,l):l()}function v(e,r,n,i,o){if(!1!==o&&(o=!0),!u.aborted||i){t&&o&&t.emit(e,r,n);for(var a=m(n),s=w(e),d=s.length,f=0;fn,p:()=>i});var n=r(2177).ee.get("handle");function i(e,t,r,i,o){o?(o.buffer([e],i),o.emit(e,t,r)):(n.buffer([e],i),n.emit(e,t,r))}},4322:(e,t,r)=>{r.d(t,{X:()=>o});var n=r(5546);o.on=a;var i=o.handlers={};function o(e,t,r,o){a(o||n.E,i,e,t,r)}function a(e,t,r,i,o){o||(o="feature"),e||(e=n.E);var a=t[o]=t[o]||{};(a[r]=a[r]||[]).push([e,i])}},3239:(e,t,r)=>{r.d(t,{bP:()=>s,iz:()=>c,m$:()=>a});var n=r(385);let i=!1,o=!1;try{const e={get passive(){return i=!0,!1},get signal(){return o=!0,!1}};n._A.addEventListener("test",null,e),n._A.removeEventListener("test",null,e)}catch(e){}function a(e,t){return i||o?{capture:!!e,passive:i,signal:t}:!!e}function s(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;window.addEventListener(e,t,a(r,n))}function c(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;document.addEventListener(e,t,a(r,n))}},4402:(e,t,r)=>{r.d(t,{Ht:()=>u,M:()=>c,Rl:()=>a,ky:()=>s});var n=r(385);const i="xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";function o(e,t){return e?15&e[t]:16*Math.random()|0}function a(){const e=n._A?.crypto||n._A?.msCrypto;let t,r=0;return e&&e.getRandomValues&&(t=e.getRandomValues(new Uint8Array(31))),i.split("").map((e=>"x"===e?o(t,++r).toString(16):"y"===e?(3&o()|8).toString(16):e)).join("")}function s(e){const t=n._A?.crypto||n._A?.msCrypto;let r,i=0;t&&t.getRandomValues&&(r=t.getRandomValues(new Uint8Array(31)));const a=[];for(var s=0;s {r.d(t,{Bq:()=>n,Hb:()=>o,oD:()=>i});const n="NRBA",i=144e5,o=18e5},7894:(e,t,r)=>{function n(){return Math.round(performance.now())}r.d(t,{z:()=>n})},7243:(e,t,r)=>{r.d(t,{e:()=>o});var n=r(385),i={};function o(e){if(e in i)return i[e];if(0===(e||"").indexOf("data:"))return{protocol:"data"};let t;var r=n._A?.location,o={};if(n.il)t=document.createElement("a"),t.href=e;else try{t=new URL(e,r.href)}catch(e){return o}o.port=t.port;var a=t.href.split("://");!o.port&&a[1]&&(o.port=a[1].split("/")[0].split("@").pop().split(":")[1]),o.port&&"0"!==o.port||(o.port="https"===a[0]?"443":"80"),o.hostname=t.hostname||r.hostname,o.pathname=t.pathname,o.protocol=a[0],"/"!==o.pathname.charAt(0)&&(o.pathname="/"+o.pathname);var s=!t.protocol||":"===t.protocol||t.protocol===r.protocol,c=t.hostname===r.hostname&&t.port===r.port;return o.sameOrigin=s&&(!t.hostname||c),"/"===o.pathname&&(i[e]=o),o}},50:(e,t,r)=>{function n(e,t){"function"==typeof console.warn&&(console.warn("New Relic: ".concat(e)),t&&console.warn(t))}r.d(t,{Z:()=>n})},2587:(e,t,r)=>{r.d(t,{N:()=>c,T:()=>u});var n=r(2177),i=r(5546),o=r(8e3),a=r(3325);const s={stn:[a.D.sessionTrace],err:[a.D.jserrors,a.D.metrics],ins:[a.D.pageAction],spa:[a.D.spa],sr:[a.D.sessionReplay,a.D.sessionTrace]};function c(e,t){const r=n.ee.get(t);e&&"object"==typeof e&&(Object.entries(e).forEach((e=>{let[t,n]=e;void 0===u[t]&&(s[t]?s[t].forEach((e=>{n?(0,i.p)("feat-"+t,[],void 0,e,r):(0,i.p)("block-"+t,[],void 0,e,r),(0,i.p)("rumresp-"+t,[Boolean(n)],void 0,e,r)})):n&&(0,i.p)("feat-"+t,[],void 0,void 0,r),u[t]=Boolean(n))})),Object.keys(s).forEach((e=>{void 0===u[e]&&(s[e]?.forEach((t=>(0,i.p)("rumresp-"+e,[!1],void 0,t,r))),u[e]=!1)})),(0,o.L)(t,a.D.pageViewEvent))}const u={}},2210:(e,t,r)=>{r.d(t,{X:()=>i});var n=Object.prototype.hasOwnProperty;function i(e,t,r){if(n.call(e,t))return e[t];var i=r();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(e,t,{value:i,writable:!0,enumerable:!1}),i}catch(e){}return e[t]=i,i}},1284:(e,t,r)=>{r.d(t,{D:()=>n});const n=(e,t)=>Object.entries(e||{}).map((e=>{let[r,n]=e;return t(r,n)}))},4351:(e,t,r)=>{r.d(t,{P:()=>o});var n=r(2177);const i=()=>{const e=new WeakSet;return(t,r)=>{if("object"==typeof r&&null!==r){if(e.has(r))return;e.add(r)}return r}};function o(e){try{return JSON.stringify(e,i())}catch(e){try{n.ee.emit("internal-error",[e])}catch(e){}}}},3960:(e,t,r)=>{r.d(t,{K:()=>a,b:()=>o});var n=r(3239);function i(){return"undefined"==typeof document||"complete"===document.readyState}function o(e,t){if(i())return e();(0,n.bP)("load",e,t)}function a(e){if(i())return e();(0,n.iz)("DOMContentLoaded",e)}},8632:(e,t,r)=>{r.d(t,{EZ:()=>u,Qy:()=>c,ce:()=>o,fP:()=>a,gG:()=>d,mF:()=>s});var n=r(7894),i=r(385);const o={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net"};function a(){return i._A.NREUM||(i._A.NREUM={}),void 0===i._A.newrelic&&(i._A.newrelic=i._A.NREUM),i._A.NREUM}function s(){let e=a();return e.o||(e.o={ST:i._A.setTimeout,SI:i._A.setImmediate,CT:i._A.clearTimeout,XHR:i._A.XMLHttpRequest,REQ:i._A.Request,EV:i._A.Event,PR:i._A.Promise,MO:i._A.MutationObserver,FETCH:i._A.fetch}),e}function c(e,t,r){let i=a();const o=i.initializedAgents||{},s=o[e]||{};return Object.keys(s).length||(s.initializedAt={ms:(0,n.z)(),date:new Date}),i.initializedAgents={...o,[e]:{...s,[r]:t}},i}function u(e,t){a()[e]=t}function d(){return function(){let e=a();const t=e.info||{};e.info={beacon:o.beacon,errorBeacon:o.errorBeacon,...t}}(),function(){let e=a();const t=e.init||{};e.init={...t}}(),s(),function(){let e=a();const t=e.loader_config||{};e.loader_config={...t}}(),a()}},7956:(e,t,r)=>{r.d(t,{N:()=>i});var n=r(3239);function i(e){let t=arguments.length>1&&void 0!==arguments[1]&&arguments[1],r=arguments.length>2?arguments[2]:void 0,i=arguments.length>3?arguments[3]:void 0;return void(0,n.iz)("visibilitychange",(function(){if(t)return void("hidden"==document.visibilityState&&e());e(document.visibilityState)}),r,i)}},1214:(e,t,r)=>{r.d(t,{em:()=>v,u5:()=>N,QU:()=>S,_L:()=>I,Gm:()=>L,Lg:()=>M,gy:()=>U,BV:()=>Q,Kf:()=>ee});var n=r(2177);const i="nr@original";var o=Object.prototype.hasOwnProperty,a=!1;function s(e,t){return e||(e=n.ee),r.inPlace=function(e,t,n,i,o){n||(n="");var a,s,c,u="-"===n.charAt(0);for(c=0;c 2?n-2:0),o=2;o {r(A[T],e,w),r(E[T],e,w)})),r(l._A,"fetch",y),t.on(y+"end",(function(e,r){var n=this;if(r){var i=r.headers.get("content-length");null!==i&&(n.rxSize=i),t.emit(y+"done",[null,r],n)}else t.emit(y+"done",[e],n)})),t}const O={},j=["pushState","replaceState"];function S(e){const t=function(e){return(e||n.ee).get("history")}(e);return!l.il||O[t.debugId]++||(O[t.debugId]=1,s(t).inPlace(window.history,j,"-")),t}var P=r(3239);const C={},R=["appendChild","insertBefore","replaceChild"];function I(e){const t=function(e){return(e||n.ee).get("jsonp")}(e);if(!l.il||C[t.debugId])return t;C[t.debugId]=!0;var r=s(t),i=/[?&](?:callback|cb)=([^&#]+)/,o=/(.*)\.([^.]+)/,a=/^(\w+)(\.|$)(.*)$/;function c(e,t){var r=e.match(a),n=r[1],i=r[3];return i?c(i,t[n]):t[n]}return r.inPlace(Node.prototype,R,"dom-"),t.on("dom-start",(function(e){!function(e){if(!e||"string"!=typeof e.nodeName||"script"!==e.nodeName.toLowerCase())return;if("function"!=typeof e.addEventListener)return;var n=(a=e.src,s=a.match(i),s?s[1]:null);var a,s;if(!n)return;var u=function(e){var t=e.match(o);if(t&&t.length>=3)return{key:t[2],parent:c(t[1],window)};return{key:e,parent:window}}(n);if("function"!=typeof u.parent[u.key])return;var d={};function f(){t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}function l(){t.emit("jsonp-error",[],d),t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}r.inPlace(u.parent,[u.key],"cb-",d),e.addEventListener("load",f,(0,P.m$)(!1)),e.addEventListener("error",l,(0,P.m$)(!1)),t.emit("new-jsonp",[e.src],d)}(e[0])})),t}var k=r(5763);const H={};function L(e){const t=function(e){return(e||n.ee).get("mutation")}(e);if(!l.il||H[t.debugId])return t;H[t.debugId]=!0;var r=s(t),i=k.Yu.MO;return i&&(window.MutationObserver=function(e){return this instanceof i?new i(r(e,"fn-")):i.apply(this,arguments)},MutationObserver.prototype=i.prototype),t}const z={};function M(e){const t=function(e){return(e||n.ee).get("promise")}(e);if(z[t.debugId])return t;z[t.debugId]=!0;var r=n.c,o=s(t),a=k.Yu.PR;return a&&function(){function e(r){var n=t.context(),i=o(r,"executor-",n,null,!1);const s=Reflect.construct(a,[i],e);return t.context(s).getCtx=function(){return n},s}l._A.Promise=e,Object.defineProperty(e,"name",{value:"Promise"}),e.toString=function(){return a.toString()},Object.setPrototypeOf(e,a),["all","race"].forEach((function(r){const n=a[r];e[r]=function(e){let i=!1;[...e||[]].forEach((e=>{this.resolve(e).then(a("all"===r),a(!1))}));const o=n.apply(this,arguments);return o;function a(e){return function(){t.emit("propagate",[null,!i],o,!1,!1),i=i||!e}}}})),["resolve","reject"].forEach((function(r){const n=a[r];e[r]=function(e){const r=n.apply(this,arguments);return e!==r&&t.emit("propagate",[e,!0],r,!1,!1),r}})),e.prototype=a.prototype;const n=a.prototype.then;a.prototype.then=function(){var e=this,i=r(e);i.promise=e;for(var a=arguments.length,s=new Array(a),c=0;c e())),t};function m(e,t){i.inPlace(t,["onreadystatechange"],"fn-",E)}function b(){var e=this,t=r.context(e);e.readyState>3&&!t.resolved&&(t.resolved=!0,r.emit("xhr-resolved",[],e)),i.inPlace(e,f,"fn-",E)}if(function(e,t){for(var r in e)t[r]=e[r]}(o,p),p.prototype=o.prototype,i.inPlace(p.prototype,J,"-xhr-",E),r.on("send-xhr-start",(function(e,t){m(e,t),function(e){h.push(e),a&&(y?y.then(A):u?u(A):(w=-w,x.data=w))}(t)})),r.on("open-xhr-start",m),a){var y=c&&c.resolve();if(!u&&!c){var w=1,x=document.createTextNode(w);new a(A).observe(x,{characterData:!0})}}else t.on("fn-end",(function(e){e[0]&&e[0].type===d||A()}));function A(){for(var e=0;e {r.d(t,{t:()=>n});const n=r(3325).D.ajax},6660:(e,t,r)=>{r.d(t,{A:()=>i,t:()=>n});const n=r(3325).D.jserrors,i="nr@seenError"},3081:(e,t,r)=>{r.d(t,{gF:()=>o,mY:()=>i,t9:()=>n,vz:()=>s,xS:()=>a});const n=r(3325).D.metrics,i="sm",o="cm",a="storeSupportabilityMetrics",s="storeEventMetrics"},4649:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageAction},7633:(e,t,r)=>{r.d(t,{Dz:()=>i,OJ:()=>a,qw:()=>o,t9:()=>n});const n=r(3325).D.pageViewEvent,i="firstbyte",o="domcontent",a="windowload"},9251:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageViewTiming},3614:(e,t,r)=>{r.d(t,{BST_RESOURCE:()=>i,END:()=>s,FEATURE_NAME:()=>n,FN_END:()=>u,FN_START:()=>c,PUSH_STATE:()=>d,RESOURCE:()=>o,START:()=>a});const n=r(3325).D.sessionTrace,i="bstResource",o="resource",a="-start",s="-end",c="fn"+a,u="fn"+s,d="pushState"},7836:(e,t,r)=>{r.d(t,{BODY:()=>A,CB_END:()=>E,CB_START:()=>u,END:()=>x,FEATURE_NAME:()=>i,FETCH:()=>_,FETCH_BODY:()=>v,FETCH_DONE:()=>m,FETCH_START:()=>p,FN_END:()=>c,FN_START:()=>s,INTERACTION:()=>l,INTERACTION_API:()=>d,INTERACTION_EVENTS:()=>o,JSONP_END:()=>b,JSONP_NODE:()=>g,JS_TIME:()=>T,MAX_TIMER_BUDGET:()=>a,REMAINING:()=>f,SPA_NODE:()=>h,START:()=>w,originalSetTimeout:()=>y});var n=r(5763);const i=r(3325).D.spa,o=["click","submit","keypress","keydown","keyup","change"],a=999,s="fn-start",c="fn-end",u="cb-start",d="api-ixn-",f="remaining",l="interaction",h="spaNode",g="jsonpNode",p="fetch-start",m="fetch-done",v="fetch-body-",b="jsonp-end",y=n.Yu.ST,w="-start",x="-end",A="-body",E="cb"+x,T="jsTime",_="fetch"},5938:(e,t,r)=>{r.d(t,{W:()=>o});var n=r(5763),i=r(2177);class o{constructor(e,t,r){this.agentIdentifier=e,this.aggregator=t,this.ee=i.ee.get(e,(0,n.OP)(this.agentIdentifier).isolatedBacklog),this.featureName=r,this.blocked=!1}}},9144:(e,t,r)=>{r.d(t,{j:()=>m});var n=r(3325),i=r(5763),o=r(5546),a=r(2177),s=r(7894),c=r(8e3),u=r(3960),d=r(385),f=r(50),l=r(3081),h=r(8632);function g(){const e=(0,h.gG)();["setErrorHandler","finished","addToTrace","inlineHit","addRelease","addPageAction","setCurrentRouteName","setPageViewName","setCustomAttribute","interaction","noticeError","setUserId"].forEach((t=>{e[t]=function(){for(var r=arguments.length,n=new Array(r),i=0;i 1?r-1:0),i=1;i {e.exposed&&e.api[t]&&o.push(e.api[t](...n))})),o.length>1?o:o[0]}(t,...n)}}))}var p=r(2587);function m(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:{},m=arguments.length>2?arguments[2]:void 0,v=arguments.length>3?arguments[3]:void 0,{init:b,info:y,loader_config:w,runtime:x={loaderType:m},exposed:A=!0}=t;const E=(0,h.gG)();y||(b=E.init,y=E.info,w=E.loader_config),(0,i.Dg)(e,b||{}),(0,i.GE)(e,w||{}),(0,i.sU)(e,x),y.jsAttributes??={},d.v6&&(y.jsAttributes.isWorker=!0),(0,i.CX)(e,y),g();const T=function(e,t){t||(0,c.R)(e,"api");const h={};var g=a.ee.get(e),p=g.get("tracer"),m="api-",v=m+"ixn-";function b(t,r,n,o){const a=(0,i.C5)(e);return null===r?delete a.jsAttributes[t]:(0,i.CX)(e,{...a,jsAttributes:{...a.jsAttributes,[t]:r}}),x(m,n,!0,o||null===r?"session":void 0)(t,r)}function y(){}["setErrorHandler","finished","addToTrace","inlineHit","addRelease"].forEach((e=>h[e]=x(m,e,!0,"api"))),h.addPageAction=x(m,"addPageAction",!0,n.D.pageAction),h.setCurrentRouteName=x(m,"routeName",!0,n.D.spa),h.setPageViewName=function(t,r){if("string"==typeof t)return"/"!==t.charAt(0)&&(t="/"+t),(0,i.OP)(e).customTransaction=(r||"http://custom.transaction")+t,x(m,"setPageViewName",!0)()},h.setCustomAttribute=function(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2];if("string"==typeof e){if(["string","number"].includes(typeof t)||null===t)return b(e,t,"setCustomAttribute",r);(0,f.Z)("Failed to execute setCustomAttribute.\nNon-null value must be a string or number type, but a type of was provided."))}else(0,f.Z)("Failed to execute setCustomAttribute.\nName must be a string type, but a type of was provided."))},h.setUserId=function(e){if("string"==typeof e||null===e)return b("enduser.id",e,"setUserId",!0);(0,f.Z)("Failed to execute setUserId.\nNon-null value must be a string type, but a type of was provided."))},h.interaction=function(){return(new y).get()};var w=y.prototype={createTracer:function(e,t){var r={},i=this,a="function"==typeof t;return(0,o.p)(v+"tracer",[(0,s.z)(),e,r],i,n.D.spa,g),function(){if(p.emit((a?"":"no-")+"fn-start",[(0,s.z)(),i,a],r),a)try{return t.apply(this,arguments)}catch(e){throw p.emit("fn-err",[arguments,this,"string"==typeof e?new Error(e):e],r),e}finally{p.emit("fn-end",[(0,s.z)()],r)}}}};function x(e,t,r,i){return function(){return(0,o.p)(l.xS,["API/"+t+"/called"],void 0,n.D.metrics,g),i&&(0,o.p)(e+t,[(0,s.z)(),...arguments],r?null:this,i,g),r?void 0:this}}function A(){r.e(439).then(r.bind(r,7438)).then((t=>{let{setAPI:r}=t;r(e),(0,c.L)(e,"api")})).catch((()=>(0,f.Z)("Downloading runtime APIs failed...")))}return["actionText","setName","setAttribute","save","ignore","onEnd","getContext","end","get"].forEach((e=>{w[e]=x(v,e,void 0,n.D.spa)})),h.noticeError=function(e,t){"string"==typeof e&&(e=new Error(e)),(0,o.p)(l.xS,["API/noticeError/called"],void 0,n.D.metrics,g),(0,o.p)("err",[e,(0,s.z)(),!1,t],void 0,n.D.jserrors,g)},d.il?(0,u.b)((()=>A()),!0):A(),h}(e,v);return(0,h.Qy)(e,T,"api"),(0,h.Qy)(e,A,"exposed"),(0,h.EZ)("activatedFeatures",p.T),T}},3325:(e,t,r)=>{r.d(t,{D:()=>n,p:()=>i});const n={ajax:"ajax",jserrors:"jserrors",metrics:"metrics",pageAction:"page_action",pageViewEvent:"page_view_event",pageViewTiming:"page_view_timing",sessionReplay:"session_replay",sessionTrace:"session_trace",spa:"spa"},i={[n.pageViewEvent]:1,[n.pageViewTiming]:2,[n.metrics]:3,[n.jserrors]:4,[n.ajax]:5,[n.sessionTrace]:6,[n.pageAction]:7,[n.spa]:8,[n.sessionReplay]:9}}},n={};function i(e){var t=n[e];if(void 0!==t)return t.exports;var o=n[e]={exports:{}};return r[e](o,o.exports,i),o.exports}i.m=r,i.d=(e,t)=>{for(var r in t)i.o(t,r)&&!i.o(e,r)&&Object.defineProperty(e,r,{enumerable:!0,get:t[r]})},i.f={},i.e=e=>Promise.all(Object.keys(i.f).reduce(((t,r)=>(i.f[r](e,t),t)),[])),i.u=e=>(({78:"page_action-aggregate",147:"metrics-aggregate",242:"session-manager",317:"jserrors-aggregate",348:"page_view_timing-aggregate",412:"lazy-feature-loader",439:"async-api",538:"recorder",590:"session_replay-aggregate",675:"compressor",733:"session_trace-aggregate",786:"page_view_event-aggregate",873:"spa-aggregate",898:"ajax-aggregate"}[e]||e)+"."+{78:"ac76d497",147:"3dc53903",148:"1a20d5fe",242:"2a64278a",317:"49e41428",348:"bd6de33a",412:"2f55ce66",439:"30bd804e",538:"1b18459f",590:"cf0efb30",675:"ae9f91a8",733:"83105561",786:"06482edd",860:"03a8b7a5",873:"e6b09d52",898:"998ef92b"}[e]+"-1.236.0.min.js"),i.o=(e,t)=>Object.prototype.hasOwnProperty.call(e,t),e={},t="NRBA:",i.l=(r,n,o,a)=>{if(e[r])e[r].push(n);else{var s,c;if(void 0!==o)for(var u=document.getElementsByTagName("script"),d=0;d {s.onerror=s.onload=null,clearTimeout(h);var i=e[r];if(delete e[r],s.parentNode&&s.parentNode.removeChild(s),i&&i.forEach((e=>e(n))),t)return t(n)},h=setTimeout(l.bind(null,void 0,{type:"timeout",target:s}),12e4);s.onerror=l.bind(null,s.onerror),s.onload=l.bind(null,s.onload),c&&document.head.appendChild(s)}},i.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},i.j=364,i.p="https://js-agent.newrelic.com/",(()=>{var e={364:0,953:0};i.f.j=(t,r)=>{var n=i.o(e,t)?e[t]:void 0;if(0!==n)if(n)r.push(n[2]);else{var o=new Promise(((r,i)=>n=e[t]=[r,i]));r.push(n[2]=o);var a=i.p+i.u(t),s=new Error;i.l(a,(r=>{if(i.o(e,t)&&(0!==(n=e[t])&&(e[t]=void 0),n)){var o=r&&("load"===r.type?"missing":r.type),a=r&&r.target&&r.target.src;s.message="Loading chunk "+t+" failed.\n("+o+": "+a+")",s.name="ChunkLoadError",s.type=o,s.request=a,n[1](s)}}),"chunk-"+t,t)}};var t=(t,r)=>{var n,o,[a,s,c]=r,u=0;if(a.some((t=>0!==e[t]))){for(n in s)i.o(s,n)&&(i.m[n]=s[n]);if(c)c(i)}for(t&&t(r);u {i.r(o);var e=i(3325),t=i(5763);const r=Object.values(e.D);function n(e){const n={};return r.forEach((r=>{n[r]=function(e,r){return!1!==(0,t.Mt)(r,"".concat(e,".enabled"))}(r,e)})),n}var a=i(9144);var s=i(5546),c=i(385),u=i(8e3),d=i(5938),f=i(3960),l=i(50);class h extends d.W{constructor(e,t,r){let n=!(arguments.length>3&&void 0!==arguments[3])||arguments[3];super(e,t,r),this.auto=n,this.abortHandler,this.featAggregate,this.onAggregateImported,n&&(0,u.R)(e,r)}importAggregator(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};if(this.featAggregate||!this.auto)return;const r=c.il&&!0===(0,t.Mt)(this.agentIdentifier,"privacy.cookies_enabled");let n;this.onAggregateImported=new Promise((e=>{n=e}));const o=async()=>{let t;try{if(r){const{setupAgentSession:e}=await Promise.all([i.e(860),i.e(242)]).then(i.bind(i,3228));t=e(this.agentIdentifier)}}catch(e){(0,l.Z)("A problem occurred when starting up session manager. This page will not start or extend any session.",e)}try{if(!this.shouldImportAgg(this.featureName,t))return void(0,u.L)(this.agentIdentifier,this.featureName);const{lazyFeatureLoader:r}=await i.e(412).then(i.bind(i,8582)),{Aggregate:o}=await r(this.featureName,"aggregate");this.featAggregate=new o(this.agentIdentifier,this.aggregator,e),n(!0)}catch(e){(0,l.Z)("Downloading and initializing ".concat(this.featureName," failed..."),e),this.abortHandler?.(),n(!1)}};c.il?(0,f.b)((()=>o()),!0):o()}shouldImportAgg(r,n){return r!==e.D.sessionReplay||!1!==(0,t.Mt)(this.agentIdentifier,"session_trace.enabled")&&(!!n?.isNew||!!n?.state.sessionReplay)}}var g=i(7633),p=i(7894);class m extends h{static featureName=g.t9;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];if(super(r,n,g.t9,i),("undefined"==typeof PerformanceNavigationTiming||c.Tt)&&"undefined"!=typeof PerformanceTiming){const n=(0,t.OP)(r);n[g.Dz]=Math.max(Date.now()-n.offset,0),(0,f.K)((()=>n[g.qw]=Math.max((0,p.z)()-n[g.Dz],0))),(0,f.b)((()=>{const t=(0,p.z)();n[g.OJ]=Math.max(t-n[g.Dz],0),(0,s.p)("timing",["load",t],void 0,e.D.pageViewTiming,this.ee)}))}this.importAggregator()}}var v=i(1117),b=i(1284);class y extends v.w{constructor(e){super(e),this.aggregatedData={}}store(e,t,r,n,i){var o=this.getBucket(e,t,r,i);return o.metrics=function(e,t){t||(t={count:0});return t.count+=1,(0,b.D)(e,(function(e,r){t[e]=w(r,t[e])})),t}(n,o.metrics),o}merge(e,t,r,n,i){var o=this.getBucket(e,t,n,i);if(o.metrics){var a=o.metrics;a.count+=r.count,(0,b.D)(r,(function(e,t){if("count"!==e){var n=a[e],i=r[e];i&&!i.c?a[e]=w(i.t,n):a[e]=function(e,t){if(!t)return e;t.c||(t=x(t.t));return t.min=Math.min(e.min,t.min),t.max=Math.max(e.max,t.max),t.t+=e.t,t.sos+=e.sos,t.c+=e.c,t}(i,a[e])}}))}else o.metrics=r}storeMetric(e,t,r,n){var i=this.getBucket(e,t,r);return i.stats=w(n,i.stats),i}getBucket(e,t,r,n){this.aggregatedData[e]||(this.aggregatedData[e]={});var i=this.aggregatedData[e][t];return i||(i=this.aggregatedData[e][t]={params:r||{}},n&&(i.custom=n)),i}get(e,t){return t?this.aggregatedData[e]&&this.aggregatedData[e][t]:this.aggregatedData[e]}take(e){for(var t={},r="",n=!1,i=0;i t.max&&(t.max=e),e 2&&void 0!==arguments[2])||arguments[2];super(e,r,j.t,n),c.il&&((0,t.OP)(e).initHidden=Boolean("hidden"===document.visibilityState),(0,N.N)((()=>(0,s.p)("docHidden",[(0,p.z)()],void 0,j.t,this.ee)),!0),(0,O.bP)("pagehide",(()=>(0,s.p)("winPagehide",[(0,p.z)()],void 0,j.t,this.ee))),this.importAggregator())}}var P=i(3081);class C extends h{static featureName=P.t9;constructor(e,t){let r=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(e,t,P.t9,r),this.importAggregator()}}var R,I=i(2210),k=i(1214),H=i(2177),L={};try{R=localStorage.getItem("__nr_flags").split(","),console&&"function"==typeof console.log&&(L.console=!0,-1!==R.indexOf("dev")&&(L.dev=!0),-1!==R.indexOf("nr_dev")&&(L.nrDev=!0))}catch(e){}function z(e){try{L.console&&z(e)}catch(e){}}L.nrDev&&H.ee.on("internal-error",(function(e){z(e.stack)})),L.dev&&H.ee.on("fn-err",(function(e,t,r){z(r.stack)})),L.dev&&(z("NR AGENT IN DEVELOPMENT MODE"),z("flags: "+(0,b.D)(L,(function(e,t){return e})).join(", ")));var M=i(6660);class B extends h{static featureName=M.t;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(r,n,M.t,i),this.skipNext=0;try{this.removeOnAbort=new AbortController}catch(e){}const o=this;o.ee.on("fn-start",(function(e,t,r){o.abortHandler&&(o.skipNext+=1)})),o.ee.on("fn-err",(function(t,r,n){o.abortHandler&&!n[M.A]&&((0,I.X)(n,M.A,(function(){return!0})),this.thrown=!0,(0,s.p)("err",[n,(0,p.z)()],void 0,e.D.jserrors,o.ee))})),o.ee.on("fn-end",(function(){o.abortHandler&&!this.thrown&&o.skipNext>0&&(o.skipNext-=1)})),o.ee.on("internal-error",(function(t){(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,o.ee)})),this.origOnerror=c._A.onerror,c._A.onerror=this.onerrorHandler.bind(this),c._A.addEventListener("unhandledrejection",(t=>{const r=function(e){let t="Unhandled Promise Rejection: ";if(e instanceof Error)try{return e.message=t+e.message,e}catch(t){return e}if(void 0===e)return new Error(t);try{return new Error(t+(0,D.P)(e))}catch(e){return new Error(t)}}(t.reason);(0,s.p)("err",[r,(0,p.z)(),!1,{unhandledPromiseRejection:1}],void 0,e.D.jserrors,this.ee)}),(0,O.m$)(!1,this.removeOnAbort?.signal)),(0,k.gy)(this.ee),(0,k.BV)(this.ee),(0,k.em)(this.ee),(0,t.OP)(r).xhrWrappable&&(0,k.Kf)(this.ee),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}onerrorHandler(t,r,n,i,o){"function"==typeof this.origOnerror&&this.origOnerror(...arguments);try{this.skipNext?this.skipNext-=1:(0,s.p)("err",[o||new F(t,r,n),(0,p.z)()],void 0,e.D.jserrors,this.ee)}catch(t){try{(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,this.ee)}catch(e){}}return!1}}function F(e,t,r){this.message=e||"Uncaught error with no additional information",this.sourceURL=t,this.line=r}let U=1;const q="nr@id";function G(e){const t=typeof e;return!e||"object"!==t&&"function"!==t?-1:e===c._A?0:(0,I.X)(e,q,(function(){return U++}))}function V(e){if("string"==typeof e&&e.length)return e.length;if("object"==typeof e){if("undefined"!=typeof ArrayBuffer&&e instanceof ArrayBuffer&&e.byteLength)return e.byteLength;if("undefined"!=typeof Blob&&e instanceof Blob&&e.size)return e.size;if(!("undefined"!=typeof FormData&&e instanceof FormData))try{return(0,D.P)(e).length}catch(e){return}}}var X=i(7243);class W{constructor(e){this.agentIdentifier=e,this.generateTracePayload=this.generateTracePayload.bind(this),this.shouldGenerateTrace=this.shouldGenerateTrace.bind(this)}generateTracePayload(e){if(!this.shouldGenerateTrace(e))return null;var r=(0,t.DL)(this.agentIdentifier);if(!r)return null;var n=(r.accountID||"").toString()||null,i=(r.agentID||"").toString()||null,o=(r.trustKey||"").toString()||null;if(!n||!i)return null;var a=(0,_.M)(),s=(0,_.Ht)(),c=Date.now(),u={spanId:a,traceId:s,timestamp:c};return(e.sameOrigin||this.isAllowedOrigin(e)&&this.useTraceContextHeadersForCors())&&(u.traceContextParentHeader=this.generateTraceContextParentHeader(a,s),u.traceContextStateHeader=this.generateTraceContextStateHeader(a,c,n,i,o)),(e.sameOrigin&&!this.excludeNewrelicHeader()||!e.sameOrigin&&this.isAllowedOrigin(e)&&this.useNewrelicHeaderForCors())&&(u.newrelicHeader=this.generateTraceHeader(a,s,c,n,i,o)),u}generateTraceContextParentHeader(e,t){return"00-"+t+"-"+e+"-01"}generateTraceContextStateHeader(e,t,r,n,i){return i+"@nr=0-1-"+r+"-"+n+"-"+e+"----"+t}generateTraceHeader(e,t,r,n,i,o){if(!("function"==typeof c._A?.btoa))return null;var a={v:[0,1],d:{ty:"Browser",ac:n,ap:i,id:e,tr:t,ti:r}};return o&&n!==o&&(a.d.tk=o),btoa((0,D.P)(a))}shouldGenerateTrace(e){return this.isDtEnabled()&&this.isAllowedOrigin(e)}isAllowedOrigin(e){var r=!1,n={};if((0,t.Mt)(this.agentIdentifier,"distributed_tracing")&&(n=(0,t.P_)(this.agentIdentifier).distributed_tracing),e.sameOrigin)r=!0;else if(n.allowed_origins instanceof Array)for(var i=0;i 2&&void 0!==arguments[2])||arguments[2];super(r,n,Z.t,i),(0,t.OP)(r).xhrWrappable&&(this.dt=new W(r),this.handler=(e,t,r,n)=>(0,s.p)(e,t,r,n,this.ee),(0,k.u5)(this.ee),(0,k.Kf)(this.ee),function(r,n,i,o){function a(e){var t=this;t.totalCbs=0,t.called=0,t.cbTime=0,t.end=E,t.ended=!1,t.xhrGuids={},t.lastSize=null,t.loadCaptureCalled=!1,t.params=this.params||{},t.metrics=this.metrics||{},e.addEventListener("load",(function(r){_(t,e)}),(0,O.m$)(!1)),c.IF||e.addEventListener("progress",(function(e){t.lastSize=e.loaded}),(0,O.m$)(!1))}function s(e){this.params={method:e[0]},T(this,e[1]),this.metrics={}}function u(e,n){var i=(0,t.DL)(r);i.xpid&&this.sameOrigin&&n.setRequestHeader("X-NewRelic-ID",i.xpid);var a=o.generateTracePayload(this.parsedOrigin);if(a){var s=!1;a.newrelicHeader&&(n.setRequestHeader("newrelic",a.newrelicHeader),s=!0),a.traceContextParentHeader&&(n.setRequestHeader("traceparent",a.traceContextParentHeader),a.traceContextStateHeader&&n.setRequestHeader("tracestate",a.traceContextStateHeader),s=!0),s&&(this.dt=a)}}function d(e,t){var r=this.metrics,i=e[0],o=this;if(r&&i){var a=V(i);a&&(r.txSize=a)}this.startTime=(0,p.z)(),this.listener=function(e){try{"abort"!==e.type||o.loadCaptureCalled||(o.params.aborted=!0),("load"!==e.type||o.called===o.totalCbs&&(o.onloadCalled||"function"!=typeof t.onload)&&"function"==typeof o.end)&&o.end(t)}catch(e){try{n.emit("internal-error",[e])}catch(e){}}};for(var s=0;s 1?e[1]=i:e.push(i)}else e[0]&&e[0].headers&&s(e[0].headers,n)&&(this.dt=n);function s(e,t){var r=!1;return t.newrelicHeader&&(e.set("newrelic",t.newrelicHeader),r=!0),t.traceContextParentHeader&&(e.set("traceparent",t.traceContextParentHeader),t.traceContextStateHeader&&e.set("tracestate",t.traceContextStateHeader),r=!0),r}}function x(e,t){this.params={},this.metrics={},this.startTime=(0,p.z)(),this.dt=t,e.length>=1&&(this.target=e[0]),e.length>=2&&(this.opts=e[1]);var r,n=this.opts||{},i=this.target;"string"==typeof i?r=i:"object"==typeof i&&i instanceof Y?r=i.url:c._A?.URL&&"object"==typeof i&&i instanceof URL&&(r=i.href),T(this,r);var o=(""+(i&&i instanceof Y&&i.method||n.method||"GET")).toUpperCase();this.params.method=o,this.txSize=V(n.body)||0}function A(t,r){var n;this.endTime=(0,p.z)(),this.params||(this.params={}),this.params.status=r?r.status:0,"string"==typeof this.rxSize&&this.rxSize.length>0&&(n=+this.rxSize);var o={txSize:this.txSize,rxSize:n,duration:(0,p.z)()-this.startTime};i("xhr",[this.params,o,this.startTime,this.endTime,"fetch"],this,e.D.ajax)}function E(t){var r=this.params,n=this.metrics;if(!this.ended){this.ended=!0;for(var o=0;o 2&&void 0!==arguments[2])||arguments[2];super(e,t,we.t,r),this.importAggregator()}}new class{constructor(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:(0,_.ky)(16);c._A?(this.agentIdentifier=t,this.sharedAggregator=new y({agentIdentifier:this.agentIdentifier}),this.features={},this.desiredFeatures=new Set(e.features||[]),this.desiredFeatures.add(m),Object.assign(this,(0,a.j)(this.agentIdentifier,e,e.loaderType||"agent")),this.start()):(0,l.Z)("Failed to initial the agent. Could not determine the runtime environment.")}get config(){return{info:(0,t.C5)(this.agentIdentifier),init:(0,t.P_)(this.agentIdentifier),loader_config:(0,t.DL)(this.agentIdentifier),runtime:(0,t.OP)(this.agentIdentifier)}}start(){const t="features";try{const r=n(this.agentIdentifier),i=[...this.desiredFeatures];i.sort(((t,r)=>e.p[t.featureName]-e.p[r.featureName])),i.forEach((t=>{if(r[t.featureName]||t.featureName===e.D.pageViewEvent){const n=function(t){switch(t){case e.D.ajax:return[e.D.jserrors];case e.D.sessionTrace:return[e.D.ajax,e.D.pageViewEvent];case e.D.sessionReplay:return[e.D.sessionTrace];case e.D.pageViewTiming:return[e.D.pageViewEvent];default:return[]}}(t.featureName);n.every((e=>r[e]))||(0,l.Z)("".concat(t.featureName," is enabled but one or more dependent features has been disabled (").concat((0,D.P)(n),"). This may cause unintended consequences or missing data...")),this.features[t.featureName]=new t(this.agentIdentifier,this.sharedAggregator)}})),(0,T.Qy)(this.agentIdentifier,this.features,t)}catch(e){(0,l.Z)("Failed to initialize all enabled instrument classes (agent aborted) -",e);for(const e in this.features)this.features[e].abortHandler?.();const r=(0,T.fP)();return delete r.initializedAgents[this.agentIdentifier]?.api,delete r.initializedAgents[this.agentIdentifier]?.[t],delete this.sharedAggregator,r.ee?.abort(),delete r.ee?.get(this.agentIdentifier),!1}}}({features:[J,m,S,class extends h{static featureName=oe;constructor(t,r){if(super(t,r,oe,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;const n=this.ee;let i;(0,k.QU)(n),this.eventsEE=(0,k.em)(n),this.eventsEE.on(se,(function(e,t){this.bstStart=(0,p.z)()})),this.eventsEE.on(ae,(function(t,r){(0,s.p)("bst",[t[0],r,this.bstStart,(0,p.z)()],void 0,e.D.sessionTrace,n)})),n.on(ce+ne,(function(e){this.time=(0,p.z)(),this.startPath=location.pathname+location.hash})),n.on(ce+ie,(function(t){(0,s.p)("bstHist",[location.pathname+location.hash,this.startPath,this.time],void 0,e.D.sessionTrace,n)}));try{i=new PerformanceObserver((t=>{const r=t.getEntries();(0,s.p)(te,[r],void 0,e.D.sessionTrace,n)})),i.observe({type:re,buffered:!0})}catch(e){}this.importAggregator({resourceObserver:i})}},C,xe,B,class extends h{static featureName=de;constructor(e,r){if(super(e,r,de,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;if(!(0,t.OP)(e).xhrWrappable)return;try{this.removeOnAbort=new AbortController}catch(e){}let n,i=0;const o=this.ee.get("tracer"),a=(0,k._L)(this.ee),s=(0,k.Lg)(this.ee),u=(0,k.BV)(this.ee),d=(0,k.Kf)(this.ee),f=this.ee.get("events"),l=(0,k.u5)(this.ee),h=(0,k.QU)(this.ee),g=(0,k.Gm)(this.ee);function m(e,t){h.emit("newURL",[""+window.location,t])}function v(){i++,n=window.location.hash,this[ve]=(0,p.z)()}function b(){i--,window.location.hash!==n&&m(0,!0);var e=(0,p.z)();this[pe]=~~this[pe]+e-this[ve],this[ye]=e}function y(e,t){e.on(t,(function(){this[t]=(0,p.z)()}))}this.ee.on(ve,v),s.on(be,v),a.on(be,v),this.ee.on(ye,b),s.on(ge,b),a.on(ge,b),this.ee.buffer([ve,ye,"xhr-resolved"],this.featureName),f.buffer([ve],this.featureName),u.buffer(["setTimeout"+le,"clearTimeout"+fe,ve],this.featureName),d.buffer([ve,"new-xhr","send-xhr"+fe],this.featureName),l.buffer([me+fe,me+"-done",me+he+fe,me+he+le],this.featureName),h.buffer(["newURL"],this.featureName),g.buffer([ve],this.featureName),s.buffer(["propagate",be,ge,"executor-err","resolve"+fe],this.featureName),o.buffer([ve,"no-"+ve],this.featureName),a.buffer(["new-jsonp","cb-start","jsonp-error","jsonp-end"],this.featureName),y(l,me+fe),y(l,me+"-done"),y(a,"new-jsonp"),y(a,"jsonp-end"),y(a,"cb-start"),h.on("pushState-end",m),h.on("replaceState-end",m),window.addEventListener("hashchange",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("load",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("popstate",(function(){m(0,i>1)}),(0,O.m$)(!0,this.removeOnAbort?.signal)),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}}],loaderType:"spa"})})(),window.NRBA=o})(); window.jQuery || document.write(' ') CKEDITOR_BASEPATH='https://f1000research.com/js/vendor/ckeditor/' window.reactTheme = 'research'; window.MathJax = { CommonHTML: { linebreaks: { automatic: true } }, 'HTML-CSS': { linebreaks: { automatic: true } }, SVG: { linebreaks: { automatic: true } }, AuthorInit: function() { MathJax.Hub.Register.MessageHook('End Process', function () { let timeout = false; // holder for timeout id const delay = 250; // delay after event is "complete" to run callback const reflowMath = function() { const dispFormulas = document.querySelectorAll('.disp-formula.panel'); if (!dispFormulas) { return; } for (const dispFormula of dispFormulas) { const child = dispFormula.querySelector('.MathJax_Preview').nextSibling.firstChild; const isMultiline = MathJax.Hub.getAllJax(dispFormula)[0].root.isMultiline; if (dispFormula.offsetWidth < child.offsetWidth || isMultiline) { MathJax.Hub.Queue(['Rerender', MathJax.Hub, dispFormula]); } } }; window.addEventListener('resize', function() { clearTimeout(timeout); // clear the timeout timeout = setTimeout(reflowMath, delay); // start timing for event "completion" }); }); }, }; if (window.location.hash == '#_=_'){ window.location = window.location.href.split('#')[0] } !function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function() {n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)} ;if(!f._fbq)f._fbq=n; n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window, document,'script','https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '1641728616063202'); fbq('track', "PixelInitialized", {}); (function(h,o,t,j,a,r){ h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)}; h._hjSettings={hjid:2318163,hjsv:6}; a=o.getElementsByTagName('head')[0]; r=o.createElement('script');r.async=1; r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv; a.appendChild(r); })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv='); search file_upload Submit your research search menu close search Browse Gateways & Collections How to Publish Submit your Research My Submissions Article Guidelines Article Guidelines (New Versions) Open Data, Software and Code Guidelines Open Data and Accessible Source Materials Guidelines (HSS) Open Data, Software and Code Guidelines (PSE) Prepublication Checks Production Process Posters and Slides Guidelines Document Guidelines Article Processing Charges Peer Review Finding Article Reviewers About How it Works For Reviewers Our Advisors Policies Glossary FAQs For Developers Newsroom Contact My Research Submissions Content and Tracking Alerts My Details Sign In file_upload Submit your research { "@context": "https://schema.org", "@type": "ScholarlyArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://f1000research.com/articles/13-1429" }, "headline": "Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and...", "datePublished": "2024-11-26T16:50:00", "dateModified": "2025-09-08T09:24:02", "author": [ { "@type": "Person", "name": "Florian Goth" }, { "@type": "Person", "name": "Renato Alves" }, { "@type": "Person", "name": "Matthias Braun" }, { "@type": "Person", "name": "Leyla Jael Castro" }, { "@type": "Person", "name": "Gerasimos Chourdakis" }, { "@type": "Person", "name": "Simon Christ" }, { "@type": "Person", "name": "Jeremy Cohen" }, { "@type": "Person", "name": "Stephan Druskat" }, { "@type": "Person", "name": "Fredo Erxleben" }, { "@type": "Person", "name": "Jean-Noël Grad" }, { "@type": "Person", "name": "Magnus Hagdorn" }, { "@type": "Person", "name": "Toby Hodges" }, { "@type": "Person", "name": "Guido Juckeland" }, { "@type": "Person", "name": "Dominic Kempf" }, { "@type": "Person", "name": "Anna-Lena Lamprecht" }, { "@type": "Person", "name": "Jan Linxweiler" }, { "@type": "Person", "name": "Frank Löffler" }, { "@type": "Person", "name": "Michele Martone" }, { "@type": "Person", "name": "Moritz Schwarzmeier" }, { "@type": "Person", "name": "Heidi Seibold" }, { "@type": "Person", "name": "Jan Philipp Thiele" }, { "@type": "Person", "name": "Harald von Waldow" }, { "@type": "Person", "name": "Samantha Wittke" } ], "publisher": { "@type": "Organization", "name": "F1000Research", "logo": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 480, "width": 60 } }, "image": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 1200, "width": 150 }, "description": "The term Research Software Engineer, or RSE, emerged a little over 10 years ago as a way to represent individuals working in the research community but focusing on software development. The term has been widely adopted and there are a number of high-level definitions of what an RSE is. However, the roles of RSEs vary depending on the institutional context they work in. At one end of the spectrum, RSE roles may look similar to a traditional research role. At the other extreme, they resemble that of a software engineer in industry. Most RSE roles inhabit the space between these two extremes. Therefore, providing a straightforward, comprehensive definition of what an RSE does and what experience, skills and competencies are required to become one is challenging. In this community paper we define the broad notion of what an RSE is, explore the different types of work they undertake, and define a list of foundational competencies as well as values that outline the general profile of an RSE. These foundational skills are encountered to a large extent within the skill sets of current RSEs in Germany and beyond, and we propose them as a starting point for aspiring RSEs to shape their technical profile. Further research and training can build upon this foundation of skills and focus on various aspects in greater detail. We expect that graduates and practitioners will have a larger and more diverse set of skills than outlined here. On this basis, we elaborate on the progression of these skills along different dimensions. We look at specific types of RSE roles, propose recommendations for organisations, give examples of future specialisations, and detail how existing curricula fit into this framework." } { "@context": "http://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": "1", "item": { "@id": "https://f1000research.com/", "name": "Home" } }, { "@type": "ListItem", "position": "2", "item": { "@id": "https://f1000research.com/browse/articles", "name": "Browse" } }, { "@type": "ListItem", "position": "3", "item": { "@id": "https://f1000research.com/articles/13-1429", "name": "Foundational Competencies and Responsibilities of a Research Software..." } } ] } Home Browse Foundational Competencies and Responsibilities of a Research Software... ALL Metrics - Views Downloads Get PDF Get XML Cite How to cite this article Goth F, Alves R, Braun M et al. Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.12688/f1000research.157778.2 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. Close Copy Citation Details Export Export Citation Sciwheel EndNote Ref. Manager Bibtex ProCite Sente EXPORT Select a format first Track Share ▬ ✚ Opinion Article Revised Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] Previously titled: Foundational Competencies and Responsibilities of a Research Software Engineer Florian Goth https://orcid.org/0000-0003-2707-4790 1 , Renato Alves https://orcid.org/0000-0002-7212-0234 2 , Matthias Braun 3 , [...] Leyla Jael Castro https://orcid.org/0000-0003-3986-0510 4 , Gerasimos Chourdakis https://orcid.org/0000-0002-3977-1385 5,6 , Simon Christ https://orcid.org/0000-0002-5866-1472 7 , Jeremy Cohen https://orcid.org/0000-0003-4312-2537 8 , Stephan Druskat https://orcid.org/0000-0003-4925-7248 9 , Fredo Erxleben 10 , Jean-Noël Grad https://orcid.org/0000-0002-5821-4912 11 , Magnus Hagdorn https://orcid.org/0000-0002-5076-4864 12 , Toby Hodges 13 , Guido Juckeland https://orcid.org/0000-0002-9935-4428 10 , Dominic Kempf https://orcid.org/0000-0002-6140-2332 14 , Anna-Lena Lamprecht https://orcid.org/0000-0003-1953-5606 15 , Jan Linxweiler https://orcid.org/0000-0002-2755-5087 16 , Frank Löffler https://orcid.org/0000-0001-6643-6323 17 , Michele Martone https://orcid.org/0000-0003-3239-8554 18 , Moritz Schwarzmeier https://orcid.org/0000-0001-8992-6245 19 , Heidi Seibold https://orcid.org/0000-0002-8960-9642 20 , Jan Philipp Thiele https://orcid.org/0000-0002-8901-6660 21,22 , Harald von Waldow https://orcid.org/0000-0003-4800-2833 23 , Samantha Wittke https://orcid.org/0000-0002-9625-7235 24 Florian Goth https://orcid.org/0000-0003-2707-4790 1 , Renato Alves https://orcid.org/0000-0002-7212-0234 2 , [...] Matthias Braun 3 , Leyla Jael Castro https://orcid.org/0000-0003-3986-0510 4 , Gerasimos Chourdakis https://orcid.org/0000-0002-3977-1385 5,6 , Simon Christ https://orcid.org/0000-0002-5866-1472 7 , Jeremy Cohen https://orcid.org/0000-0003-4312-2537 8 , Stephan Druskat https://orcid.org/0000-0003-4925-7248 9 , Fredo Erxleben 10 , Jean-Noël Grad https://orcid.org/0000-0002-5821-4912 11 , Magnus Hagdorn https://orcid.org/0000-0002-5076-4864 12 , Toby Hodges 13 , Guido Juckeland https://orcid.org/0000-0002-9935-4428 10 , Dominic Kempf https://orcid.org/0000-0002-6140-2332 14 , Anna-Lena Lamprecht https://orcid.org/0000-0003-1953-5606 15 , Jan Linxweiler https://orcid.org/0000-0002-2755-5087 16 , Frank Löffler https://orcid.org/0000-0001-6643-6323 17 , Michele Martone https://orcid.org/0000-0003-3239-8554 18 , Moritz Schwarzmeier https://orcid.org/0000-0001-8992-6245 19 , Heidi Seibold https://orcid.org/0000-0002-8960-9642 20 , Jan Philipp Thiele https://orcid.org/0000-0002-8901-6660 21,22 , Harald von Waldow https://orcid.org/0000-0003-4800-2833 23 , Samantha Wittke https://orcid.org/0000-0002-9625-7235 24 PUBLISHED 08 Sep 2025 Author details Author details 1 Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universität Würzburg, Würzburg, Bavaria, Germany 2 European Molecular Biology Laboratory, Heidelberg, Baden-Württemberg, Germany 3 Cluster of Excellence IntCDC, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 4 ZB MED Information Centre for Life Sciences, Cologne, North Rhine-Westphalia, Germany 5 Institute for Parallel and Distributed Systems, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 6 School of Computation, Information and Technology, Technical University of Munich, Garching, Bavaria, Germany 7 Leibniz University Hannover, Department of Cell Biology and Biophysics, Hanover, Lower Saxony, Germany 8 Department of Computing, Imperial College London, London, England, UK 9 Institute of Software Technology, German Aerospace Center DLR Berlin, Berlin, Berlin, Germany 10 Helmholtz-Zentrum Dresden-Rossendorf, Dresden, Saxony, Germany 11 Institute for Computational Physics, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 12 Geschäftsbereich IT, Charité Universitätsmedizin Berlin, Berlin, Berlin, Germany 13 The Carpentries, Oakland, California, USA 14 Scientific Software Center, Universität Heidelberg, Heidelberg, Baden-Württemberg, Germany 15 Institute of Computer Science, University of Potsdam, Potsdam, Brandenburg, Germany 16 Technische Universität Braunschweig, Brunswick, Lower Saxony, Germany 17 Michael Stifel Center Jena, Friedrich Schiller University Jena, Jena, Thuringia, Germany 18 Bavarian Academy of Sciences and Humanities Leibniz Supercomputing Centre, Garching, Bavaria, Germany 19 Mathematical Modeling and Analysis, TU Darmstadt Department of Mathematics, Darmstadt, Hesse, Germany 20 Institute for Globally Distributed Open Research and Education, Gothenburg, Västra Götaland County, Sweden 21 Weierstrass Institute for Applied Analysis and Stochastics, Berlin, Berlin, Germany 22 Scientific Computing, Leibniz University Hannover Institute of Applied Mathematics, Hanover, Lower Saxony, Germany 23 Centre for Information Management, Johann Heinrich von Thünen Institute, Braunschweig, Lower Saxony, Germany 24 CSC IT Center for Science Ltd, Espoo, Uusimaa, Finland Florian Goth Roles: Data Curation, Funding Acquisition, Project Administration, Supervision, Writing – Original Draft Preparation, Writing – Review & Editing Renato Alves Roles: Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing Matthias Braun Roles: Data Curation, Writing – Review & Editing Leyla Jael Castro Roles: Writing – Review & Editing Gerasimos Chourdakis Roles: Data Curation, Writing – Review & Editing Simon Christ Roles: Software, Visualization, Writing – Review & Editing Jeremy Cohen Roles: Writing – Original Draft Preparation, Writing – Review & Editing Stephan Druskat Roles: Writing – Review & Editing Fredo Erxleben Roles: Writing – Review & Editing Jean-Noël Grad Roles: Software, Writing – Original Draft Preparation, Writing – Review & Editing Magnus Hagdorn Roles: Data Curation, Writing – Review & Editing Toby Hodges Roles: Data Curation, Writing – Review & Editing Guido Juckeland Roles: Writing – Review & Editing Dominic Kempf Roles: Writing – Review & Editing Anna-Lena Lamprecht Roles: Writing – Review & Editing Jan Linxweiler Roles: Writing – Original Draft Preparation, Writing – Review & Editing Frank Löffler Roles: Writing – Review & Editing Michele Martone Roles: Writing – Review & Editing Moritz Schwarzmeier Roles: Writing – Review & Editing Heidi Seibold Roles: Conceptualization, Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing Jan Philipp Thiele Roles: Data Curation, Project Administration, Writing – Original Draft Preparation, Writing – Review & Editing Harald von Waldow Roles: Writing – Review & Editing Samantha Wittke Roles: Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing OPEN PEER REVIEW DETAILS REVIEWER STATUS This article is included in the Software and Hardware Engineering gateway. This article is included in the Research on Research, Policy & Culture gateway. This article is included in the EMBL-EBI collection. Abstract The term Research Software Engineer, or RSE, emerged a little over 10 years ago as a way to represent individuals working in the research community but focusing on software development. The term has been widely adopted and there are a number of high-level definitions of what an RSE is. However, the roles of RSEs vary depending on the institutional context they work in. At one end of the spectrum, RSE roles may look similar to a traditional research role. At the other extreme, they resemble that of a software engineer in industry. Most RSE roles inhabit the space between these two extremes. Therefore, providing a straightforward, comprehensive definition of what an RSE does and what experience, skills and competencies are required to become one is challenging. In this community paper we define the broad notion of what an RSE is, explore the different types of work they undertake, and define a list of foundational competencies as well as values that outline the general profile of an RSE. These foundational skills are encountered to a large extent within the skill sets of current RSEs in Germany and beyond, and we propose them as a starting point for aspiring RSEs to shape their technical profile. Further research and training can build upon this foundation of skills and focus on various aspects in greater detail. We expect that graduates and practitioners will have a larger and more diverse set of skills than outlined here. On this basis, we elaborate on the progression of these skills along different dimensions. We look at specific types of RSE roles, propose recommendations for organisations, give examples of future specialisations, and detail how existing curricula fit into this framework. READ ALL READ LESS Keywords research software engineering, RSE, competencies, curriculum design, teaching Corresponding Author(s) Florian Goth ( [email protected] ) Close Corresponding author: Florian Goth Competing interests: No competing interests were disclosed. Grant information: FG acknowledges funding from the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) through the SFB 1170 “Tocotronics”, project Z03 - project number 258499086 as well as financial support by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy through the Würzburg-Dresden Cluster of Excellence on Complexity and Topology in Quantum Matter – ct.qmat (EXC 2147, project-id 390858490). MB acknowledges support by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy – EXC 2120/1 – 390831618. LJC acknowledges support from the NFDI4DS consortium funded by the German Research Foundation (DFG) - project number 460234259. JC acknowledges support from the UK Engineering and Physical Sciences Research Council (UKRI-EPSRC) under grants EP/R025460/1, EP/W035731/1 and EP/Y530608/1. JNG acknowledges funding from the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) - project number 391126171 (PI: Holm), from the German Federal Ministry of Education and Research (Bundesmin- isteriums für Bildung und Forschung, BMBF) under the funding code 16HPC095, and from the European Union – this work has received funding from the European High Performance Computing Joint Undertaking (JU) and countries participating in the project under grant agreement No 101093169. DK is funded by the Scientific Software Center which is part of the Excellence Strategy of the German Federal and State Governments. MM is funded by the SiVeGCS Project. MS would like to thank Hessian Ministry of Higher Education, Research, Science and the Arts and the Federal Government and the Heads of Government of the Länder, as well as the Joint Science Conference (GWK), for their funding and support within the framework of the NFDI4Ing consortium. Part of this work was funded by the German Research Foundation (DFG) - project number 442146713. Part of this work was funded by the Hessian Ministry of Higher Education, Research, Science and the Arts - cluster project Clean Circles. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. Copyright: © 2025 Goth F et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. How to cite: Goth F, Alves R, Braun M et al. Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.12688/f1000research.157778.2 ) First published: 26 Nov 2024, 13 :1429 ( https://doi.org/10.12688/f1000research.157778.1 ) Latest published: 08 Sep 2025, 13 :1429 ( https://doi.org/10.12688/f1000research.157778.2 ) Revised Amendments from Version 1 From version 1 to version 2 we considered the reports of the referees and adapted our manuscript to include their feedback. This led to the inclusion of a subtitle into the manuscripts header. On top of that we fixed numerous formatting issues that now hopefully provide for a better online reading experience and the figures have been redone. From version 1 to version 2 we considered the reports of the referees and adapted our manuscript to include their feedback. This led to the inclusion of a subtitle into the manuscripts header. On top of that we fixed numerous formatting issues that now hopefully provide for a better online reading experience and the figures have been redone. See the authors' detailed response to the review by Uwe Schmitt See the authors' detailed response to the review by Miranda Mundt READ REVIEWER RESPONSES Contents Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions1 [version 1; peer review: 2 approved]1 Abstract6 Contents6 1. Introduction9 1.1 Terminology10 1.1.1 The term Research Software Engineer10 1.1.2 Further definitions11 2. Related work11 3. Values13 3.1 Current challenges14 3.1.1 Data security14 3.1.2 Mentoring and diversity14 3.1.3 Shaping digital science15 3.1.4 Addressing environmental sustainability within planetary limits15 3.1.5 Emerging challenges15 4. Foundational RSE competencies15 4.1 Software/Technical skills16 4.1.1 Classical software engineering skills16 4.1.2 Adapting to the software life cycle ( SWLC)17 4.1.3 Creating documented code building blocks ( DOCBB)17 4.1.4 Building distributable software ( DIST)17 4.1.5 Use software repositories ( SWREPOS)18 4.1.6 Software behaviour awareness and analysis ( MOD)18 4.2 Research skills18 4.2.1 Conducting and leading research ( NEW)18 4.2.2 Understanding the research cycle ( RC)18 4.2.3 Software re-use ( SRU)19 4.2.4 Software publication and citation ( SP)19 4.2.5 Using domain repositories/directories ( DOMREP)19 4.3 Communication skills20 4.3.1 Working in a team ( TEAM)20 4.3.2 Teaching ( TEACH)20 4.3.3 Project management ( PM)20 4.3.4 Interaction with users and other stakeholders ( USERS)20 4.4 RSE tasks and responsibilities21 5. How much do different people need to know?23 5.1 Career level23 Table 1. Levels of technical skills expected per RSE career stage.24 Table 2. Levels of research skills expected per RSE career stage.24 Table 3. Levels of communication skills expected per RSE career stage.25 5.2 Helpful RSE skills for researchers in an academic career26 5.3 Project team structures27 Table 4. Levels of software eng. skills expected per team structure.28 Table 5. Levels of research skills expected per team structure.30 Table 6. Levels of communication skills expected per team structure.32 5.4 Designing a generalist RSE framework33 5.4.1 An example master’s programme for research software engineering33 5.4.2 An example of a possible career path35 6. RSE specialisations37 6.1 Specialisations within the core RSE competencies37 6.2 Specialisations outside the core RSE competencies38 6.3 Existing frameworks for specialised RSE roles39 6.3.1 Bioinformatics skills and certification39 6.3.2 HPC skills and certification40 7. Future work41 8. Conclusion41 Contribution details42 Ethics and consent43 Glossary43 Skill codes44 Acronyms44 Data availability statement46 Acknowledgements46 References46 Article Information (continued)51 1. Introduction Computers and software have played a key role in the research life cycle for many decades. They are now vital elements of the research process across almost all domains. They enable researchers to collect and process ever-increasing amounts of data, simulate a wide range of physical phenomena across previously unexplored scales of the universe, and discover previously inconceivably complex structures in nature and societies via machine learning (ML). This prevalence of computation and digitally-aided data analysis in research means that digital skills are now required by researchers at all career levels, and in fields significantly beyond those that would previously have been expected. Research software is now used and developed not only in science, technology, engineering and mathematics (STEM) domains, but also in other fields, like medicine and the humanities. Researchers often lack the skills to use specialised software for their research, let alone write it. 97 If they come from a non-technical domain, they may also struggle to know what to ask when trying to request help from and interact with more experienced colleagues. A gap still exists in academic education, as many curricula do not sufficiently prepare students in this regard. This situation is exemplified by the extracurricular Massachusetts Institute of Technology (MIT) class “The Missing Semester of Your CS Education”, 3 which aims to increase “computing ecosystem literacy” even among students of Computer Science at MIT. Researchers investing increasing amounts of their time developing their software engineering (SE) skills to support their research work can find themselves with little time to do the research itself. This, in turn, presents career development challenges since the experience required to gain and progress in research and academic roles is traditionally assessed through metrics that do not directly include software outputs. A recent shift towards the establishment of the distinct role of a “Research Software Engineer” 69 (RSE, a term that was coined in the United Kingdom (UK) a little over 10 years ago 43 ), now provides a base on which sustainable career opportunities can be (and are being) built, allowing for better training of researchers and more effective support for the development of high quality research software. There is still a long way to go, but positive change is well underway. RSEs may work within one of the increasing number of research software engineering teams that have been set up at universities and research organisations over the past decade, or they may be embedded within a research team. They may have a job title that officially recognises them as an RSE, or they may have a standard research or technical job title such as Research Assistant, Research Fellow, or Software Engineer. Regardless of their job title, RSEs share a set of core skills that are required to design and develop research software, understand the research environment, and ensure that they produce sustainable, maintainable code that supports reproducible research outputs, following the Findability, Accessibility, Interoperability and Reusability (FAIR) principles. 5 This community paper defines a set of core values and foundational competencies, which an RSE should acquire during training and formal education. These skills are formulated independently of a specific research domain and current technical tools used to support the application of the skills. By defining these competencies, we provide a guiding framework to facilitate the training and continuous professional development of RSEs, thus helping to provide a positive impact on research outputs and, ultimately, society as a whole. These competencies draw upon skills from traditional SE practice, established research culture, and the commitment to being part of a team. However, we see this set of skills as a foundation to build upon. We envision that through specialised training, the set of skills of graduate RSEs and domain researchers will grow. This is underlined by a growing interest to perform RSE research, i.e. research into methods and tools more catered to the unique challenges that research software provides. While this community paper is based on workshop discussions that were attended largely by RSEs (deRSE23 in Paderborn, 37 un-deRSE23 in Jena, and deRSE24 in Würzburg, all in Germany), we believe that the competencies formulated here can offer far-reaching impact beyond the domain of RSE into adjacent aspects of research and, indeed, the wider research community. This is especially important given that much research involves some amount of data management, processing and visualisation, or the creation of tools for these tasks, and funding bodies and computing infrastructure providers will sometimes prioritise projects that generate archived, annotated, re-usable, and potentially remotely executable data. In particular, funding agencies and research managers will find the discussion in this paper valuable in order to discover where RSEs see their place in the existing landscape of scientific domains and how to support the work of RSEs at different positions and career levels. While we draw mostly from experiences of RSEs working in Germany or, in some cases, across Europe and the US, our recommendations do not focus on a particular region. The outline of the paper is as follows. We start with a non-exhaustive overview of existing initiatives in Section 2 . Section 3 elaborates on the values that provide the guiding principles for the work of an RSE. Section 4 defines a set of core skills based on these values. We categorise these skills into three pillars, namely “software/technical”, “research”, and “communication” skills, reflecting the hybrid nature of an RSE. To justify the selection of these skills, we also list some current tasks and discuss the skills used therein. As with any general skill set, not all RSEs will need to use all the skills highlighted to the same level of expertise. Therefore, Section 5 examines how much a person needs to know depending on their education or career level or on the type of projects they would like to be involved with. In the same section, we provide an overview of what skills and limitations an RSE in different team structures typically has, and we give recommendations for organisations that need to support RSEs. Section 6 provides a list of RSE specialisations and discusses the level of skill needed to work in each of them, before we conclude the paper with details of future work in Section 7 and conclusions in Section 8 . 1.1 Terminology 1.1.1 The term Research Software Engineer Research Software Engineering can be considered an interface discipline, linking traditional Software Engineering with Research itself. 57 Due to this nature there is a plethora of different variations of RSE depending on the particular Research domain they are working in. Therefore the broad notion of Research Software Engineers is better thought of as a collection of sub-communities. The term Research Software Engineer is made more difficult to grasp since an internationally recognised definition is still missing. While there is consensus about the general notion that an RSE is a person with one leg in their research domain and the other in software development, this spans a whole spectrum depending on which one is more emphasised. There is also the question of what level of professionalism concerning both non-SE research and SE is expected. A more inclusive definition allows more people to self-identify as RSEs, thereby also fostering an inclusive community of people working in digital science (see also Section 3 on the values of an RSE). RSEs fall therefore somewhere on the spectrum between a researcher at one end and a software engineer at the other. Common to all of them is, that they need to be able to work in the research environment the software is used in, ideally at eye-level with native researchers, but at least as close as possible. RSEs often need to deal with non-technical complexities that are characteristic for research environments: organisational, motivational, with respect to the size of projects, independence and heterogeneous goals of stakeholders, boundary conditions for funding and future funding, to name just a few. Summarising, RSEs have skills and experience in three important areas: in the research area(s) their software is used in, in software engineering topics, as well as in interdisciplinary communication. 1.1.2 Further definitions Depending on the national research environments and processes that readers are familiar with, the notion of the terms software and research might differ. Therefore, to avoid ambiguities, we define these as follows: Software : Source code, documentation, tests, executables and all other artefacts that are created during the development process that are necessary to understand its purpose. Research software : Foundational algorithms, the software itself, as well as scripts and computational workflows that were created during the research process or for a research purpose, across all domains of research. This definition is broader than in 5 and is the outcome of a recent discussion in. 40 Research software engineers : People who create or improve research software and/or the structures that the software interacts with in the computational environment of a research domain. They are highly skilled team members who may also choose to conduct their own research as part of their role. However, we also recognise that many RSEs have chosen specifically to focus on a technical role as an alternative to a traditional research role because they enjoy and wish to focus on the development of research software. Researchers : People who are using the services provided by Research Software Engineers. This, on purpose, is a very broad definition and was chosen for a better reading. 2. Related work Various initiatives are working to support technical professionals develop their computational skills. Particularly related to this work are initiatives that aim to define sets of such skills and to guide the community with certification programs and training resources. RSE Competencies Toolkit: The RSE Competencies Toolkit 75 is a community project that developed out of a hack day activity at the 2023 edition of the annual Software Sustainability Institute Collaborations Workshop. 102 The toolkit provides a web application that aims to support technical professionals in understanding how to develop their skills. It enables them to build a profile of their competencies within the system, while it also provides a set of training resources that are linked to a competency framework. HPC Certification Forum: The High-Performance Computing (HPC) Certification Forum 88 is working towards providing a certification process for HPC skills. As part of this process, the group is developing a Competence Standard 89 and an associated skill tree that provides a classification of HPC competencies. This work aims to develop a standardised representation of relevant HPC knowledge and skills which can, in turn, lead to structured and recognised sets of skills that can underpin the certification process. EMBL-EBI Competency Hub: The European Molecular Biology Laboratory - European Bioinformatics Institute (EMBL-EBI) Competency Hub 25 provides a bioinformatics/computational biology-focused example of a competency portal. In addition to collecting information on a range of competencies that can be browsed within the web-based tool, it also provides career profiles for roles within the domains that EMBL-EBI focuses on. The hub provides access to a variety of training resources that are linked to the specific competencies that they relate to. This enables learners to more easily find the right training materials in order to support their career development journey, helping them to identify what they might want to learn and in what order. Training-focused initiatives: Further initiatives implicitly define sets of competencies by providing (open) teaching material for selected skills. This is a non-exhaustive list of related initiatives, which will be discussed in more detail in a separate publication. In some cases, the activities extend beyond training, but they do not focus on defining frameworks of competencies. One prominent example is the Carpentries, 85 a non-profit entity that supports a range of open source training materials and international communities of volunteer instructors and helpers who run courses around these materials. A similar framework is provided by CodeRefinery, 18 currently funded by the Nordic e-Infrastructure, as well as SURESOFT, 8 , 103 a project at Technical University (TU) Braunschweig and Friedrich-Alexander-University (FAU) Erlangen-Nürnberg, funded by the German Research Foundation (DFG, Deutsche Forschungsgemeinschaft) and targeting more advanced SE topics such as software design principles, design patterns , refactoring, continuous integration (CI) and test-driven development (TDD). The INTERSECT RSE Training project 14 , 50 also provides training materials and organises training events in the USA, funded by the NSF. There are also several initiatives focused on training HPC-oriented RSEs, such as the Partnership for Advanced Computing in Europe (PRACE) 72 (with material aggregated on various websites, e.g., on EuroCC Training 26 ), Understanding and Nurturing an Integrated Vision for Education in RSE and HPC (UNIVERSE-HPC) 93 (a project funded under the UK’s ExCALIBUR research programme 30 ), and the EuroCC National Competence Center Sweden (ENCCS), 28 which offers a collection of lessons for HPC skills. 27 At the intersection between HPC and the broader RSE field, the IDEAS PRODUCTIVITY project 47 organises online events, provides training material via the Better Scientific Software (BSSw) project 6 and maintains HPC-focused guidelines, such as the Extreme-scale Scientific Software Development Kit. 100 Initiatives focused on Germany include EduTrain 104 (a section of the National Research Data Infrastructure (Nationale Forschungsdateninfrastruktur) (NFDI) 105 ), the Helmholtz Federated IT Services (HIFIS), 41 and the already mentioned SURESOFT. 103 3. Values It is important that the activities of an RSE are guided by ethical values. In addition to the values for good scientific practice, 33 RSEs also need to adhere to the SE Code of Ethics. 38 Central to that code is the RSE’s obligation to In addition to the values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients. Further values loosely based on that code include the obligations • to commit to objectivity and fact-based, honest research conclusions, • to promote openness and accountability in the research process, • to take great care to develop software that adheres to current best practices, • to judge independently and maintain professional integrity, • to treat colleagues and collaborators with respect and work towards a fair and inclusive environment, and • to promote these values whenever possible and make sure that they are passed on to new practitioners. Many practitioners will follow the values expressed in these codes of conduct without knowing them because they are passed on implicitly by their peers and mentors. 19 Here, they are stated explicitly because they underpin the foundational competencies and responsibilities of RSEs who are professionals living in both worlds. The deployment of computer-based modelling and simulation has dramatically changed the practice of science in a large number of fields. It has enabled the hitherto impossible study of new classes of problems, often replacing traditional experimentation and observation (it can also serve to integrate a communal body of knowledge). 71 Thereby it has the potential of changing our way of generating knowledge, while at the same time it challenges our notions of explaining science. Humphreys 46 regards this development as “more important than the invention of calculus in the 1660s, an event that remained unparalleled for almost 300 years”. The epistemological status of computer modelling and simulation is still the subject of debate, which ranges from the postulate of a new process of knowledge creation that has its own, unique, epistemology 99 to the perception that from a philosophy of science perspective, there is nothing really new. 31 In any case, it is clear that a number of decisions in the construction of a simulation-model will have a significant impact on the adequacy for purpose 9 of the model. These decisions include the selection of the salient characteristics of the system to be modelled, the choice of the mathematical representation of the processes to be represented, the choice of numerical methods and other algorithms and even including the design of the user-interface. The relationship between initial state, inputs and final state of a computer simulation is “epistemically opaque”, 46 in that not every step of the process is directly observable. The current trend of an increasing application of computationally irreducible systems, such as those based on artificial neural networks, further exacerbates this inherent limitation of explainability. An RSE usually takes a pivotal role in assessing this adequacy for purpose of a model as well as in characterising and communicating the domain of its legitimate application and its limits of interpretability. This role, together with the enormous reliance on modelling and simulation of scientific results, as well as real-world decision-making, places a large responsibility on the RSE. It is important that RSEs are aware of this responsibility and continuously improve their capabilities to live up to it. Research software is also well on its way to being ever-present in data-driven research, in all research fields. This can probably be most prominently seen by considering software used to analyse data, e.g. within experimental research. It is not unusual for RSEs to support those more research data oriented efforts as well. Here, specifically, they closely interact with research data management professionals and practices by designing research software that is better able to adhere to the FAIR principles for research data, but also to follow similar rules for research software (FAIR4RS 5 ). As such, they are then familiar with special requirements stemming from the field itself, e.g., in medical research, and with privacy related issues especially for personal data, e.g., for conducting surveys. RSEs often assume a multifaceted role at the junction of research, SE and data management. They work with a varying and diverse set of colleagues that might include other developers, support unit staff and academics of different fields and all career stages. This situation yields a specific set of challenges RSEs should be aware of to consciously make ethically sound judgement calls. Below we list some example areas that highlight present-day challenges. 3.1 Current challenges 3.1.1 Data security A lot of RSE work involves the manipulation or creation of data processing tools. We highlight that professional conduct requires these creations to be reliable and to maintain data integrity. In particular, the way that personal data is handled can have far-reaching implications for society. Independent of the encoding into the respective national law in an RSE’s jurisdiction, the right to information privacy is internationally recognised as a fundamental human right, e.g., in the European Convention on Human Rights. 20 , 45 RSEs need to be aware of this topic’s importance and deal with tensions that might arise with researchers’ desire for trouble-free sharing of data, thereby expecting openness about the research process, versus the integrity expectations of the society towards information technology (IT) systems. Handling personal data also has ramifications for information security considerations during the software development process. Data protection is a complex topic, so RSEs should be aware that they may need to consult external expertise, for example when dealing with special topics such as cryptography or re-identification attacks. 42 3.1.2 Mentoring and diversity RSEs are often experienced professionals who work closely with and provide technical training and guidance to early career researchers. Similarly to academic supervisors, they bear a certain responsibility to guide and advise less-experienced colleagues with respect to career development and the achievement of academic goals. This can take the form of supervising a student or mentoring a fellow RSE. The RSE needs to be aware of the biases arising from the sociological imbalances in research and academia. According to the United Nations Educational, Scientific and Cultural Organization (UNESCO) Science Report 78 women account for 33.3% of all researchers. 60.2% of researchers come from high-income countries which account for 17.5% of the global population in 2018. Furthermore, the socioeconomic background of academics is not representative of the general population, for example in the US a tenure-track academic is 25 times more likely to have a parent with a PhD. 65 Thereby, to promote their values of an honest, open, and inclusive research space, they should be aware of the diversity problems and help to mitigate them whenever they have the chance to do so. 3.1.3 Shaping digital science Through writing research software, RSEs hold an important role in the process of scientific production. Their choices might determine whether the respective research is reproducible or not, whether the results can be re-used, whether future research can build on existing tools or has to start from scratch. Builders of larger research-infrastructure projects determine to some extent the possibilities and limitations of future research and therefore need to be able to make a value-based judgement on topics such as open science, path dependence, and vendor lock-in. 3.1.4 Addressing environmental sustainability within planetary limits The last two decades saw transistor technology approach the limits of attainable miniaturisation, and maximum chip clock frequency begin to plateau. 84 Nevertheless, a misleading belief in limitless growth of computing capabilities (storage, computing power, transfer speed) is still widespread within popular perception. A practical consequence of this is an ever-growing demand for resources to cover the expanding need of storage and processing, with no clear deceleration in sight (e.g. the IEA estimates a doubling in data centres energy consumption from 2024 to 2026 48 ). At the same time, current science is well aware of several planetary boundaries being exceeded due to human activities. 74 Data processing, storage and transfer account for a non-negligible fraction. 48 Demands to move resource consumption to a sustainable rate are well justified and supported by science. 81 RSEs have the opportunity to contribute to this effort by, for example, choosing computationally adequate approaches (e.g. recognising where a proven statistical method may suffice in place of a power-hungry AI model, or configuring a test pipeline to minimise redundancy), and embracing data frugality measures (e.g. recognising sufficient resolution when sampling data for processing or storage). If past computational solutions were frugal because of technological limits, in future they should tend to that by virtue of an awareness of what may be adequate. The Governance, Responsibility, Estimation, Energy and embodied impacts, New collaborations, Education and Research (GREENER) principles 59 suggest how these concerns can be addressed and how research computing can become more environmentally sustainable. 3.1.5 Emerging challenges RSEs often operate at the cutting edge of technological development and therefore might have to deal with technologies of which the dangers and drawbacks are still poorly understood. A current example is the rush for the application of large language models (LLMs), where RSEs working in these fields should stay up-to-date and be able to help researchers assess topics such as training-data bias, LLM “hallucinations” or malicious use, with the greater goal of making these powerful tools work for the welfare of society. 4. Foundational RSE competencies The role of an RSE lies somewhere on the spectrum between that of a researcher (the “R”) and a software engineer (the “SE”) and, therefore, requires competencies in both fields. RSEs typically have a background in research or software engineering, but they definitely have obtained broader knowledge in both fields. Even when working as the only RSE on a task or project, they typically apply their knowledge and experience as part of larger teams of researchers and technical professionals, which allows them to cultivate this hybrid nature. There are many ways to categorise the competencies of an RSE. We chose to distribute these competencies over three pillars to reflect the fact that RSEs are both competent researchers (the research skills, Section 4.2 ) and software engineers (the software/technical skills, Section 4.1 ). The third pillar (communication skills, Section 4.3 ) forms the bridge between the former two categories, with a particular focus on the software and research cycle and the scientific process. These competencies are relevant in a broad setting and form the foundation for specific specialisations. These competencies have been chosen in order to make RSEs contribute to an open and inclusive research environment, with tools that respect their professional values (see Section 3 ). These skills and competencies come into play in various forms: The RSEs themselves need to acquire and develop them as their career progresses ( Career level ). However, some knowledge of software and data processing is required at all academic levels and for all positions ( Academic Progression ). The relative importance of the skills and competencies also depends on the size of the RSE team ( Project team size ). Finally, different sets of skills are emphasised in the different RSE specialisations ( RSE specialisations ). During the Paderborn workshop (deRSE23) we asked learners and novice RSEs what they would like to have learnt. The top five items mentioned were (Goth et al. 37 ): testing, contributing to large projects, when or why to keep repositories private, high-quality software development, and finding a community. Those topics comprise combinations of the skills and competencies defined below. We will elaborate these in Section 4.4 . 4.1 Software/Technical skills Besides skilled researchers, RSEs are also competent software engineers. As such, they ideally can solve complex software engineering problems and design software as a user-oriented, future-proof product. The technical skills required by an RSE overlap to a large extent with the common fundamental software engineering skills (see, e.g., Landwehr et al. 58 ), but put greater emphasis on aspects related to achieving good scientific practice and to serving special needs of research software. In addition, a lot of RSEs are either self- or peer taught in these skills (see, e.g., figure 14 in Barker et al. 4 ). These skills include requirements analysis, design, construction, testing, program analysis, and maintenance of software. On the other hand, RSEs also know how to make research software adhere to the FAIR principles, 5 and how to achieve different levels of research software reusability (see, e.g., Chue Hong 17 ), while they have deeper understanding of the scientific context around the research software projects they work on. To reflect this, the technical skills listed below complement competencies regarding the standard life cycle of software development (as summarised in Section 4.1.1 ) with RSE-specific focus skills. 4.1.1 Classical software engineering skills To summarise the vast range of the skills a software engineer is typically equipped with, we refer to the Guide to the Software Engineering Body of Knowledge (Bourque, Fairley, and IEEE Computer Society 10 ). Because research software engineering is an interface discipline, RSEs are often stronger in topics more commonly encountered in research software contexts (e.g., mathematical and engineering foundations) than in other areas (e.g., software engineering economics). However, they bring a solid level of competence in all software engineering topics. Therefore, RSEs can set and analyse software requirements in the context of open-ended, question-driven research. They can design software so that it can sustainably grow, often in an environment of rapid turnover of contributors. They are competent in implementing solutions themselves in a wide range of technologies fit for different scientific applications. They can formulate and implement various types of tests, they can independently maintain software and automate operations of the integration and release process. They can provide working, scalable, and future-proof solutions in a professional context and with common project and software management techniques, adapted to the needs of the research environment. Finally, as people who have often gained significant research experience in a particular discipline, they combine the necessary foundations from their domain with software engineering skills to develop complex software. 4.1.2 Adapting to the software life cycle ( SWLC) The traditional software development life cycle defines the stages that form the process of building a piece of software. Initial development generally involves an analytic process where requirements and ideas are gathered and analysed (requirements engineering), followed by formulating a plan to fulfil them (design) that is finally turned into running code (implementation). This is accompanied by different measures of quality control (e.g., reviews, testing), validating and verifying that things work as expected and that they continue to do so when development progresses further. Depending on the software project, this can mean a simple “Think-before-you-do”, or more elaborate and formal processes. 67 Often the development cycles are executed iteratively and incrementally. The life cycle further includes periods of deployment, maintenance and further development (software evolution), as well as software retirement. To assess the current state and needs of the software, the RSE should be familiar with different maturity metrics, e.g. the DLR application classes, 77 the research software maturity model 21 or technology readiness levels (TRLs). Additionally, the research software life cycle extends the traditional life cycle with software publication . The RSE should be aware of this life cycle and be able to predict and cater to the changing needs of a software project as it moves through the stages. 4.1.3 Creating documented code building blocks ( DOCBB) The RSE should be able to create building blocks from source code that are reusable. This ranges from simple libraries of functions up to complex architectures consisting of multiple software packages. An important part of enabling code reusability is the provision of sufficient information in the form of comments within code, documentation or other means. This is vital to ensure that developers and maintainers understand what a piece of software aims to do and how to enable others to use the provided functionality. This is primarily achieved through a “clean” implementation and enhanced by documentation. Documentation ranges from commenting code blocks to using documentation (building) tools. It should be written with consideration for the different audiences who may need it depending on their goals and expertise, for example by following the Diátaxis framework. 73 4.1.4 Building distributable software ( DIST) The RSE should be able to distribute their code on their domain/language specific distribution platforms. This almost always encompasses handling/documenting dependencies with other packages/libraries. It sometimes requires knowledge of using build or package management systems to enable interoperability with other projects. In terms of usability and needs of the user community the RSE should be able to decide whether a library or a framework is the right type of program to build and distribute. 4.1.5 Use software repositories ( SWREPOS) The RSE should be able to identify and use fitting software Forges (often just termed “repos”) to share the artefacts they have created and, if possible, invite the public to scrutinise them in an open review process. These software repositories usually provide facilities for software development, which differentiate them from the domain repositories described later. 4.1.6 Software behaviour awareness and analysis ( MOD) We define this as a certain quality of analytical thinking that enables an RSE to form a mental model of a piece of software in a specific environment (program comprehension). Using that, an RSE should be able to make predictions about a software’s behaviour. This is a required skill for common tasks such as debugging, profiling, optimising, designing good tests, or predicting user interaction. Many tools exist to help with understanding and evaluating existing code, especially from a structural point of view. An RSE should understand their output and its implications. An important facet of this capability relates to information security. RSEs need to consider the safety and integrity of personal data and other sensitive information and make sure that they do not negatively impact the integrity of their institution’s network and computing infrastructure (see Section 3.1.1 ). 4.2 Research skills 4.2.1 Conducting and leading research ( NEW) RSEs are curious and able to conduct research, both on research software engineering, and on their research-wise “home domain” (see also Section 5.4.1 ). Senior RSEs are also able to lead research, and many RSEs have a doctorate. 44 Since RSEs often operate in different research fields, they also gain their reputation from their effectiveness in interacting with researchers from the same or other domains. Therefore, some curiosity together with a broad overview of the research field is required, as this enables the RSE to learn new methods and algorithms directly from domain peers. Similarly, a broad overview of the field of SE research and the growing field of RSE research enables the RSE to learn, apply, and teach new methods and tools for improving the way they develop software. This curiosity, together with the ability to convert it into new ideas, is also reflected when an RSE is actively trying out new tools or discovering related literature from adjacent domains. Lifelong learning is then no longer just a phrase but becomes a motivation to work. 4.2.2 Understanding the research cycle ( RC) One of the key skills that RSEs have is their understanding of how research works. They embrace being part of a larger community which, despite friendly competition, shares the common goal of gaining knowledge to disseminate it. Thereby they know that they are part of a bigger undertaking that involves many other parties in and outside their domain, and also that their software can be utilised at different stages of the research cycle by different people. They may be asked to contribute to the ethical and regulatory evaluation of a project to ensure integrity of the research performed therein. Like other researchers, RSEs are open to discussions and arguments beyond their own expertise and appreciate the underlying principles of good research, including publications, reviews and reproducibility. 4.2.3 Software re-use ( SRU) The re-use of existing assets such as libraries and pieces of code to improve efficiency and quality belongs to the fundamentals of software construction. 10 To discover software, RSEs rely on domain-specific knowledge and domain repositories, as well as research skills, discovering related software via software citations and metadata. To evaluate whether the artefacts to be re-used suit their needs, RSEs often need to consider the scientific context of their origin. For example, a paper that references the code under consideration might be crucial to validate its fitness for purpose or lack of suitability. Code that incorporates research-domain specific knowledge needs to be understood at a very detailed level and its re-use documented to meet standards of good research practice. Not only the technical compatibility needs to be understood and documented (programming languages, system interoperability), but also the underlying models and computational methods need to fit the purpose; this question often requires wider research skills and deeper understanding of the research domain at hand. 4.2.4 Software publication and citation ( SP) Another part of FAIR software is concerned with publishing new and derived works and making them available for re-use by the research community and the general public, within the boundaries set by their institutional policies. RSEs need to have a basic understanding of common software licence types, including proprietary and open source licences and how “copyleft” and “permissive” open source licences differ. They should also understand compatibility between different licences, and the ramifications for re-using and composing programs. Beyond that, RSEs will need to properly execute the technicalities of software publishing. These include the application of licences and copyright statements, understanding and assigning software authorship, crediting contributors, maintaining FAIR software metadata and publishing software artefacts on respective publication platforms. Finally, RSEs will need to understand the principles of software citation. 82 This concerns both the potential for reuse of their own work, which demands the provision of complete and correct up-to-date citation metadata for their software, as well as their own citation obligations deriving from building on previous work in the form of dependencies. 4.2.5 Using domain repositories/directories ( DOMREP) Almost all research software is developed within a specific scientific domain. Some software may be able to cross boundaries, but the majority will have a home domain, with which it needs to be able to interact. The RSE then needs to be aware of any domain specific repositories that will contain data sets, catalogues, and other domain specific artefacts, in addition to software. The RSE also needs to be aware of how their software can interact with the existing domain-specific data repositories. Finally, they need to be able to assess and use software repositories - domain-specific or generic - for publishing software with the relevant metadata. 4.3 Communication skills RSEs do not work in isolation. They are embedded in a research group or work within a team of RSEs supporting particular research projects. RSEs often need to interact with and facilitate communication among colleagues, clients and contractors with a very broad spectrum of background-knowledge, specialisation, expectations, and experience whilst keeping diversity issues in mind ( Section 3.1.2 ). Communication skills are therefore crucially important. Team skills are also mentioned in common guides for SE such as the software engineering body of knowledge. 10 However, the interpersonal and organisational skills and the capacity for adaption required to work in a research setting warrants a much stronger emphasis on this field of competence. 4.3.1 Working in a team ( TEAM) Being able to work, and effectively communicate in teams is essential for RSEs. For example, RSEs need to be able to explain particular implementation choices made and may even need to defend them. Within a team of RSEs, code reviews improve knowledge transfer and increase team cohesion. The team might change on a project-to-project basis and might be comprised of colleagues with very different backgrounds including, for example, IT staff, domain scientists and technicians working alongside software engineers. The shared values come into play and each RSE needs to ensure that these values are lived by and passed on to others. Senior RSEs may lead a team of RSEs. 4.3.2 Teaching ( TEACH) RSEs have many opportunities to teach. These range from inducting new colleagues to teaching digital skills either through short courses, for example from The Carpentries, 85 or entire lecture series. RSEs may also act as mentors and consultants. Code review also includes aspects of the teaching skill. 4.3.3 Project management ( PM) The RSE should have knowledge of project management processes. At some institutes, project management tools and approaches differ between individual research groups, but it is useful if an RSE understands general structures of a PM scheme, or can bring in new ideas for improvement. Project management in research software engineering poses specific challenges (see USERS ) that might require the capacity to adapt to changing conditions and deviate from common project management methods. Additionally, the RSE should know that SE offers various methods and approaches specifically tailored to management of software projects and products. 4.3.4 Interaction with users and other stakeholders ( USERS) Since research software is often developed as part of the research process itself, its requirements and specifications might change with the progression of research. Stakeholders of research software often change across different research projects or even within the course of one project. Roles in connection with research software are often in flux and diffuse. For example, a single person might be user, developer and project manager at the same time. Often this means it is necessary for an RSE to think “outside their comfort zone”, but at the same time to be able to convey their knowledge and experience to experts of other fields or persons at different hierarchy levels in a way they can understand more easily. These conditions pose specific challenges for requirements analysis, project management, training and support. 4.4 RSE tasks and responsibilities These skills, while already numerous are also generic on purpose. They span a multidimensional space in which the day-to-day tasks and responsibilities of an RSE can be found. We describe here some examples of the competencies applied in combination to the set of current common tasks and challenges for RSEs identified during the deRSE23 Paderborn workshop. The most obvious task of an RSE is to develop software that is used in research. This broad topic requires all the SE skills. Of course, these are the competencies that are the most fluid since they have to adapt to frequent technological advancements. Additionally, proper SE skills often require knowledge of TEAM , and PM . Today, this means effective use of integrated development environments (IDE), static analysis tools, design patterns and documentation (for oneself and others). The RSE needs to be able to formulate and discuss structural and behavioural aspects of software on a more general level than through the code itself and often even before a first line of code is written. A set of tools and diagrams for effective and standardised communication about software on a meta level is provided by the Unified Modelling Languages (UMLs). As a modelling tool, it is directly related to MOD . Additionally, it can be applied in various stages of the SWLC , especially in the early stages, as a first documentation of the planned modular structure to facilitate DOCBB , USERS , PM and TEAM . The RSE needs to be able to choose appropriate algorithms and techniques ( MOD and NEW ). Apart from the technical feasibility, this choice is also informed by the values outlined in Section 3 . For example, the RSE needs to be able to estimate resource usage (processing, memory and storage consumption, e.g. Ref. 60 ). Resource usage has not only a direct financial price tag but also environmental costs via associated energy consumption (see Section 3.1.4 ). Software development also includes testing. This task is a manifestation of the SE competencies of DOCBB and MOD since a model of the software is required in order to write good tests that facilitate understanding and documentation. Today this encompasses the knowledge of testing frameworks as well as continuous integration and continuous delivery (CI/CD) practices. In addition to being tested, software should also provide reproducible outputs. Projects like ReproHack 101 can greatly help in fostering that competency. Apart from testing, there are many code analysis tools to monitor and improve the quality of code. An RSE should be familiar with the tools available for their specific environment and how to include some of them into a CI/CD pipeline. Typically, this includes linters and similar static tools as well as dynamic tools like profilers and code coverage analysis. The development of these tools is very dynamic and environment specific. A good introduction can be found in Ref. 10 and an online resource is Ref. 106 . As these tools help with behavioural and structural analysis and therefore modularisation these tools enable MOD as well as DOCBB . Part of the FAIR principles is to make software findable and reusable. The RSE needs to be able to decide when and why to keep a repository private. This decision requires knowledge in RC , USERS , TEAM , and sometimes SP . Furthermore, knowledge of the practices and contractual regulations of the RSE’s institution is also required. The RSE also needs to understand metadata for research data and research software. There are ongoing efforts on metadata for research software such as CodeMeta 51 and the National Research Data Infrastructure (NFDI, Nationale Forschungsdateninfrastruktur) working group 16 on the subject. These are complemented by the development of new tools and methods for providing and working with software metadata, such as the Citation File Format project 24 and HERMES. 23 Other efforts focus on Software Management Plans (e.g., Refs. 1 , 63 ) which could be helpful for RSEs at early stages (i.e., with not much experience of project management). They give quick hints on what to look for regarding basic management for research software (including information on, e.g., licenses, releases, publication, citation, archiving) together with some ongoing work on corresponding metadata. 35 Metadata can also be used actively during and within a research project, to inform the decision-making processes. 7 Most RSEs will contribute to other projects, some of which will be large. This is a topic that requires competency in SWREPOS , SRU , and SP in order to understand the ramifications of sharing, and in DOCBB , since the contributed code has to be understood by others. Interacting with project members depends on the TEAM skill. Today, this frequently involves the effective use of collaborative platforms like GitHub/GitLab, honouring a project’s code of conduct, and some knowledge of popular open source software licences, e.g. the GNU General Public License (GPL). The TEAM skill will play a major role when an RSE is introduced to an existing project. An existing project will have grown some idiosyncratic habits and processes. Often it will require all the skills and patience of an RSE to steer a project towards best software engineering practices, while not having a leadership position. RSEs are embedded in communities. There are two different aspects to finding these communities: First, we have the aspect of community building for a research project. Since this deals with software that is supposed to be used in research this requires knowledge of RC , USERS , and also NEW , in order to effectively interact with domain scientists. Today, an example is a presence on social media. The other TEAM -related aspect is the embedding of recently-trained RSEs into the Research Software Engineering community, sharing the same set of values and competencies. We envision newcomers to the RSE field becoming part of a strong network of RSEs, tool-related communities, and the classical domain communities, making them more effective at supporting research. These networks are a lifelong manifestation where RSEs work to provide an inclusive environment for their peers and provide opportunities for lifelong learning. An ever-growing list of national associations can be found at Ref. 76 . RSEs are also mentoring colleagues (see also Section 3.1.2 ). This necessitates giving good advice that fits to a project’s stage in its life cycle, thereby requiring knowledge of ( SWLC ), and its context in its research domain and thus ( RC ). Research software can often start out as a tool to answer a personal research question, becoming more important when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key processes that deal with critical questions such as weather forecasting or medical diagnosis. A classification of software is commonly used to formalise the process of giving good advice 77 , 94 where research software can move from one class to another during its life cycle. 77 Classifies applications based on their scope and criticality and provides SE recommendations. The RSE needs to be able to identify the application class they are dealing with and apply the respective RSE practices. Often RSEs, especially in RSE groups, will develop applications and services with different variants for different research purposes and groups. Additionally, many research groups develop their own codes for specific research purposes, e.g. simulation codes or specialised data analysis pipelines. A lot of their development of new features is project-based, often through PhD projects. Work can sometimes result in code that diverges from the main project into a separate variant with re-integration planned as a final step. To reduce the chance of variant source code diverging significantly and producing a large integration overhead, PM skills and methods are needed. More specifically, software product line management methods have been developed for this exact problem and purpose. 5. How much do different people need to know? Now that we have the different competencies, we can explore various dimensions of these competencies, depending on their circumstances. A strong beneficiary of specialised RSEs can also be newly formed RSE centres at research institutions. 5.1 Career level At different career levels, differing skills are required. To elaborate on that, we have prepared the following tables with three levels of experience in mind. • Junior RSE: These are people who are in the earlier stages of their RSE career journey, but they should ideally have research experience of their own as well as the skills to contribute reliable and well-structured code to software projects. • Senior RSE: They have gained experience, both concerning their software skills as well as in their research collaborations in potentially many different fields. They can set the standards in a software project. • Principal RSE: Their actual job description varies a lot. These may be RSE team leaders based in a professional services type role, or they may be professors or research group leaders based in a more academic-focused role. They are often the people responsible for bringing in the funding that supports new and sustains existing projects. Generally speaking, they do not need to be actively involved in the day-to-day technical tasks, but they should be able to guide projects from both a technical and a research perspective while providing an inclusive working space. Table 1 , Table 2 , and Table 3 elaborate on the required facets of the competencies in different roles. A story-like example of an individual through the hierarchies can be found in Section 5.4.2 . Table 1. Levels of technical skills expected per RSE career stage. Competency Junior RSE Senior RSE Principal RSE SWLC Should be aware of the software life cycle. Should know where in the life cycle their project is and which decisions are likely to lead to technical debt. Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. DOCBB Should be able to write reusable building blocks. Same as junior, but the quality should set the standard for the project, while following current best practices. Should know the current best practices and point their team members and collaborators to the right resources. DIST Should be able to use package distribution platforms. Same as junior, but should also be familiar with current best practices for building and deploying packages. Should ensure that their project is available via an up-to-date and secure distribution platform. SWREPOS Should seamlessly interact with the repository of their project. Should be well-versed in the intricacies and best practices around working with a repository, and probably interact with repositories of multiple projects. Should promote the use of repositories and be able to convey best practices of sharing and reviewing to junior and senior RSEs. MOD Should have a basic grasp of the part of the software they are responsible for in order to use basic tools such as a debugger. Should understand the characteristics of large parts of the codebase considering a variety of the metrics. Should have a detailed understanding of the software project as well as its aims and potential for impact, in order to effectively steer it. Table 2. Levels of research skills expected per RSE career stage. Competency Junior RSE Senior RSE Principal RSE NEW Should have some curiosity to fit into research teams. Same as junior, but they should proactively propose directions in individual aspects of the project. Should have research insights and a broad view of the research field to steer the project. RC Should be aware of the research life cycle. Should know the position of the project in the research life cycle. Should know what is necessary for the project to fit into its position in the research life cycle. SRU Should be aware of software reusability tools. Should be able to search with software reusability tools. Should be able to effectively search with SRU tools and to evaluate and perform the integration of a library into the project. SP Should be aware of available opportunities to publish software and understand the need to consider issues of intellectual property. Should be able to correctly publish software in simple cases and to identify cases where professional legal advice is needed. Same as senior, plus the ability to take the future publication of software into account when initiating and guiding larger software collaboration projects. DOMREP Should be able to interact with the domain repository. Same as junior RSE. Same as junior, and should know about how it fits into workflows surrounding these domain repositories. Table 3. Levels of communication skills expected per RSE career stage. Competency Junior RSE Senior RSE Principal RSE TEAM Should be able to work in the team in order to effectively fulfil the given tasks. Should be able to learn from code review. Should be able to break down tasks into more easily digestible sub-tasks and review or guide work undertaken by less-experienced team members. Should be able to lead the team and set the respective direction. TEACH Should be able to perform simple peer-to-peer on-boarding tasks. Should be able to explain logical components and the general architecture to other RSEs. Should be able to effectively communicate about all high-level parts of the project. PM Should be aware of the employed PM method. Should be able to use and adapt the employed PM method. Should be able to design and adapt the employed PM method. USERS Should be able to communicate with both users and SEs on the project, on topics of the research and SE. Same as junior RSE, and be able to interpret the feedback. Same as senior, and should also be able to effectively take feedback into account when steering the project. 5.2 Helpful RSE skills for researchers in an academic career In the previous section, we looked at the competency levels needed for RSE specialists. However, many of these competencies are important for domain researchers in academia as well, who do not specialise in RSE but nevertheless contribute to research software. Naturally, the ‘R’ competencies apply, and research in general is increasingly team based. Additionally, many researchers in fields from classical examples like numerical mathematics or theoretical physics to newer disciplines like digital humanities will spend time in their research on writing and developing software. Therefore, RSE focused training, e.g., in a master’s programme, is also beneficial for students in these fields resulting in a broader audience. This also means that students as well as researchers need to be given time to acquire those skills, e.g., to be able to attend training in RSE-relevant topics as part of their regular work or study. This section outlines how the RSE competencies could be reflected at all academic levels. Again, this relates to domain studies and non-RSE positions in academia. It is important to note that this section does not reflect the current state of academic training and research institutions. Instead, it summarises the discussions with and between workshop participants at different levels of academic progression on what they would have liked to learn at an earlier stage or know before starting their current position. While individuals already work at implementing some of these changes and teaching these skills, it has not yet reached a systemic level. The text is organised along the academic progression path (bachelor’s degree, master’s degree, PhD, Postdoc, Principal Investigator (PI)/Professor). Since each level is based on the previous levels, we presume that the skills and competencies at each level also encompass those of the previous levels. Due to the broad need throughout academic specialisations, the described levels serve as a baseline and certain fields will require higher SE skill levels as development is a large part of their actual research. Bachelor’s level Students at the undergraduate level mostly consume science/knowledge. During their studies, they should also learn about the existence of digital tools and structures. Undergraduate students should be aware that RSEs exist and that software has different quality aspects ( DOCBB ). They should be aware of domain specific tools ( DIST , SRU ) and where to find them ( SWREPOS , DOMREP ). At this level, it may be sufficient to consider software as black boxes ( USERS ) although some training in data presentation would be very helpful and a good way to find out about programming ( MOD , NEW ). They should have a basic awareness of software licences, such as legal pitfalls and implications for good scientific practice ( SP ). They will be taught about the research cycle ( RC ) and that researchers often work in groups ( TEAM ). During practicals, they will have an opportunity for peer learning ( TEACH ). Master’s level A student at a master’s level can participate in science and should therefore be able to use “some” digital structures. A master’s student needs to be aware of relevant tools and data sets for their domain, where to find them and how to use them ( DIST , SWREPOS , DOMREP ). They should be able to process and present their data ( MOD ). They need to understand how their research depends on software ( SWLC ). Working on their master’s thesis allows them to understand the research cycle ( RC ), practice project management ( PM ) and collaborate with other members of their research group ( TEAM ). PhD PhD students perform independent research under guidance. They need to know relevant tools and structures. They should know where to find information about tools and where to find help using them ( DOCBB , SWREPOS ). They should be able to use the tools ( DIST ) and identify and report bugs ( MOD ). They need to be aware that the user’s perspective is different from the developer’s perspective in order to be able to write good bug reports ( USERS ). They might produce new software ( MOD , SRU ), in which case they need to understand how to licence their code for publication ( SP ). PhD students need to be curious to be able to conduct their research. In order to be able to explore new tools ( NEW ) they must be able to evaluate research software ( SWLC ). They need to be able to interact with services ( RC ) and domain specific repositories ( DOMREP ). They should be able to supervise a student ( TEACH ). Postdoc Postdocs are independent researchers. Their role is similar to that of a PhD student, with a deepened focus on their research career. However, they are proficient users of all relevant tools, which makes them active contributors to their domain of research. They need to be aware of more advanced topics regarding intellectual property rights, such as patents ( SP ). PI/Professor They are experts in their field and should be able to give proper guidance to their students on which digital tools are currently relevant. They should be aware of the skills of an RSE and when they might need one in their group. They should encourage their students to use relevant tools ( DIST ). They need to be able to judge the suitability of the software ( SWLC ) and follow the interactions between relevant projects ( SWREPOS ). They should be able to advise their students on the legal aspects of software production and distribution ( SP ). They should be able to contribute meaningfully to the steering decisions of the software in their field ( USERS ). They are able to guide students and prepare and deliver a full lecture course ( TEACH ). They need to manage and lead their research group ( PM , TEAM ). 5.3 Project team structures In Table 4 , Table 5 , and Table 6 , we look at individual or team competencies and approaches to them, considering how these differ depending on whether an RSE is working alone on a software project, or whether they are working as part of a team of RSEs. We extend this to consider how things differ when an RSE or a group of RSEs is based locally within a research team or department, or when they are based in a dedicated, centralised RSE team. We also look at organisational aspects in the context of each of the considered competencies, since there are a variety of ways that organisations can contribute to and support them, complementing those proposed by Ref. 54 . Some of them are brought to life in the example career path of Section 5.4.1 . We first summarise the meaning of each of the columns in the tables: • Competency: The code assigned to the competency being considered, as defined in Section 4 , e.g. TEAM . • Individual RSE (Locally-based): A single person working on software within a research project - for example a domain RSE with focus on their own specific research. Often time-constrained, may be self-taught. • Individual RSE (RSE team-based): A single person working on research software - generally a professional RSE assigned to support another team’s software on their own, who however is connected to an RSE team. • Group of RSEs (Locally-based): A group within a research group or team, working together on software to support or undertake a single research goal/project. Similarly to the individual RSE, they are often research-focused with RSE skills, often self-taught. • Group of RSEs (RSE team-based): An RSE team working together on research software projects for a research group. • Organisation-level RSE support: Describes how the defined competencies are recognised and represented at an organisational level and what the organisation can do to support the RSEs in the context of the different team structures. These can be read as policy/action recommendations. These tables take the perspective of the expected skill set of each RSE or team of RSEs, similarly to personas in a user experience analysis. The current situation may differ. Table 4. Levels of software eng. skills expected per team structure. Competency Working as an individual RSE Working with a group of RSEs Organisation-level support Locally-based RSE-Team based Locally-based RSE-Team based DOCBB Focuses on supporting research. May not be very familiar with code quality and structure. Follows basic best practice guides. Puts greater focus on reusability, documentation, and knowledge of best practices, but potentially lacks domain knowledge. Has more opportunities to discuss and share ideas, but team members may be less aware of key practices. Has stronger ingrained focus on team-base PM and development methodologies, resulting in higher quality, more reusable code. Should offer training and other resources in core topics to support individual RSEs. Should have research software guidance/policies that provide advice. DIST Does not emphasise code reusability and sharing/distribution. Puts greater focus on reusability/sharing, but likely not as part of the project aims. May want to develop reusable, shareable outputs for a specific case. Needs clear guidelines. Focuses on quality and best practices. Reusability/packaging driven by project needs and spec. Should provide policies on reusability/sharing. May be driven by requirements/policies, e.g., of institution or funding agency. SWLC Manages the complete life cycle, bus factor equal to 1. The team supports parts of the software life cycle, but with low bus factor. The team infrastructure and tooling supports the life cycle and sustainability. The bus factor may still be low in parts of the code. Need to think about coherent life cycle management across the team - generally a key area of expertise for an RSE team. Should support with training. Organisation may also provide site licences for, e.g., management tools. SWREPOS Uses repositories for code management and demonstrating outputs, e.g., for supporting academic credit, but may be missing skills. As locally-based, but professional RSEs are generally very experienced with use of repositories and their many features. Uses repositories to collaborate inside the team. Can benefit from short courses on effective use. Uses repositories extensively for project management, issue tracking, etc. in addition to code itself. May train others. Should offer enterprise repository set ups, site licences etc. Also provide training for this vital research software development tooling. MOD Needs full awareness of entire codebase to extend/maintain. If project taken on from another developer, there may be challenges in transferring the mental model. As local, but more aware of need for future transition to other RSE(s), likely provides docs, issues, and other support from central services to support this. May only need to know parts of the code. Internal team training ensures ability to build necessary mental model of codebase and to document it via text or tools for sustainability. As local team, but likely more aware of tooling and practices in place within RSE team. Distributing work makes it only necessary for each developer to understand code related to their assigned tasks. Should provide training and retain experience via coordinating and provide support for mentoring/community activities. Establishing RSE departments with specialists for certain aspects of software will improve overall turnaround times. Table 5. Levels of research skills expected per team structure. Competency Working as an individual RSE Working with a group of RSEs Organisation-level support Locally-based RSE-Team based Locally-based RSE-Team based NEW May struggle to learn new methods and skills due to split research focus between research goal and software project. Gets support from the RSE team to explore new methods and skills, make relevant contacts and learn more about the domain. Has increased interest in learning new methods and skills, but still prioritises domain research. As team-based individual Should reach out to relevant local groups to facilitate training and sharing of know-how on new technical processes and tooling. RC Is familiar with the RC in their domain, especially when embedded in a research team. Is familiar with the RC, although they may not have domain knowledge, which a group can provide. Is familiar with the RC and can share knowledge within the team. One or more members of the team are strongly aware of the RC. Should provide extensive infrastructure to manage the RC , supporting researchers/RSEs. SRU Has limited awareness of existing solutions and limited support regarding SRU . Is familiar with software sharing and can discover tools and platforms. As locally-based individual, but being part of a team can help to address this. As team-based individual Should run local environments to host software, catalogue software, and/or provide institution-level access to platforms that support this. SP Has limited knowledge and motivation regarding SP . Applies practices, workflows, and policies established in the RSE team. As locally-based RSE As team-based RSE Should raise awareness about software as a publishable scientific output, provide recommendations and checklists to support software publications, and have legal experts in place to offer advice on complex cases. DOMREP Domain researchers working on software are likely to be more familiar with the domain-specific solutions. RSEs may need guidance from domain researchers around domain-specific repositories if they have a background in a different domain. As locally-based individual As team-based individual Should host domain-specific repositories for areas that the organisation works extensively in, but this is likely to be handled at a research group level. Table 6. Levels of communication skills expected per team structure. Competency Working as an individual RSE Working with a group of RSEs Organisation-level support Locally-based RSE-Team based Locally-based RSE-Team based USERS May have additional skills to safeguard potential future development and maintenance of the software for external users. Resourcing for future maintenance may be a challenge. Has additional skills or can access support to safeguard potential future development and maintenance of the software for external users. Needs to safeguard future development and maintenance of the software for external users, but may not have the skills or resources to support this. Applies best practices to prepare the code for external users, while the team provides infrastructure and/or specialised RSEs for user support. Should have institutions that are able to offer support with outreach and publicising outputs. TEACH May be independently involved in training activities. May be able to support researchers with core technical skills. Shares knowledge and skills within the group (peer support). Supports teaching more widely, either through organised courses or ad hoc activities such as “code clinics”. Should have programs for a diverse range of teaching/training activities, such as an RSE curriculum, as described in Section 5.4.1 . PM Is organised enough to be able to transfer the codebase to future RSEs. Follows the project management approach set by the team, or can suggest such PM approaches. Has additional PM challenges, but may not have awareness of or experience with key PM skills, which can be acquired with low-key courses. Team provides well-structured approaches and tooling to support management of projects. Should offer training to support management of projects. May offer organisation-level tooling. TEAM When not developing code for themselves, they must be able to work effectively with researchers they are potentially developing code for. Must be able to work effectively with their home RSE team, as well as with researchers they are potentially developing code for. Must have strong team skills and knowledge to support team-based software development. Must be able to work and collaborate effectively in an interdisciplinary team, use required tools and processes, infrastructure, etc. Should offer support with team work and promote interdisciplinary interaction. Should facilitate team-building initiatives, also on a social level. In the tables above, we have looked at how different competencies can be related to and handled by researchers and RSEs working in different environments within an organisation and how the organisations themselves can contribute. We recognise that this is a challenging area to gain a detailed view of and that this is still a significant generalisation. We talk about the “Research Software Engineer” as a single entity but as the field expands, we expect to see more roles and job titles emerging around the RSE concept, many of which fit under the wider umbrella of research technology professionals (RTPs). 107 , 108 Examples are different RSE-like computational roles of the EMBL-EBI BioExcel competency framework 109 (also Section 6.3.1 ), as is a range of different roles from King’s Digital Lab at King’s College London. 83 5.4 Designing a generalist RSE framework 5.4.1 An example master’s programme for research software engineering The target audience for such a master’s programme are students holding a bachelor’s degree from a domain science, which we will call “home domain” in the following. There is explicitly no restriction on the candidates’ home domain: it may be from the STEM disciplines, life sciences, humanities or social sciences, and it can also change later in their career. Candidates with a bachelor’s degree in computer science are also explicitly included, although we acknowledge that their master’s programme should include adaptations to make their interaction effective with other domain scientists. In order to give the future RSE the necessary breadth, we expect this to be a four-semester curriculum. The curriculum is formed from a combination of modules, some of which are core modules teaching essential skills that must be completed by all students. Other modules introduce more specialised concepts and skills. During the master’s programme, students should pick an RSE specialisation from the list in this paper and attend these additional modules to deepen their knowledge in that field. Core modules are of course drawn from the three pillars of the RSE and can be categorised accordingly. • Software/Technical skills: ○ Foundational module: Here we have an introduction to programming: Emphasising use cases over programming paradigms, students learn at least two languages: a language that facilitates prototyping and data processing (e.g., Python or R ) and a language for designing complex, performance-critical systems (e.g., C/C++). This exposes them to computers in a hands-on fashion and is the foundation for ( DOCBB , DIST ). ○ Computing environment module: Programming languages are not enough to work in a landscape of many interconnected software components; hence we require something like software craftsmanship, where tools such as the Unix shell, version control systems, build systems, documentation generators, package distribution platforms, and software discovery systems are taught to strengthen skills in ( DIST , DOCBB , SWREPOS , SRU ). ○ Software engineering module: Here we develop foundational software engineering competencies (basic knowledge and skill regarding requirements engineering, software architecture and design, implementation, quality assurance, software evolution), again emphasising and strengthening ( DOCBB , DIST ) on a more abstract level. • Research skills: ○ Optional domain mastery module: Additional minor research courses, but students with a home-domain already have the research part well-covered. Courses here should be allowed to fall in any research field, and those outside of the own home-domain should be especially encouraged. ○ Research tools module: Here we teach tools used to distribute and publish software, as well as introducing students to domain specific data repositories, thereby gaining foundational knowledge in ( SRU , SP , DOMREP ). ○ Meta-research module: Here we teach people how research works. The research life cycle is introduced, as well as the data life cycle and the software life cycle are abstractly introduced. • Communication skills: ○ Project management methods: Here we teach project management methods that are useful in science, such as agile ones ( PM ). ○ Communication skills module: Here we have courses focusing on interdisciplinary communication, interacting across cultures, communication in hierarchies, supporting end users effectively. These are all facets of the ( USERS ) skill. ○ Teaching module: This module covers topics to effectively design courses and teaching material for the various digital tools, thereby strengthening the ( TEACH ) skill. Throughout the programme the values outlined in Section 3 are incorporated into the sessions to raise awareness of the codes of conduct and to put these values into ethical practice (see e.g. Ref. 13 ). Given that RSE work also involves a lot of craftsmanship skills, hands-on practice is an integral part of the curriculum. At least two lab projects are required within the mandatory curriculum. These should be executed as a team and involve a question from a domain science. We recommend covering both the candidate’s home domain as well as a different one. Ideally, projects stem from collaborations with scientists within the institution and RSE students take the role of a consultant. This setup strengthens the ( TEAM , TEACH , USERS ) skill and encourages also the ( MOD ) skill through interaction. To emphasise the exposure to domains outside their bachelor’s degree domain, we recommend that RSEs also support their non-home-domain project with introductory courses from this discipline. This schools their ability to quickly adapt their vocabulary and thinking to other disciplines and is an aspect of ( MOD ). To align with the specialisations listed in this paper, example optional modules include topics on HPC engineering/parallel programming, numerical mathematics/scientific computing, web technologies, data stewardship, AI models/statistics, and community management/training. The programme is finalised with a master’s thesis which should be dual-supervised by an RSE supervisor from an actual project, and a domain supervisor. The thesis should answer a relevant research question from the domain using computational methods, strengthening ( NEW ). Software development is required, and the code is part of the gradable deliverables. The RSE supervisor ensures and grades the software craftsmanship aspects of the project. This setup ensures that we are grading the effectiveness of applying RSE skills in an actual research environment. 5.4.2 An example of a possible career path Setting the stage Meet Kay, Kim’s 2 younger sister who currently studies researchology in a bachelor’s programme in the established domain of researchonomy at University of Orithena (UofO). We will follow Kay’s fictional career to illustrate how education, job-experience and a career in academic institutions could lead to become a successful RSE. In Kay’s world, some of the measures proposed in this paper have already been implemented. Bachelor’s degree Through a program like Software Carpentry 86 or The Missing Semester, 3 Kay learns about using computational tools to support the sophisticated statistical analysis typical for researchology. She uses those tools to create and automate the steps of processing data and producing outcomes for her bachelor’s thesis (generating plots with matplotlib and even CI for automatic building) and takes pride in a fully open and reproducible bachelor’s thesis enabling her to graduate with honours from the faculty of researchonomy. Master’s degree Kay ponders whether to continue with computational researchology, which her bachelor’s supervisor is responsible for, or enrol in a domain-agnostic RSE master’s programme. Researchers in computational researchology need to acquire a large part of the general RSE know-how presented in this paper and specialise in Quantum-Accelerated Bayesian Optimisation methods. However, Kay decides to go for the more generic route of a dedicated RSE programme because she wants to continue in academia, but does not like the idea of becoming stuck with one research topic. She also experienced the immediate satisfaction gained by helping colleagues from her research group with tricky technical problems, which makes her happier than the subdued sense of achievement from having a research paper accepted long after she had written it. For her, coding and sharing knowledge in the form of software is of similar importance to writing a paper focused mostly on the obtained results. The domain-agnostic RSE Master programme consists of a core of RSE topics with various electives for specialisation, some of them domain-specific (e.g., chemistry) or topic-specific (e.g., cloud computing for research). Kay chooses digital archaeology and develops a pipeline for reconstructing 3D models from ground penetrating radar data, to simplify the process for archaeologists (reproducibility, big data, ML). The project management skills that are being taught as part of the core RSE curriculum really help her to not get lost in this project. Apart from working with the researchers in her archaeology group, she has to work with members of the central RSE department to help her with the pipelines. She also has to liaise with the central IT department to organise storage for the large data sets. Towards the end of the programme, she visits her first RSE conference where she sees a lot of notions ( SWLC , RC ) in action that so far have been abstract in her master’s degree. The exposure to the wider RSE community inspires her to invest additional time into her thesis to publish her software project under a licence approved by the Open Source Initiative and to write an accompanying article in the open source journal JOSS. 53 Inspired by the discussion with reviewers of her JOSS paper, and the citation metadata file that JOSS created automatically for her when her paper is published, Kay starts to think more about making her software FAIR. She reads up on the topic in a guide suggested to her, the Turing Way, 91 and creates metadata files that provide the citation metadata and general description for her software. She adds the files to her source code repository, and also adds an automated CI/CD pipeline that updates metadata and creates a new publication record in the Zenodo repository for each new release. Kay has now completed the RSE programme and has reached Junior RSE level. Junior RSE Kay finds a position in the central RSE department at her university with a competitive IT salary. Although the contract is temporary, there is a good chance that it will lead to a permanent position. The university makes an effort to enable that since it is a member of “The Technician Commitment”, 108 an initiative to ensure recognition and career development of technicians, who face similar challenges to RSEs. Kay completes the Software Carpentry Instructor training and teaches basic research computing, while advising fellow students of her department on better programming ( DOCBB and MOD skill). She also runs a seminar in the RSE Master’s programme. She publishes a condensed version of that in JOSE. 52 During her teaching duties, she becomes aware of a new project in her department that requires a community manager RSE, and she gladly signs up to focus more on her communication skills. After three years, she takes an exciting opportunity to work in another university. Senior RSE The new position involves taking responsibility for the RSE related aspects of a large inter-organisational project. With her new responsibilities comes a shift in the importance of various aspects of her work. Having this position in an inter-organisational project places far more emphasis on communication and organisation skills. She is spending time teaching people ( TEACH skill) to onboard them into the project. There is a lot of interaction with different stakeholders in the project like funders and user groups ( USERS skill). To oversee the project, she uses an amalgamation of both agile and traditional project-management concepts and methods which she acquires on-the-job ( PM skills). Her work so far has already been heavy on ( TEAM ) skills, but now also the leadership aspect comes into play. RSE-focused principal investigator The job experience as a leading RSE for a large project was the last requirement necessary to be awarded the title of a “Certified Research Software Professional” (CRSP) from an institutionalised centre of RSE education. The certificate confirms her track record of valuable software contributions and of teaching and mentoring people, as well as her capability to enable, foster and contribute to high-quality research in a leading position. It is recognised by various funding agencies, such as the DFG, and hence enables RSEs to act as a PI for RSE-focused grant applications. It is also recognised by many prestigious universities and opens many career options that are also typical for PhDs. Kay can now write her own grant proposals to effectively fund work of moving research software projects from prototypes to infrastructure. 6. RSE specialisations What we have defined above is intended to be a set of skills that an RSE irrespective of domain, position, and experience should know about. There is a large variety of RSEs. They specialise in different areas, some of which we want to present below. Many of the specialisations may overlap, so the same RSE might for example work on data management and open science. We categorise them into those that can be viewed as a specialisation within RSE-specific topics, while other RSEs might expand their skill set and profession to areas that are not typical for an RSE. 6.1 Specialisations within the core RSE competencies Open science RSE Open science and FAIRness of data and software are increasingly important topics in research, as exemplified by the demand of an increasing amount of research funding agencies requiring openness. Hence, an open science RSE is required to have a deeper knowledge of ( RC ) and how to distribute software publicly ( SRU , SP ). Open Science RSEs can help researchers navigate the technical questions that come up when practising Open Science, such as “How do I make my code presentable?”, “How do I make my code citable?”, “What do I need to do to make my software FAIR?”, or “How do I sustainably work with an (international) team on a large code base?”. Like the Data-focused RSE, they have a deep understanding of research data management (RDM) topics. Project/community manager RSEs When research software projects become larger, they need someone who manages processes and people. In practice, this concerns change management for code and documentation and community work to safeguard usability and adaptability, but also handling project governance and scalable decision-making processes. This gap can be filled by people who invest in the ( PM ), ( USERS ), and ( TEAM ) skills, as exemplified in Section 5.4.2 . Building a community around a research project is an important building block for sustainable software, 80 so these RSEs play an important role, even if they do not necessarily touch much of the code themselves. Teaching RSEs RSEs interested in developing their ( TEACH ) skill can focus on teaching the next generation of researchers and/or RSEs and will play a vital role in improving the quality of research software. They need to have a good understanding of all RSE competencies relevant to their domain and additionally should have teaching experience and training in didactics and pedagogy. User interface/user experience designers for research software Scientific software is a complex product that often needs to be refined in order to be usable even by other scientists. To facilitate this, there are people required that specialise in the ( DOCBB ) and probably the ( DIST ) competency with a focus on making end-user facing software really reusable and hence FAIR. This task is supported by strong ( MOD ) skills to reason about the behaviour of potential users of the software. 6.2 Specialisations outside the core RSE competencies ${DOMAIN}-RSE While software is the common focus of all RSEs, there will be RSEs that have additionally specialised in the intricacies of one particular research domain, such as medical RSEs, digital humanities RSEs, or physics RSEs. This can often serve as a base domain for RSE specialisation as in Section 5.4.1 . Data-focused RSE Data-focused RSEs work at the flourishing intersection between data science and RSE. They are additionally skilled in cleaning data and/or running data analyses and can help researchers in setting up their analysis pipeline and/or RDM solutions. When the field requires research on sensitive data or information, e.g., patient information in medicine, this RSE should have knowledge about secure transfer methods and/or ways to anonymise the data. As part of RDM, this RSE profile is able to support all stages of the research data life cycle, 70 with synchronous data management processes. Those processes implement established best practices for planning and documenting of data acquisition in a data management plan (DMP), as well as for management, storage, and preservation of data, and publication and sharing of data in repositories according to the FAIR principles. 98 Research infrastructure RSE This RSE has a special interest in SysOps and system administration and sets up IT infrastructures for and with researchers. Therefore, this specialisation on the one hand requires a deep knowledge of physical computer and network hardware and on the other hand knowledge about setup and configuration of particular server software, e.g., setup of virtual machines on hypervisors or the planning and setup of compute server clusters for special purposes, e.g., ML. As an interface between the researchers and the infrastructure, they take care of user management, access permissions, and configuration of required services. HPC-RSE RSEs with a focus on HPC have specialist knowledge about programming models that can be used to efficiently undertake large-scale computations on parallel computing clusters. They may have knowledge of (automatic) code optimisation tools and methods and will understand how to write code that is optimised for different types of computing platforms, leveraging various efficiency related features of the target hardware. They are familiar with HPC-specific package managers and can build dependencies from sources. They also understand the process of interacting with job scheduling systems that are often used on HPC clusters to manage the queuing and running of computational tasks. HPC-focused RSEs may be involved with managing HPC infrastructure at the hardware or software level (or both) and understand how to calculate the environmental impact of large-scale computations. Their knowledge of how to run HPC jobs and write successful HPC access proposals can be vitally important to researchers wanting to make use of HPC infrastructure. ML-RSE The development of research software based on ML requires additional specialised theoretical background and experienced handling of appropriate software in order to produce meaningful results. This involves knowledge about data analysis and feature engineering, metrics that are involved in ML, ML algorithm selection and cross validation, and knowledge in mathematical optimisation methods and statistics. Here, we use ML in a broad sense of machine-based learning including deep learning, reinforcement learning, neuro-symbolic learning and similar. ML-RSEs analyse and check the suitability of an algorithm. They check if it fulfils the needs of a certain task and they play a central role in deciding on and selecting ML libraries for a given task. The increasing usage of ML in numerous scientific areas with social impact involves an emphasised awareness and consideration of possible influences and biases. At the intersection of data science 32 and data-focused RSEs, the complex way of solving problems utilising ML calls for this separate specialisation. Legacy RSEs Research software may have evolved over generations of researchers without change management or governance processes, while software “ecosystems” (e.g., programming languages, frameworks, operating systems) constantly evolve. This may lead to the emergence of legacy code that is still actively used. To safeguard continued usability and adoption, these RSEs have experience in working with code written in language standards and on software stacks considered deprecated by their communities. Adaption of existing, large-scale codebases to evolving dependencies ( DIST ) or changing hardware (HPC; see the HPC-RSE specialisation) may require mastery in refactoring techniques and in the usage of specialised code transformation tools. Web-development RSE This RSE is skilled in the development of web applications and/or mobile apps. They have expertise in one or more of frontend development, backend development and the design or implementation of APIs, for example to support research data portals or big research projects. Since a lot of web services for research may be accessible to a large audience or even to the public, this RSE is also familiar with aspects relating to cybersecurity, usability and accessibility. Not only do they need to balance these concerns while adhering to their values from Section 3 , but they also need to efficiently communicate the decisions made to stakeholders. Legal-RSE RSEs are often the go-to person for questions about software licensing, in particular when mixing software components that use different licences. But with the rising requirements from legislation, we foresee the need for RSEs that still have a background in RSE but extend it with a knowledge of legal processes that cover corner cases and go beyond applying Best Practice guides. These requirements may arise in the area of publication of research software, as this also requires knowledge about particular laws or regulatory frameworks concerning data protection, like the General Data Protection Regulation (GDPR) within the European Union (EU). 87 Another area are legal aspects of cybersecurity and export control in science and research (see Ref. 110 for Germany). Legal-RSEs focus on facilitating the achievement of technically feasible solutions, while adhering to regulatory mandates. They are able to communicate and collaborate effectively with lawyers. 6.3 Existing frameworks for specialised RSE roles 6.3.1 Bioinformatics skills and certification Bioinformatics is another field that actively works on developing skill trees. The Bioinformatics Core Competencies, 66 , 95 , 96 the BioExcel competency framework, 64 the PerMedCoE competency framework, 61 the Research Data Management and Data Stewardship competence framework 22 and the ELIXIR Data Stewardship Competency Framework for Life Sciences 79 are examples of grassroots efforts aiming at defining the set of skills of various bioinformatics specialities, one of them as a taxonomy. 66 These frameworks eventually converged into the EMBL-EBI Competency Hub, 25 , 62 where typical RSE and bioinformatician profiles at different levels of seniority can be queried (e.g., Junior RSE, Senior Computational Chemist) and compared against one another (e.g., Junior vs. Senior RSE). Competencies can be divided into more fine-grained building blocks: knowledge, skills and abilities (KSAs). They can be organised in a taxonomy, and are also transferable, i.e. a KSA can be a prerequisite to multiple competencies. The Mastery Rubric for Bioinformatics 92 and the ELIXIR Data Stewardship Competency Framework for Life Sciences 79 are examples of KSA frameworks for bioinformatics curricula. The Curriculum Task Force of the International Society for Computational Biology (ISCB) curates a database of degrees and certificates in bioinformatics. 49 , 66 The database includes bachelor’s and master’s degree programs and specialisations, PhD programs, and certificates from graduate schools. BioExcel has research competencies that combine some of our research competencies and some notions from the communication skills. Their computing competencies roughly map to our software skills. Here, we find competencies such as “package and distribute software”, which maps to our ( DIST ) competencies, and “comply with licensing policy”, which would in our framework be part of ( SP ) in the research competencies. In addition, they have a dedicated parallel computing competency section, thereby shifting the emphasis of the knowledge of their computational tools towards the HPC-RSE specialisation in our framework. Career profiles, such as the computational chemist, bring additional domain specific knowledge; we would classify those as a mixture of ${DOMAIN}-RSE and HPC-RSE. It is noteworthy, however, that the BioExcel framework puts very little emphasis on communication skills, which are often involved in RSE-related tasks. 6.3.2 HPC skills and certification As an area that generally requires a range of advanced skills, HPC is one field where there is ongoing work to identify relevant sets of skills for HPC practitioners and potential paths to develop these skills. The HPC Certification Forum 89 has developed a competence standard for HPC that defines a range of skills and how they are related in the context of a skill tree. 55 , 56 This competence standard is currently being built upon by the CASTIEL 2 29 project in collaboration with initiatives funded by the European High-Performance Computing Joint Undertaking (EuroHPC JU) to create a framework for HPC certification. 39 While this framework focuses mostly on skills specific to HPC, there are a couple of similarities to the framework proposed in this paper. The “SD: Software Development” skill set is very similar to the SE skills discussed in Section 4 , describing a wide range of such skills. This skill set contains Programming Best Practices (SD2), Software Configuration Management (SD3), Software Quality (SD5), Software Design and Software Architecture (SD6), and explicit mention of documentation (SD7, see our DOCBB ). Besides the Software Concepts for HPC (SD1), which mainly concerns HPC-focused RSEs, most of the skills contained in the SD2-SD7 categories apply to all RSEs. A significant difference compared to the framework proposed in this paper is the absence of skills related to research or communication. Noteworthy is already now the level of detail in their skill tree which is more similar to Section 5.4.1 . Also looking at pathways and how different skills are related, the UNIVERSE-HPC project, 93 funded under the UK’s ExCALIBUR research programme, 30 is looking to understand and develop training pathways to support the development of specialist skills in the HPC and exascale domains. The project is gathering open source training materials to develop curricula that support the training pathways that are underpinned by high-quality training materials. 7. Future work This list and description of competencies is a first step to finding common ground around which to structure curricula, institutions, and teachers in this framework. Applications of these competencies in an individual’s career can be found in Section 5.4.1 . Opportunities for sustainable funding is a concern that is often 12 , 15 , 36 , 68 raised by RSEs. An omission that we found and that we would like to highlight in order to spark a community discussion is that RSEs that choose explicitly a science-supporting role outside of research will not be eligible for funding under the statutes of many funding organisations that require at least a PhD. To alleviate this and to give RSEs in leadership positions a means to become eligible for funding themselves, since completion of scientific training is often a requirement, 34 we see two possible parts of a solution. One is to allow for doctorates primarily based on software contributions to the scientific community. Secondly, we propose the introduction of new, standardised certificates like those of Section 5.4.2 , and to officially accept them as PhD-equivalent concerning eligibility to be a PI. Beyond this discussion, a diverse set of publications on the topic of RSE teaching is already in the making. Within this set, we will work next on how to institutionalise education. In that publication, we will detail how we organise our institutions and what qualifications our teachers need to have in order to effectively communicate our values. We will put forward ideas on how to build up bachelor’s and master’s programmes, of which a glimpse can already be found in Section 5.4.1 . We will show how we intend to provide the necessary continuous education for RSEs after graduation, and we will connect that with the integration of RSEs into a mesh of community networks aimed at supporting research, while providing them with an inclusive social network that further facilitates lifelong learning. That publication will again intentionally be free of regional specifics, to also serve as a blueprint that other national RSE societies can build upon. Online resources for courses are another important building block. This is the general intention of the learn-and-teach project. 90 Surveying and curating of existing resources is not carried out as a traditional publication, but it is made available as a continuously-evolving online resource at. 90 And finally, we plan to formulate a call to action, building on the previously mentioned publication on the necessary institutions, that spells out everything that is required to best support the continuous need for young RSEs to support digital science specifically in Germany. 8. Conclusion This paper started from a community workshop at deRSE23 in Paderborn where people working in RSE related fields got together to figure out structures and ideas for educating newcomers to this field. One outcome of this diverse gathering is that RSEs from differing fields gather around similar core concepts, At the same time they share a vision of how to renew scientific research practice making extensive use of digital tools. In this publication, we have tried to formalise these concepts. We have formulated a set of values that guide our actions in society, manifestly making RSEs part of the scientific community that shares the ideals of good scientific practice. At the same time, being close to software engineers, we cherish that we have to take responsibility for our tools. We listed core competencies that have been intentionally formulated abstractly without referencing any particular information-processing device. As expected, we have drawn equally upon notions from SE and other research fields, but found that we likewise require teamwork capabilities. We detailed these competencies in various dimensions and found that a different amount is required in different positions and scientific domains. Using this, we proposed recommendations for organisations to foster the development of these competencies. The gathered values and competencies form a common denominator that unifies RSEs and enables them to identify with this domain, in the knowledge that it is already or will soon become critically important for many areas of science. These competencies at the intersection of research and SE, coupled with a firm belief in team processes, make RSEs sought after on the job market and their values make them responsible members of a digital society. The result is a qualification profile which is highly attractive for young people. At an institutional level, research performing organisations have a growing interest in fostering RSE training to support the use of FAIR data and FAIR software in the academic world, a direction determined by new incentives created by scientific journals and librarians. How we update existing institutions and set up new ones that provide this education will be the topic of a follow-up paper. Contribution details Heidi Seibold came up with the original idea for the deRSE23 workshop in Paderborn. Heidi Seibold, Jeremy Cohen, Florian Goth, Renato Alves, Jan Philipp Thiele, and Samantha Wittke organised the deRSE23 workshop. We thank all the participants of this community workshop! Toby Hodges conceptualised and organised the un-deRSE23 workshop together with Jan Philipp Thiele and Florian Goth. We also thank all the participants of this follow-up community workshop! Jeremy Cohen, Gerasimos Chourdakis, Magnus Hagdorn, Jean-Noël Grad, Jan Philipp Thiele, and Matthias Braun organised the deRSE24 workshop in Würzburg. We are also grateful to the participants of this third community workshop! Heidi Seibold, Jeremy Cohen, Florian Goth, Renato Alves, Jan Philipp Thiele, Jan Linxweiler, Jean-Noël Grad, and Samantha Wittke contributed the initial draft. Florian Goth supervised the project and did the project administration. Jean-Noël Grad designed and implemented the software tooling for the collaborative writing of this manuscript on GitHub. Everybody contributed to the final review and editing. The CRediT system 11 is far too generic to adequately describe the contributions of everybody in various workshops, spread over a two year period. While everybody contributed to the discussion formulating and refining the ideas, and to collaboratively writing and/or reviewing and editing the entirety of the script, some parts merit special mention. Renato Alves quickly jumped in to host the first deRSE23 workshop to take over from a sick organiser. Matthias Braun contributed early versions of the specialisations and also contributed to the survey. Leyla Jael Castro contributed to the initial draft of the example career path, and provided helpful insights in discussions on metadata. Gerasimos Chourdakis’ contributions to the paper are numerous (extensively editing large parts of the initial draft), but he especially wrote first drafts for clarifying the relationship of the RSE competencies to the SE competencies. He also designed the “Learning and teaching RSE” website. 90 Simon Christ helped with typesetting and contributed the competencies’ symbols and the spell-checker script. Jeremy Cohen drafted the initial introduction and contributed the tables for RSEs in centralised RSE departments. Stephan Druskat contributed parts on proper software citation and publication and sharpened various RSE specialisations. Fredo Erxleben contributed to early discussions of the paper and added the contributions by the Helmholtz Association. Jean-Noël Grad contributed initial drafts for the ELIXIR framework and the section on the work of the HPC certification forum as well as numerous other contributions to the BibTeX infrastructure and the GitHub actions. Magnus Hagdorn drafted and supervised the ethics and values section for an RSE and made sure that these values are reflected in the competencies of RSEs. Toby Hodges contributed parts on the Carpentries, and helped steer the curriculum discussion. Guido Juckeland contributed experiences from his first RSE course for students. Dominic Kempf drafted the first version of the example curriculum. Anna-Lena Lamprecht helped with proper wording, especially with awareness about established SE terminology, that was misused earlier. Jan Linxweiler drafted various RSE specialisations and made sure that clean coding techniques got their due recognition. Frank Löffler rewrote numerous parts to be actually legible, and helped with preparation for the final steps of a de-RSE position paper. Michele Martone wrote the first draft of the environmental sustainability section. Moritz Schwarzmeier drafted the categorisation of the specialisations. Heidi Seibold contributed the idea and started everything. Jan Philipp Thiele drafted initial parts of the technical pillar of the RSE competencies, and represented the project on numerous discussions. Harald von Waldow contributed to initial drafts of the Masters program and contributed his knowledge to the explainability of computer simulations. Samantha Wittke contributed the parts on CodeRefinery and how to reach out to new RSEs. Florian Goth has the pleasure of being grateful to all collaborators in this project for contributing their time and knowledge into this project! Ethics and consent Ethical approval and consent were not required. Glossary bus factor vulnerability of a project to losing key and irreplaceable team members - a bus factor of 1 means that a single such team member vanishing would already stall the project’s advancement. C general-purpose compiled programming language. C++ general-purpose compiled programming language. design pattern general and reusable solution to solve a SE problem (often a best practice, or a “recipe”). Forge A platform that integrates software repositories and other communication or project management tools. GitHub online software repository hosting and collaboration platform. GitLab online software repository hosting and collaboration platform. Python general-purpose scripting language. R general-purpose scripting language. software publication the practice of long-term archiving software artifacts with software metadata under a permanent identifier. static analysis automated procedure to detect software bugs in source code without executing the code. SysOp system administrator in charge of a computing infrastructure. Skill codes DIST Building distributable software. Section 4.1.4 DOCBB Creating documented code building blocks. Section 4.1.3 DOMREP Using domain repositories/directories. Section 4.2.5 MOD Software behaviour awareness and analysis. Section 4.1.6 NEW Conducting and leading research. Section 4.2.1 PM Project management. Section 4.3.3 RC Understanding the research cycle. Section 4.2.2 SP Software publication and citation. Section 4.2.4 SRU Software re-use. Section 4.2.3 SWLC Adapting to the software life cycle. Section 4.1.2 SWREPOS Use software repositories. Section 4.1.5 TEACH Teaching. Section 4.3.2 TEAM Working in a team. Section 4.3.1 USERS Interaction with users and other stakeholders. Section 4.3.4 Acronyms CD continuous delivery. CI continuous integration. CI/CD continuous integration and continuous delivery. DFG German Research Foundation (Deutsche Forschungsgemeinschaft). DMP data management plan. EMBL-EBI European Molecular Biology Laboratory - European Bioinformatics Institute. ENCCS EuroCC National Competence Center Sweden. EU European Union. EuroHPC JU European High-Performance Computing Joint Undertaking. FAIR Findability, Accessibility, Interoperability and Reusability. GDPR General Data Protection Regulation. GPL GNU General Public License. GREENER Governance, Responsibility, Estimation, Energy and embodied impacts, New collaborations, Education and Research. HIFIS Helmholtz Federated IT Services. HPC High-Performance Computing. IDE integrated development environment. ISCB International Society for Computational Biology. IT information technology. LLM large language model. MIT Massachusetts Institute of Technology. ML machine learning. NFDI National Research Data Infrastructure (Nationale Forschungsdateninfrastruktur). PI Principal Investigator. PRACE Partnership for Advanced Computing in Europe. RDM research data management. SE software engineering. STEM science, technology, engineering and mathematics. TDD test-driven development. UK United Kingdom. UML Unified Modelling Language. UNESCO United Nations Educational, Scientific and Cultural Organization. UNIVERSE-HPC Understanding and Nurturing an Integrated Vision for Education in RSE and HPC. Data availability statement No data associated with this article. Acknowledgements We appreciate the comments and suggestions from Yves Vincent Grossmann, Wilhelm Hasselbring, and Bernhard Rumpe. References 1. Alves R, Bampalikis D, Castro LJ, et al. : ELIXIR Software Management Plan for Life Sciences.2021. Publisher Full Text 2. Anzt H, Bach F, Druskat S, et al. : An environment for sustainable research software in Germany and beyond: current state, open challenges, and call for action [version 2; peer review: 2 approved]. F1000Res. 2021; 9 : 295. PubMed Abstract | Publisher Full Text | Free Full Text Reference Source 3. Athalye A, Gjengset J, Ortiz JJG: The Missing Semester of Your CS Education. MIT, Computer Science & Artificial Intelligence Laboratory; Retrieved August 11, 2023. Reference Source 4. Barker M, Breitmoser E, Broadbent P, et al. : Software and skills for research computing in the UK. Software Sustainability Institute; 2023. Publisher Full Text 5. Barker M, Chue Hong NP, Katz DS, et al. : Introducing the FAIR Principles for research software. Sci Data. 2022; 9 (1): 622. PubMed Abstract | Publisher Full Text | Free Full Text 6. Better Scientific Software: Better Scientific Software (BSSw). Retrieved March 31, 2025. Reference Source 7. Bird C, Coles S, Garrelfs I, et al. : Using Metadata Actively. Int. J. Digit. Curation. 2016; 11 (1): 76–85. Publisher Full Text 8. Blech C, Dreyer N, Friebel M, et al. : SURESOFT: Towards Sustainable Research Software. Technische Universität Braunschweig; 2022. Publisher Full Text 9. Bokulich A, Parker W: Data models, representation and adequacy-for-purpose. Eur. J. Philos. Sci. 2021; 11 (1): 31. PubMed Abstract | Publisher Full Text | Free Full Text 10. Bourque P, Fairley RE; IEEE Computer Society: Guide to the Software Engineering Body of Knowledge (SWEBOK(R)): Version 3.0. 3rd ed.Washington, DC, USA: IEEE Computer Society Press; 2014; 346. ISBN: 978-0-7695-5166-1. 11. Brand A, Allen L, Altman M, et al. : Beyond authorship: attribution, contribution, collaboration, and credit. Learned Publishing. 2015; 28 (2): 151–155. Publisher Full Text 12. Brett A, Croucher M, Haines R, et al. : Research Software Engineers: State of the Nation Report 2017. Engineering and Physical Sciences Research Council, United Kingdom. 2017 Publisher Full Text 13. Brown N, Xie B, Sarder E, et al. : Teaching Ethics in Computing: A Systematic Literature Review of ACM Computer Science Education Publications. ACM Trans. Comput. Educ. 2024; 24 : 1–36. Publisher Full Text 14. Carver JC, Cosden IA: INnovative Training Enabled by a Research Software Engineering Community of Trainers (INTERSECT). 2020. Publisher Full Text 15. Carver JC, Cosden IA, Hill C, et al. : Sustaining Research Software via Research Software Engineers and Professional Associations.In Proceedings of the 2021 IEEE/ACM International Workshop on Body of Knowledge for Software Sustainability (BoKSS). IEEE: Los Alamitos, California, USA; 2021. Publisher Full Text 16. Castro LJ, et al. : “Research Software Metadata” - Working Group Charter (NFDI section-metadata).2023-10. (Visited on 2023-11-05). Publisher Full Text 17. Hong NC: Minimal information for reusable scientific software. 2 nd Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE2) (New Orleans, Louisiana, USA, 2014-11-16). figshare. 2014-07. Publisher Full Text 18. CodeRefinery: CodeRefinery. Retrieved June 16, 2023. Reference Source 19. Consoli L: The intertwining of ethics and methodology in science and engineering: a virtue-ethical approach. Interdiscip. Sci. Rev. 2008; 33 (3): 234–243. Publisher Full Text 20. Council of Europe: Convention for the Protection of Human Rights and Fundamental Freedoms as amended by Protocol No. 15. European Treaty Series No. 005. Council of Europe; 2021-08. Reference Source 21. Deekshitha, Bakhshi R, Maassen J, et al. : RSMM: A Framework to Assess Maturity of Research Software Project. arXiv. 2024-06. arXiv: 2406.01788 [cs.SE]. Publisher Full Text 22. Demchenko Y, Stoy L: Research Data Management and Data Stewardship Competences in University Curriculum. Proceedings of the 2001 IEEE Global Engineering Education Conference (EDUCON) (Vienna, Austria, 2021-04-21/2021-04-23). Klinger T, Kollmitzer C, Pester A, editors. Red Hook, New York, USA: IEEE; 2021-04. Publisher Full Text 23. Druskat S, Bertuch O, Juckeland G, et al. : Software Publications with Rich Metadata: State of the Art, Automated Workflows and HERMES Concept. arXiv. 2022-01. Publisher Full Text 24. Druskat S, Spaaks JH, Hong NC, et al. : Citation File Format. Zenodo. 2021-08. Publisher Full Text 25. EMBL-EBI: Competency Hub. Retrieved July 20, 2023. Reference Source 26. EuroCC: EuroCC Training. Retrieved June 16, 2023. Reference Source 27. EuroCC National Competence Center Sweden: ENCCS Lessons. Retrieved July 25, 2024. Reference Source 28. EuroCC National Competence Centre Sweden: ENCCS - Supercomputer access and training for your business/organisation. Retrieved October 27, 2023. Reference Source 29. EuroHPC Joint Undertaking: EuroCC 2 and CASTIEL 2: Promoting HPC to boost digital skills, jobs and industrial competitiveness in Europe. Retrieved June 16, 2023. Reference Source 30. ExCALIBUR: Exascale Computing ALgorithms & Infrastructures Benefiting UK Research. Retrieved June 16, 2023. Reference Source 31. Frigg R, Reiss J: The philosophy of simulation: hot new issues or same old stew? Synthese. 2009-08-01; 169 (3): 593–613. Publisher Full Text 32. Stuart Geiger R, Gonzalez-Beltran A, Haines R, et al. : So you want to start a data science institute? Achieving sustainability. Software Sustainability Institute; Retrieved August 4, 2023. Reference Source 33. German Research Foundation: Guidelines for Safeguarding Good Research Practice. Deutsche Forschungsgemeinschaft. 2022. Publisher Full Text 34. German Research Foundation: Merkblatt Programm Sachbeihilfe.2023-06. Retrieved November 14, 2023. Reference Source 35. Giraldo O, Geist L, Quiñones N, et al. : A metadata schema for machine-actionable Software Management Plans. 3rd International Workshop on Metadata and Research (objects) Management for Linked Open Science (DaMaLOS 2023) (Hersonissos, Greece, 2023-05-29). PUBLISSO-FRL, 2023-06. Publisher Full Text 36. Goble C: Better Software, Better Research. IEEE Internet Comput. 2014; 18 (5): 4–8. Publisher Full Text 37. Goth F, Alves R, Braun M, et al. : Material from the deRSE23 workshop. Teach. Learn. Res. Softw. Eng. 2025. Publisher Full Text 38. Gotterbarn D, Miller K, Rogerson S: Software Engineering Code of Ethics is Approved. Commun. ACM. 1999-10; 42 (10): 102–107. Publisher Full Text 39. Governing Board of the EuroHPC Joint Undertaking: Amending the Joint Undertaking’s Work Programme and Budget for the year 2023 (Work Programme and Budget Amendment no. 1). EuroHPC JU Decision No 03/2023. EuroHPC Joint Undertaking; 2023-03. Reference Source 40. Gruenpeter M, Katz DS, Lamprecht A-L, et al. : Defining Research Software: a controversial discussion. Zenodo. 2021. Publisher Full Text 41. Helmholtz: Helmholtz Federated IT Services (HIFIS). Retrieved June 16, 2023. Reference Source 42. Henriksen-Bulmer J, Jeary S: Re-identification attacks—A systematic literature review. Int. J. Inf. Manag. 2016; 36 (6, Part B): 1184–1192. Publisher Full Text 43. Hettrick S: A not-so-brief history of Research Software Engineers. Software Susitainability Institute; 2016-08. Retrieved June 16, 2023. Reference Source 44. Hettrick S, Bast R, Crouch S, et al. : International RSE Survey 2022. Version v0.9.3.2022-08. Publisher Full Text 45. Hirvelä P, Heikkilä S: Right to Respect for Private and Family Life, Home and Correspondence. A Practical Guide to the Article 8 Case-Law of the European Court of Human Rights. Intersentia; 2022. Publisher Full Text 46. Humphreys P: Extending Ourselves: Computational Science, Empiricism, and Scientific Method. Oxford University Press; 2004. Publisher Full Text 47. IDEAS: PRODUCTIVITY. IDEAS PRODUCTIVITY. Retrieved March 31, 2025. Reference Source 48. International Energy Agency (IEA): Electricity 2024. Report. Paris, France: IEA; 2024-01. Reference Source 49. International Society for Computational Biology: Degree & Certificate Programs in Bioinformatics. Retrieved July 20, 2023. Reference Source 50. INTERSECT: Existing Research Software Engineering Training Material.2023. Retrieved July 12, 2023. Reference Source 51. Matthew B, Jones CB, Mayes AC, et al. : CodeMeta: An Exchange Schema for Software Metadata.2017. Publisher Full Text 52. JOSE: The Journal of Open Source Education. Retrieved October 18, 2023. Reference Source 53. JOSS: The Journal of Open Source Software. Retrieved October 18, 2023. Reference Source 54. Katerbow M, Feulner G: Recommendations on the Development, Use and Provision of Research Software. Zenodo. 2018. Publisher Full Text 55. Kunkel J, Filinger W, Meesters C, et al. : The HPC Certification Forum: Toward a Globally Acknowledged HPC Certification. Comput. Sci. Eng. 2020; 22 (4): 110–114. Publisher Full Text 56. Kunkel JM, Himstedt K, Filinger W, et al. : One Year HPC Certification Forum in Retrospective. J. Comput. Sci. Educ. 2020-01; 11 (1): 29–35. Publisher Full Text 57. Lamprecht A-L: Thema im Fokus: Forschungssoftware und Research Software Engineering (RSE). GI-Radar. 2024. Reference Source 58. Landwehr C, et al. : Software Systems Engineering programmes a capability approach. J. Syst. Softw. 2017; 125 : 354–364. Publisher Full Text 59. Lannelongue L, Aronson H-EG, Bateman A, et al. : GREENER principles for environmentally sustainable computational science Nat. Comput. Sci. 2023; 3 (6): 514–521. PubMed Abstract | Publisher Full Text 60. Lannelongue L, Grealey J, Inouye M: Green Algorithms: Quantifying the Carbon Footprint of Computation. Adv. Sci. 2021; 8 (12): 2100707. PubMed Abstract | Publisher Full Text | Free Full Text 61. Lloret-Llinares M, Calbó J, Carbonell-Caballero J, et al. : The PerMedCoE competency framework to guide the training programme. 29 th Conference on Intelligent Systems for Molecular Biology and the 20 th European Conference on Computational Biology (Virtual Event, 2021-07-25/2021-07-30). 2021. Reference Source 62. Lloret-Llinares M, Lopez DT: The EMBL-EBI Competency Hub, a tool to support training and professional development. FEBS Network. 2022-10. Retrieved July 20, 2023. Reference Source 63. Martinez-Ortiz C, Lavanchy PM, Sesink L, et al. : Practical guide to Software Management Plans. Zenodo. 2022. Publisher Full Text 64. Matser V: BioExcel Deliverable 4.2 – Competency framework, mapping to current training & initial training plan. Zenodo. 2016. Publisher Full Text 65. Morgan AC, LaBerge N, Larremore DB, et al. : Socioeconomic roots of academic faculty. Nat. Hum. Behav. 2022; 6 (12): 1625–1633. PubMed Abstract | Publisher Full Text | Free Full Text 66. Mulder N, Schwartz R, Brazas MD, et al. : The development and application of bioinformatics core competencies to improve bioinformatics training and education. PLoS Comput. Biol. 2018; 14 (2): e1005772. PubMed Abstract | Publisher Full Text | Free Full Text 67. Mundt M, Burgess W, Vigil D: A Tiered Approach to Scientific Software Quality Practices. Albuquerque, NM (United States): Sandia National Lab.(SNL-NM); 2022. Publisher Full Text 68. Mundt MR, Beattie K, Bisila J, et al. : For the Public Good: Connecting, Retaining, and Recognizing Current and Future RSEs at U.S. National Research Laboratories and Agencies. Comput. Sci. Eng. 2022; 24 (6): 6–13. Publisher Full Text 69. Netherlands eScience Center: What Is a Research Software Engineer? A Definition by the Netherlands eScience Center. Tech. rep. Version 1.0.2023-06. Publisher Full Text 70. Nieva A, de la Hidalga A , Hardisty PM, et al. : The ENVRI Reference Model. Towards Interoperable Research Infrastructures for Environmental and Earth Sciences. 2020; pp. 61–81. Publisher Full Text 71. Parker WS: Evidence and Knowledge from Computer Simulation. Erkenntnis. 2022-08; 87 (4): 1521–1538. Publisher Full Text 72. PRACE: Partnership for Advanced Computing in Europe. Retrieved June 16, 2023. Reference Source 73. Procida D: Diátaxis documentation framework. Reference Source 74. Richardson K, Steffen W, Lucht W, et al. : Earth beyond six of nine planetary boundaries. Sci. Adv. 2023; 9 (37): eadh2458. PubMed Abstract | Publisher Full Text | Free Full Text 75. RSE Competencies Toolkit team: RSE Competencies Toolkit. GitHub; 2023. Reference Source 76. RSEs International: International Council of RSE Associations.2025. Reference Source 77. Schlauch T, Meinel M, Haupt C: DLR Software Engineering Guidelines. Zenodo. 2018. Publisher Full Text 78. Schneegans S, Straza T, Lewis J: editors: UNESCO Science Report: the race against time for smarter development. Paris: 2021. Reference Source 79. Scholtens S, Jetten M, Böhmer J, et al. : Final report: Towards FAIR data steward as profession for the lifesciences. Report of a ZonMw funded collaborative approach built on existing expertise. Zenodo. 2019. Publisher Full Text 80. Segal J: Some challenges facing software engineers developing software for scientists. Proceedings of the 2009 ICSE Workshop on Software Engineering for Computational Science and Engineering (Vancouver, British Columbia, Canada, 2009-05-23/2009-05-23). IEEE; 2009-05. Publisher Full Text 81. Sills J, Hagedorn G, Kalmus P, et al. : Concerns of young protesters are justified. Science. 2019; 364 (6436): 139–140. PubMed Abstract | Publisher Full Text 82. Smith AM, Katz DS, Niemeyer KE, et al. : Software Citation Principles. PeerJ. Comput. Sci. 2016; 2 : e86. Publisher Full Text 83. Smithies J: Research Software (RS) Careers. Generic Learnings from King’s Digital Lab, King’s College London. Report. Version 6.0. King’s Digital Lab; 2018. Publisher Full Text 84. Herb Sutter: The Free Lunch Is Over. A Fundamental Turn Toward Concurrency in Software.2004. Retrieved April 10, 2024. Reference Source 85. The Carpentries: The Carpentries. Retrieved December 12, 2024. Reference Source 86. The Carpentries: Software Carpentry. Retrieved July 25, 2023. Reference Source 87. The European Parliament and the Council of the European Union: Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Off. J. Eur. Union. 2016; 59 : L 119. Reference Source 88. The HPC Certification Forum: HPC Certification Forum. Retrieved November 1, 2023. Reference Source 89. The HPC Certification Forum: Competencies. Retrieved June 16, 2023. Reference Source 90. The teachingRSE project: Learning and teaching RSE. Retrieved December 12, 2024. Reference Source 91. The Turing Way Community: The Turing Way: A Handbook for Reproducible, Ethical and Collaborative Research. Zenodo. 2022. Publisher Full Text 92. Tractenberg RE, Lindvall JM, Attwood TK, et al. : The Mastery Rubric for Bioinformatics: A tool to support design and evaluation of career-spanning education and training. PLoS One. 2019; 14 (11): e0225256. PubMed Abstract | Publisher Full Text | Free Full Text 93. UNIVERSE HPC: Understanding and Nurturing an Integrated Vision for Education in RSE and HPC. Retrieved June 16, 2023. Reference Source 94. Wang J: Survival factors for Free Open Source Software projects: A multi-stage perspective. Eur. Manag. J. 2012; 30 (4): 352–371. Publisher Full Text 95. Welch L, Brooksbank C, Schwartz R, et al. : Applying, Evaluating and Refining Bioinformatics Core Competencies (An Update from the Curriculum Task Force of ISCB’s Education Committee). PLoS Comput. Biol. 2016; 12 (5): e1004943. PubMed Abstract | Publisher Full Text | Free Full Text 96. Welch L, Lewitter F, Schwartz R, et al. : Bioinformatics Curriculum Guidelines: Toward a Definition of Core Competencies. PLoS Comput. Biol. 2014; 10 (3): e1003496. PubMed Abstract | Publisher Full Text | Free Full Text 97. Wiese I, Polato I, Pinto G: Naming the Pain in Developing Scientific Software. IEEE Softw. 2020; 37 (4): 75–82. Publisher Full Text 98. Wilkinson MD, Dumontier M, Aalbersberg IJ, et al. : The FAIR Guiding Principles for scientific data management and stewardship. Sci. Data. 2016; 3 (1): 160018. 2052-4463. PubMed Abstract | Publisher Full Text | Free Full Text 99. Winsberg E: Sanctioning Models: The Epistemology of Simulation. Sci. Context. 1999; 12 (2): 275–292. Publisher Full Text 100. xSDK: xSDK: Extreme-scale Scientific Software Development Kit. Retrieved March 31, 2025. Reference Source 101. ReproHack Hub: Building Communities of Practice in Reproducibility.2023. Retrieved July 25, 2023. Reference Source 102. Collaborations Workshop 2023 (CW23). Retrieved October 27, 2023. Reference Source 103. SureSoft. Retrieved July 14, 2023. Reference Source 104. NFDI: Section Training & Education. Retrieved July 27, 2023. Reference Source 105. German National Research Data Infrastructure (NFDI). Retrieved July 14, 2023. Reference Source 106. Virtual Institute - High Productivity Supercomputing. Retrieved May 6, 2024. Reference Source 107. Investing in Research Teams. Retrieved July 31, 2024. Reference Source 108. The Technician Commitment. Retrieved July 31, 2024. Reference Source 109. Professionals in Computational Biomolecular Research. Retrieved October 30, 2023. Reference Source 110. Export Control in Science & Research. Retrieved August 4, 2023. Reference Source Comments on this article Comments (0) Version 2 VERSION 2 PUBLISHED 26 Nov 2024 ADD YOUR COMMENT Comment Author details Author details 1 Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universität Würzburg, Würzburg, Bavaria, Germany 2 European Molecular Biology Laboratory, Heidelberg, Baden-Württemberg, Germany 3 Cluster of Excellence IntCDC, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 4 ZB MED Information Centre for Life Sciences, Cologne, North Rhine-Westphalia, Germany 5 Institute for Parallel and Distributed Systems, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 6 School of Computation, Information and Technology, Technical University of Munich, Garching, Bavaria, Germany 7 Leibniz University Hannover, Department of Cell Biology and Biophysics, Hanover, Lower Saxony, Germany 8 Department of Computing, Imperial College London, London, England, UK 9 Institute of Software Technology, German Aerospace Center DLR Berlin, Berlin, Berlin, Germany 10 Helmholtz-Zentrum Dresden-Rossendorf, Dresden, Saxony, Germany 11 Institute for Computational Physics, University of Stuttgart, Stuttgart, Baden-Württemberg, Germany 12 Geschäftsbereich IT, Charité Universitätsmedizin Berlin, Berlin, Berlin, Germany 13 The Carpentries, Oakland, California, USA 14 Scientific Software Center, Universität Heidelberg, Heidelberg, Baden-Württemberg, Germany 15 Institute of Computer Science, University of Potsdam, Potsdam, Brandenburg, Germany 16 Technische Universität Braunschweig, Brunswick, Lower Saxony, Germany 17 Michael Stifel Center Jena, Friedrich Schiller University Jena, Jena, Thuringia, Germany 18 Bavarian Academy of Sciences and Humanities Leibniz Supercomputing Centre, Garching, Bavaria, Germany 19 Mathematical Modeling and Analysis, TU Darmstadt Department of Mathematics, Darmstadt, Hesse, Germany 20 Institute for Globally Distributed Open Research and Education, Gothenburg, Västra Götaland County, Sweden 21 Weierstrass Institute for Applied Analysis and Stochastics, Berlin, Berlin, Germany 22 Scientific Computing, Leibniz University Hannover Institute of Applied Mathematics, Hanover, Lower Saxony, Germany 23 Centre for Information Management, Johann Heinrich von Thünen Institute, Braunschweig, Lower Saxony, Germany 24 CSC IT Center for Science Ltd, Espoo, Uusimaa, Finland Florian Goth Roles: Data Curation, Funding Acquisition, Project Administration, Supervision, Writing – Original Draft Preparation, Writing – Review & Editing Renato Alves Roles: Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing Matthias Braun Roles: Data Curation, Writing – Review & Editing Leyla Jael Castro Roles: Writing – Review & Editing Gerasimos Chourdakis Roles: Data Curation, Writing – Review & Editing Simon Christ Roles: Software, Visualization, Writing – Review & Editing Jeremy Cohen Roles: Writing – Original Draft Preparation, Writing – Review & Editing Stephan Druskat Roles: Writing – Review & Editing Fredo Erxleben Roles: Writing – Review & Editing Jean-Noël Grad Roles: Software, Writing – Original Draft Preparation, Writing – Review & Editing Magnus Hagdorn Roles: Data Curation, Writing – Review & Editing Toby Hodges Roles: Data Curation, Writing – Review & Editing Guido Juckeland Roles: Writing – Review & Editing Dominic Kempf Roles: Writing – Review & Editing Anna-Lena Lamprecht Roles: Writing – Review & Editing Jan Linxweiler Roles: Writing – Original Draft Preparation, Writing – Review & Editing Frank Löffler Roles: Writing – Review & Editing Michele Martone Roles: Writing – Review & Editing Moritz Schwarzmeier Roles: Writing – Review & Editing Heidi Seibold Roles: Conceptualization, Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing Jan Philipp Thiele Roles: Data Curation, Project Administration, Writing – Original Draft Preparation, Writing – Review & Editing Harald von Waldow Roles: Writing – Review & Editing Samantha Wittke Roles: Data Curation, Writing – Original Draft Preparation, Writing – Review & Editing Competing interests No competing interests were disclosed. Grant information FG acknowledges funding from the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) through the SFB 1170 “Tocotronics”, project Z03 - project number 258499086 as well as financial support by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy through the Würzburg-Dresden Cluster of Excellence on Complexity and Topology in Quantum Matter – ct.qmat (EXC 2147, project-id 390858490). MB acknowledges support by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy – EXC 2120/1 – 390831618. LJC acknowledges support from the NFDI4DS consortium funded by the German Research Foundation (DFG) - project number 460234259. JC acknowledges support from the UK Engineering and Physical Sciences Research Council (UKRI-EPSRC) under grants EP/R025460/1, EP/W035731/1 and EP/Y530608/1. JNG acknowledges funding from the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) - project number 391126171 (PI: Holm), from the German Federal Ministry of Education and Research (Bundesmin- isteriums für Bildung und Forschung, BMBF) under the funding code 16HPC095, and from the European Union – this work has received funding from the European High Performance Computing Joint Undertaking (JU) and countries participating in the project under grant agreement No 101093169. DK is funded by the Scientific Software Center which is part of the Excellence Strategy of the German Federal and State Governments. MM is funded by the SiVeGCS Project. MS would like to thank Hessian Ministry of Higher Education, Research, Science and the Arts and the Federal Government and the Heads of Government of the Länder, as well as the Joint Science Conference (GWK), for their funding and support within the framework of the NFDI4Ing consortium. Part of this work was funded by the German Research Foundation (DFG) - project number 442146713. Part of this work was funded by the Hessian Ministry of Higher Education, Research, Science and the Arts - cluster project Clean Circles. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. Article Versions (2) version 2 Revised Published: 08 Sep 2025, 13:1429 https://doi.org/10.12688/f1000research.157778.2 version 1 Published: 26 Nov 2024, 13:1429 https://doi.org/10.12688/f1000research.157778.1 Copyright © 2025 Goth F et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Download Export To Sciwheel Bibtex EndNote ProCite Ref. Manager (RIS) Sente metrics Views Downloads F1000Research - - PubMed Central info_outline Data from PMC are received and updated monthly. - - Citations open_in_new 0 open_in_new 0 open_in_new SEE MORE DETAILS CITE how to cite this article Goth F, Alves R, Braun M et al. Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.12688/f1000research.157778.2 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS track receive updates on this article Track an article to receive email alerts on any updates to this article. TRACK THIS ARTICLE Share Open Peer Review Current Reviewer Status: ? Key to Reviewer Statuses VIEW HIDE Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Version 1 VERSION 1 PUBLISHED 26 Nov 2024 Views 0 Cite How to cite this report: Schmitt U. Reviewer Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345501 ) The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345501 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 26 Dec 2024 Uwe Schmitt , ETH Zurich, Zürich, Zurich, Switzerland Approved VIEWS 0 https://doi.org/10.5256/f1000research.173278.r345501 # Summary The paper addresses many aspects of working as an RSE in different roles and the skills required or recommended to work effectively and to a high standard in this area. As outlined, RSEs work in ... Continue reading READ ALL # Summary The paper addresses many aspects of working as an RSE in different roles and the skills required or recommended to work effectively and to a high standard in this area. As outlined, RSEs work in a wide variety of roles and as such the inclusion of many contributors helps to ensure that many different aspects are covered and considered. In addition, the authors outline future scenarios on how the current situation can be systematically shaped and improved. The paper is well structured and readable and makes a significant contribution to the understanding and future development of different RSE roles, required skills and training and career paths. The authors also outline future publications based on this article. # Minor corrections and suggestions. I think the title of the publication only describes part of the content and does not include the proposed suggestions and scenarios for the future of RSE skills development and support. A different title, along the lines of "Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions" might better describe the content of the article. ## Section 3 (Values) This sentence appears to be corrupted due to editing: “Central to that code is the RSE’s obligation to In addition to the values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. ## Page 14 bottom: I recommend to separate the following two paragraphs: RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). **END OF PARAGRAPH HERE** Research software can often start out as a tool to answer a personal research question, becoming more important when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key processes that deal with critical questions such as weather forecasting or medical diagnosis. ## Table 4 The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. ## 5.4.1 Indentation of the bullet points after “Research skills” seems to be broken. Is the topic of the opinion article discussed accurately in the context of the current literature? Yes Are all factual statements correct and adequately supported by citations? Yes Are arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Senior RSE in different scientific domains. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Schmitt U. Reviewer Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345501 ) The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345501 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 08 Sep 2025 Florian Goth , Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany 08 Sep 2025 Author Response Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript ... Continue reading Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript in detail: ## Reviewer 2: Section 3(Values) > This sentence appears to be corrupted due to editing: > “Central to that code is the RSE’s obligation to In addition to the > values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” > “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. - corrupted sentence is fixed in markdown version of the paper - changed "RSEs also adhere to the SE Code of Ethics..." to "RSEs also need to adhere to..." to indicate that this is an aspiration - good point to refer back to values from the example curriculum. We have expanded the example curriculum accordingly. ## Reviewer 2 (GH: #395) Reviewer 2 Feedback: page 14 bottom > I recommend to separate the following two paragraphs: > RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s > stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). > END OF PARAGRAPH HERE > Research software can often start out as a tool to answer a personal research question, becoming more important > when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key > processes that deal with critical questions such as weather forecasting or medical diagnosis. - We added a line break at the indicated position. ## Reviewer 2: > Indentation of the bullet points after “Research skills” seems to be broken. Thanks for the feedback, We fixed the indentation in 5.4.1. While at it, we also regenerated the table of contents for F1000. ## Reviewer 2: > The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. We checked, the bus factor is referenced in the glossary. We have used the opportunity, to include an html link to the glossary here. Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript in detail: ## Reviewer 2: Section 3(Values) > This sentence appears to be corrupted due to editing: > “Central to that code is the RSE’s obligation to In addition to the > values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” > “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. - corrupted sentence is fixed in markdown version of the paper - changed "RSEs also adhere to the SE Code of Ethics..." to "RSEs also need to adhere to..." to indicate that this is an aspiration - good point to refer back to values from the example curriculum. We have expanded the example curriculum accordingly. ## Reviewer 2 (GH: #395) Reviewer 2 Feedback: page 14 bottom > I recommend to separate the following two paragraphs: > RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s > stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). > END OF PARAGRAPH HERE > Research software can often start out as a tool to answer a personal research question, becoming more important > when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key > processes that deal with critical questions such as weather forecasting or medical diagnosis. - We added a line break at the indicated position. ## Reviewer 2: > Indentation of the bullet points after “Research skills” seems to be broken. Thanks for the feedback, We fixed the indentation in 5.4.1. While at it, we also regenerated the table of contents for F1000. ## Reviewer 2: > The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. We checked, the bus factor is referenced in the glossary. We have used the opportunity, to include an html link to the glossary here. Competing Interests: No competing interests were disclosed. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 08 Sep 2025 Florian Goth , Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany 08 Sep 2025 Author Response Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript ... Continue reading Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript in detail: ## Reviewer 2: Section 3(Values) > This sentence appears to be corrupted due to editing: > “Central to that code is the RSE’s obligation to In addition to the > values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” > “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. - corrupted sentence is fixed in markdown version of the paper - changed "RSEs also adhere to the SE Code of Ethics..." to "RSEs also need to adhere to..." to indicate that this is an aspiration - good point to refer back to values from the example curriculum. We have expanded the example curriculum accordingly. ## Reviewer 2 (GH: #395) Reviewer 2 Feedback: page 14 bottom > I recommend to separate the following two paragraphs: > RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s > stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). > END OF PARAGRAPH HERE > Research software can often start out as a tool to answer a personal research question, becoming more important > when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key > processes that deal with critical questions such as weather forecasting or medical diagnosis. - We added a line break at the indicated position. ## Reviewer 2: > Indentation of the bullet points after “Research skills” seems to be broken. Thanks for the feedback, We fixed the indentation in 5.4.1. While at it, we also regenerated the table of contents for F1000. ## Reviewer 2: > The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. We checked, the bus factor is referenced in the glossary. We have used the opportunity, to include an html link to the glossary here. Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript in detail: ## Reviewer 2: Section 3(Values) > This sentence appears to be corrupted due to editing: > “Central to that code is the RSE’s obligation to In addition to the > values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” > “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. - corrupted sentence is fixed in markdown version of the paper - changed "RSEs also adhere to the SE Code of Ethics..." to "RSEs also need to adhere to..." to indicate that this is an aspiration - good point to refer back to values from the example curriculum. We have expanded the example curriculum accordingly. ## Reviewer 2 (GH: #395) Reviewer 2 Feedback: page 14 bottom > I recommend to separate the following two paragraphs: > RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s > stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). > END OF PARAGRAPH HERE > Research software can often start out as a tool to answer a personal research question, becoming more important > when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key > processes that deal with critical questions such as weather forecasting or medical diagnosis. - We added a line break at the indicated position. ## Reviewer 2: > Indentation of the bullet points after “Research skills” seems to be broken. Thanks for the feedback, We fixed the indentation in 5.4.1. While at it, we also regenerated the table of contents for F1000. ## Reviewer 2: > The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. We checked, the bus factor is referenced in the glossary. We have used the opportunity, to include an html link to the glossary here. Competing Interests: No competing interests were disclosed. Close Report a concern COMMENT ON THIS REPORT Views 0 Cite How to cite this report: Mundt M. Reviewer Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345505 ) The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345505 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 17 Dec 2024 Miranda Mundt , Sandia National Laboratories, New Mexico, USA Approved VIEWS 0 https://doi.org/10.5256/f1000research.173278.r345505 # Paper Review - Foundational Competencies and Responsibilities of an RSE ## Summary This paper presents an idyllic image of what RSE education and career paths could be. It presents a detailed (but high-level) ... Continue reading READ ALL # Paper Review - Foundational Competencies and Responsibilities of an RSE ## Summary This paper presents an idyllic image of what RSE education and career paths could be. It presents a detailed (but high-level) overview of competencies and provides example specializations. It is unclear the full intended scope (i.e., is this meant to be an emphasis on RSEs only in academia? Only in Europe? All RSEs in all roles worldwide?) Overall, this is clearly a paper that is well-considered, well-formatted, and a labor of love. ## Specific Feedback - Scope: How large is the scope of this paper? Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? Also is it meant to be aspirational (e.g., all RSEs should have these) or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? - Section 2 (Related Work): - Related to scope question: If this is intended to be more widespread, I recommend including references to INTERSECT (https://intersect-training.org), BSSw (https://bssw.io), and IDEAS-productivity (https://ideas-productivity.org) - Section 3 (Values) - I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. - First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." - I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - Section 3.1 (Challenges) - I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) - There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") - Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph - Section 3.1.2 - I agree with all of the points here *but* it's realistically not just up to RSEs to embrace and shape diversity. What does it mean for them to "mitigate them whenever they have the chance to do so"? Examples might be helpful. - Section 4 - can you include a footnote to any digital information on the Paderborn workshop? - Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 - Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) - Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well - Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. - Section 5.2 (Helpful RSE skills in academic career) - I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... - Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) - Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). - Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) - Section 6 - This section is my favorite. I love the examples of different specializations because it allows a lot of readers to "see" themselves in this paper. Is the topic of the opinion article discussed accurately in the context of the current literature? Partly Are all factual statements correct and adequately supported by citations? Yes Are arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Research software engineering with an emphasis on testing, reproducibility, and diversity; FAIR(ER) principles (E = Equitable, R = Realistic) I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Mundt M. Reviewer Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345505 ) The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345505 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 08 Sep 2025 Florian Goth , Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany 08 Sep 2025 Author Response Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer ... Continue reading Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer 1: Scope > Scope: How large is the scope of this paper? > Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? > Also is it meant to be aspirational (e.g., all RSEs should have these) > or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? We acknowledge that the scope and the perspective might be confusing in parts. We have extended the abstract and the introduction to clarify that the foundational competencies are based on what is often encountered in Germany and beyond, while aiming to be guidelines for aspiring RSEs. We have also clarified that our recommendations draw from experiences in Germany, Europe, and the US, but are not specific to a particular region. A subtitle was added to better reflect the scope and aims of the paper. ## Reviewer 1: Related work > - Section 2 (Related Work): > - Related to scope question: If this is intended to be more widespread, I recommend including references to > INTERSECT (https://intersect-training.org), > BSSw (https://bssw.io), and > IDEAS-productivity (https://ideas-productivity.org) We have now added these examples from the USA, which we previously missed. Thank you for reporting these blind spots! ## Reviewer 1: Section 3 (Values) > I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. > First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." > I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - we agree with the reviewer that many RSEs are probably unaware of these code of conducts. However we feel that this is an important aspect for RSEs going forward. They will need at least some basic familiarity with it to support their future work. - add sentences to explain why these values are stated explicitly here even though many practioners will learn about these values by following the examples of their peers and mentors. - reworded the paragraph on computer-based modeling to improve flow. - fixed in markdown version of the paper ## Reviewer 1 Feedback 4: > can you include a footnote to any digital information on the Paderborn workshop? > Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 > Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) > Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well > Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. We thank the reviewer for their feedback! In more detail: - We made the original session pads available on zenodo and linked them in the bibliography. "Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491" - We thank the reviewer for this reference and augmented the section on the software life cycle with it. "Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well" - We qualified it in both sections accordingly. "Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc." - We thank the referee for this suggestion, and we took then the opportunity to link to the overview page of the international RSE council, which lists all national groups, and thereby also will be updated in the future. ## Reviewer 1 Feedback: Section 3.1 > Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph Good point, we have renamed the section. > I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) > There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") We thank the reviewer for his/her feedback. We now mention the funding problem in the future work section of the paper. We thank the referee for the additional references, Since we don't feel that is a challenge that has a stronger influence on the education of an RSE than it would have for any other domain scientist. The Integration into teams is now mentioned in the Tasks-and-Responsibilities section. ## Reviewer 1 Feedback: Section 5 > Section 5.2 > I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... > Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) We agree that a full license discussion would be too much for a Bachelor's degree, we really mean a very basic awareness, e.g. that different licenses exist and may come with obligations like copyleft. This would fit in a more general discussion around good scientific practice as a primer to a Bachelor's thesis. We expanded on what we mean by awareness to hopefully make this clearer. Sections 5.2 is about RSE skills that academic researchers may need without being or ever becoming RSEs, so this would not be the place to address this issue. We have expanded the introduction to make this distinction clearer. However, we agree that a PhD is not (and should not be) a requirement to work as an RSE and as hinted at in the future work section we are working on composing a curriculum for a Master's degree in RSE. > Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). We have clarified that this type of RSE (alone in a team of non-RSEs) is also meant in the category "Individual RSE (Locally-based)". > Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) fixed, thanks for reporting! Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer 1: Scope > Scope: How large is the scope of this paper? > Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? > Also is it meant to be aspirational (e.g., all RSEs should have these) > or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? We acknowledge that the scope and the perspective might be confusing in parts. We have extended the abstract and the introduction to clarify that the foundational competencies are based on what is often encountered in Germany and beyond, while aiming to be guidelines for aspiring RSEs. We have also clarified that our recommendations draw from experiences in Germany, Europe, and the US, but are not specific to a particular region. A subtitle was added to better reflect the scope and aims of the paper. ## Reviewer 1: Related work > - Section 2 (Related Work): > - Related to scope question: If this is intended to be more widespread, I recommend including references to > INTERSECT (https://intersect-training.org), > BSSw (https://bssw.io), and > IDEAS-productivity (https://ideas-productivity.org) We have now added these examples from the USA, which we previously missed. Thank you for reporting these blind spots! ## Reviewer 1: Section 3 (Values) > I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. > First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." > I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - we agree with the reviewer that many RSEs are probably unaware of these code of conducts. However we feel that this is an important aspect for RSEs going forward. They will need at least some basic familiarity with it to support their future work. - add sentences to explain why these values are stated explicitly here even though many practioners will learn about these values by following the examples of their peers and mentors. - reworded the paragraph on computer-based modeling to improve flow. - fixed in markdown version of the paper ## Reviewer 1 Feedback 4: > can you include a footnote to any digital information on the Paderborn workshop? > Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 > Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) > Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well > Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. We thank the reviewer for their feedback! In more detail: - We made the original session pads available on zenodo and linked them in the bibliography. "Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491" - We thank the reviewer for this reference and augmented the section on the software life cycle with it. "Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well" - We qualified it in both sections accordingly. "Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc." - We thank the referee for this suggestion, and we took then the opportunity to link to the overview page of the international RSE council, which lists all national groups, and thereby also will be updated in the future. ## Reviewer 1 Feedback: Section 3.1 > Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph Good point, we have renamed the section. > I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) > There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") We thank the reviewer for his/her feedback. We now mention the funding problem in the future work section of the paper. We thank the referee for the additional references, Since we don't feel that is a challenge that has a stronger influence on the education of an RSE than it would have for any other domain scientist. The Integration into teams is now mentioned in the Tasks-and-Responsibilities section. ## Reviewer 1 Feedback: Section 5 > Section 5.2 > I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... > Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) We agree that a full license discussion would be too much for a Bachelor's degree, we really mean a very basic awareness, e.g. that different licenses exist and may come with obligations like copyleft. This would fit in a more general discussion around good scientific practice as a primer to a Bachelor's thesis. We expanded on what we mean by awareness to hopefully make this clearer. Sections 5.2 is about RSE skills that academic researchers may need without being or ever becoming RSEs, so this would not be the place to address this issue. We have expanded the introduction to make this distinction clearer. However, we agree that a PhD is not (and should not be) a requirement to work as an RSE and as hinted at in the future work section we are working on composing a curriculum for a Master's degree in RSE. > Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). We have clarified that this type of RSE (alone in a team of non-RSEs) is also meant in the category "Individual RSE (Locally-based)". > Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) fixed, thanks for reporting! Competing Interests: No competing interests were disclosed. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 08 Sep 2025 Florian Goth , Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany 08 Sep 2025 Author Response Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer ... Continue reading Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer 1: Scope > Scope: How large is the scope of this paper? > Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? > Also is it meant to be aspirational (e.g., all RSEs should have these) > or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? We acknowledge that the scope and the perspective might be confusing in parts. We have extended the abstract and the introduction to clarify that the foundational competencies are based on what is often encountered in Germany and beyond, while aiming to be guidelines for aspiring RSEs. We have also clarified that our recommendations draw from experiences in Germany, Europe, and the US, but are not specific to a particular region. A subtitle was added to better reflect the scope and aims of the paper. ## Reviewer 1: Related work > - Section 2 (Related Work): > - Related to scope question: If this is intended to be more widespread, I recommend including references to > INTERSECT (https://intersect-training.org), > BSSw (https://bssw.io), and > IDEAS-productivity (https://ideas-productivity.org) We have now added these examples from the USA, which we previously missed. Thank you for reporting these blind spots! ## Reviewer 1: Section 3 (Values) > I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. > First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." > I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - we agree with the reviewer that many RSEs are probably unaware of these code of conducts. However we feel that this is an important aspect for RSEs going forward. They will need at least some basic familiarity with it to support their future work. - add sentences to explain why these values are stated explicitly here even though many practioners will learn about these values by following the examples of their peers and mentors. - reworded the paragraph on computer-based modeling to improve flow. - fixed in markdown version of the paper ## Reviewer 1 Feedback 4: > can you include a footnote to any digital information on the Paderborn workshop? > Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 > Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) > Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well > Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. We thank the reviewer for their feedback! In more detail: - We made the original session pads available on zenodo and linked them in the bibliography. "Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491" - We thank the reviewer for this reference and augmented the section on the software life cycle with it. "Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well" - We qualified it in both sections accordingly. "Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc." - We thank the referee for this suggestion, and we took then the opportunity to link to the overview page of the international RSE council, which lists all national groups, and thereby also will be updated in the future. ## Reviewer 1 Feedback: Section 3.1 > Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph Good point, we have renamed the section. > I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) > There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") We thank the reviewer for his/her feedback. We now mention the funding problem in the future work section of the paper. We thank the referee for the additional references, Since we don't feel that is a challenge that has a stronger influence on the education of an RSE than it would have for any other domain scientist. The Integration into teams is now mentioned in the Tasks-and-Responsibilities section. ## Reviewer 1 Feedback: Section 5 > Section 5.2 > I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... > Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) We agree that a full license discussion would be too much for a Bachelor's degree, we really mean a very basic awareness, e.g. that different licenses exist and may come with obligations like copyleft. This would fit in a more general discussion around good scientific practice as a primer to a Bachelor's thesis. We expanded on what we mean by awareness to hopefully make this clearer. Sections 5.2 is about RSE skills that academic researchers may need without being or ever becoming RSEs, so this would not be the place to address this issue. We have expanded the introduction to make this distinction clearer. However, we agree that a PhD is not (and should not be) a requirement to work as an RSE and as hinted at in the future work section we are working on composing a curriculum for a Master's degree in RSE. > Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). We have clarified that this type of RSE (alone in a team of non-RSEs) is also meant in the category "Individual RSE (Locally-based)". > Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) fixed, thanks for reporting! Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer 1: Scope > Scope: How large is the scope of this paper? > Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? > Also is it meant to be aspirational (e.g., all RSEs should have these) > or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? We acknowledge that the scope and the perspective might be confusing in parts. We have extended the abstract and the introduction to clarify that the foundational competencies are based on what is often encountered in Germany and beyond, while aiming to be guidelines for aspiring RSEs. We have also clarified that our recommendations draw from experiences in Germany, Europe, and the US, but are not specific to a particular region. A subtitle was added to better reflect the scope and aims of the paper. ## Reviewer 1: Related work > - Section 2 (Related Work): > - Related to scope question: If this is intended to be more widespread, I recommend including references to > INTERSECT (https://intersect-training.org), > BSSw (https://bssw.io), and > IDEAS-productivity (https://ideas-productivity.org) We have now added these examples from the USA, which we previously missed. Thank you for reporting these blind spots! ## Reviewer 1: Section 3 (Values) > I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. > First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." > I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - we agree with the reviewer that many RSEs are probably unaware of these code of conducts. However we feel that this is an important aspect for RSEs going forward. They will need at least some basic familiarity with it to support their future work. - add sentences to explain why these values are stated explicitly here even though many practioners will learn about these values by following the examples of their peers and mentors. - reworded the paragraph on computer-based modeling to improve flow. - fixed in markdown version of the paper ## Reviewer 1 Feedback 4: > can you include a footnote to any digital information on the Paderborn workshop? > Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 > Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) > Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well > Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. We thank the reviewer for their feedback! In more detail: - We made the original session pads available on zenodo and linked them in the bibliography. "Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491" - We thank the reviewer for this reference and augmented the section on the software life cycle with it. "Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well" - We qualified it in both sections accordingly. "Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc." - We thank the referee for this suggestion, and we took then the opportunity to link to the overview page of the international RSE council, which lists all national groups, and thereby also will be updated in the future. ## Reviewer 1 Feedback: Section 3.1 > Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph Good point, we have renamed the section. > I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) > There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") We thank the reviewer for his/her feedback. We now mention the funding problem in the future work section of the paper. We thank the referee for the additional references, Since we don't feel that is a challenge that has a stronger influence on the education of an RSE than it would have for any other domain scientist. The Integration into teams is now mentioned in the Tasks-and-Responsibilities section. ## Reviewer 1 Feedback: Section 5 > Section 5.2 > I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... > Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) We agree that a full license discussion would be too much for a Bachelor's degree, we really mean a very basic awareness, e.g. that different licenses exist and may come with obligations like copyleft. This would fit in a more general discussion around good scientific practice as a primer to a Bachelor's thesis. We expanded on what we mean by awareness to hopefully make this clearer. Sections 5.2 is about RSE skills that academic researchers may need without being or ever becoming RSEs, so this would not be the place to address this issue. We have expanded the introduction to make this distinction clearer. However, we agree that a PhD is not (and should not be) a requirement to work as an RSE and as hinted at in the future work section we are working on composing a curriculum for a Master's degree in RSE. > Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). We have clarified that this type of RSE (alone in a team of non-RSEs) is also meant in the category "Individual RSE (Locally-based)". > Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) fixed, thanks for reporting! Competing Interests: No competing interests were disclosed. Close Report a concern COMMENT ON THIS REPORT Comments on this article Comments (0) Version 2 VERSION 2 PUBLISHED 26 Nov 2024 ADD YOUR COMMENT Comment keyboard_arrow_left keyboard_arrow_right Open Peer Review Reviewer Status info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Reviewer Reports Invited Reviewers 1 2 Version 2 (revision) 08 Sep 25 Version 1 26 Nov 24 read read Miranda Mundt , Sandia National Laboratories, New Mexico, USA Uwe Schmitt , ETH Zurich, Zürich, Switzerland Comments on this article All Comments (0) Add a comment Sign up for content alerts Sign Up You are now signed up to receive this alert Browse by related subjects keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2024 Schmitt U. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 26 Dec 2024 | for Version 1 Uwe Schmitt , ETH Zurich, Zürich, Zurich, Switzerland 0 Views copyright © 2024 Schmitt U. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions # Summary The paper addresses many aspects of working as an RSE in different roles and the skills required or recommended to work effectively and to a high standard in this area. As outlined, RSEs work in a wide variety of roles and as such the inclusion of many contributors helps to ensure that many different aspects are covered and considered. In addition, the authors outline future scenarios on how the current situation can be systematically shaped and improved. The paper is well structured and readable and makes a significant contribution to the understanding and future development of different RSE roles, required skills and training and career paths. The authors also outline future publications based on this article. # Minor corrections and suggestions. I think the title of the publication only describes part of the content and does not include the proposed suggestions and scenarios for the future of RSE skills development and support. A different title, along the lines of "Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions" might better describe the content of the article. ## Section 3 (Values) This sentence appears to be corrupted due to editing: “Central to that code is the RSE’s obligation to In addition to the values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. ## Page 14 bottom: I recommend to separate the following two paragraphs: RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). **END OF PARAGRAPH HERE** Research software can often start out as a tool to answer a personal research question, becoming more important when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key processes that deal with critical questions such as weather forecasting or medical diagnosis. ## Table 4 The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. ## 5.4.1 Indentation of the bullet points after “Research skills” seems to be broken. Is the topic of the opinion article discussed accurately in the context of the current literature? Yes Are all factual statements correct and adequately supported by citations? Yes Are arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Senior RSE in different scientific domains. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (1) Author Response 08 Sep 2025 Florian Goth, Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany Dear reviewer, we thank you for your constructive feedback and have used it for an improved version, that will be public here shortly. Here is how we adapted the manuscript in detail: ## Reviewer 2: Section 3(Values) > This sentence appears to be corrupted due to editing: > “Central to that code is the RSE’s obligation to In addition to the > values for good scientific practice commit to the health, safety and welfare of the public and act in the interest of society, their employer and their clients.” > “RSEs also adhere to the SE Code of Ethics”: As much as I agree with the proposed values, I would prefer the subjunctive/conjunctive form here, as used in other parts of the document. The teaching of these values could be strengthened in the later section proposing bachelor and master curricula. - corrupted sentence is fixed in markdown version of the paper - changed "RSEs also adhere to the SE Code of Ethics..." to "RSEs also need to adhere to..." to indicate that this is an aspiration - good point to refer back to values from the example curriculum. We have expanded the example curriculum accordingly. ## Reviewer 2 (GH: #395) Reviewer 2 Feedback: page 14 bottom > I recommend to separate the following two paragraphs: > RSEs are also mentoring colleagues (see also Section 3.1.2). This necessitates giving good advice that fits to a project’s > stage in its life cycle, thereby requiring knowledge of ( SWLC), and its context in its research domain and thus ( RC). > END OF PARAGRAPH HERE > Research software can often start out as a tool to answer a personal research question, becoming more important > when other researchers start to rely on it. At the other end of the scale, research software can sometimes underpin key > processes that deal with critical questions such as weather forecasting or medical diagnosis. - We added a line break at the indicated position. ## Reviewer 2: > Indentation of the bullet points after “Research skills” seems to be broken. Thanks for the feedback, We fixed the indentation in 5.4.1. While at it, we also regenerated the table of contents for F1000. ## Reviewer 2: > The row “SLWC” mentions “bus factors” several times and may need explanation, or should be added to the glossary. We checked, the bus factor is referenced in the glossary. We have used the opportunity, to include an html link to the glossary here. View more View less Competing Interests No competing interests were disclosed. reply Respond Report a concern Schmitt U. Peer Review Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345501) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345501 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2024 Mundt M. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 17 Dec 2024 | for Version 1 Miranda Mundt , Sandia National Laboratories, New Mexico, USA 0 Views copyright © 2024 Mundt M. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions # Paper Review - Foundational Competencies and Responsibilities of an RSE ## Summary This paper presents an idyllic image of what RSE education and career paths could be. It presents a detailed (but high-level) overview of competencies and provides example specializations. It is unclear the full intended scope (i.e., is this meant to be an emphasis on RSEs only in academia? Only in Europe? All RSEs in all roles worldwide?) Overall, this is clearly a paper that is well-considered, well-formatted, and a labor of love. ## Specific Feedback - Scope: How large is the scope of this paper? Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? Also is it meant to be aspirational (e.g., all RSEs should have these) or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? - Section 2 (Related Work): - Related to scope question: If this is intended to be more widespread, I recommend including references to INTERSECT (https://intersect-training.org), BSSw (https://bssw.io), and IDEAS-productivity (https://ideas-productivity.org) - Section 3 (Values) - I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. - First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." - I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - Section 3.1 (Challenges) - I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) - There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") - Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph - Section 3.1.2 - I agree with all of the points here *but* it's realistically not just up to RSEs to embrace and shape diversity. What does it mean for them to "mitigate them whenever they have the chance to do so"? Examples might be helpful. - Section 4 - can you include a footnote to any digital information on the Paderborn workshop? - Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 - Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) - Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well - Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. - Section 5.2 (Helpful RSE skills in academic career) - I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... - Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) - Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). - Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) - Section 6 - This section is my favorite. I love the examples of different specializations because it allows a lot of readers to "see" themselves in this paper. Is the topic of the opinion article discussed accurately in the context of the current literature? Partly Are all factual statements correct and adequately supported by citations? Yes Are arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Research software engineering with an emphasis on testing, reproducibility, and diversity; FAIR(ER) principles (E = Equitable, R = Realistic) I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (1) Author Response 08 Sep 2025 Florian Goth, Würzburg-Dresden Cluster of Excellence ct.qmat, Julius-Maximilians-Universitat Wurzburg, Würzburg, Germany Dear reviewer, We thank you for your constructive comments, and a future update will include changes to reflect your feedback. Here is what we did in detail: ## Reviewer 1: Scope > Scope: How large is the scope of this paper? > Is it meant to encompass RSEs around the globe or focused primarily on European RSEs? > Also is it meant to be aspirational (e.g., all RSEs should have these) > or does it represent the current state of RSEs (e.g., most RSEs already have these competencies)? We acknowledge that the scope and the perspective might be confusing in parts. We have extended the abstract and the introduction to clarify that the foundational competencies are based on what is often encountered in Germany and beyond, while aiming to be guidelines for aspiring RSEs. We have also clarified that our recommendations draw from experiences in Germany, Europe, and the US, but are not specific to a particular region. A subtitle was added to better reflect the scope and aims of the paper. ## Reviewer 1: Related work > - Section 2 (Related Work): > - Related to scope question: If this is intended to be more widespread, I recommend including references to > INTERSECT (https://intersect-training.org), > BSSw (https://bssw.io), and > IDEAS-productivity (https://ideas-productivity.org) We have now added these examples from the USA, which we previously missed. Thank you for reporting these blind spots! ## Reviewer 1: Section 3 (Values) > I'd push back on the claim that RSEs adhere to the SE Code of Ethics purely because, as stated earlier in the paper, a lot of RSEs don't have classical training and wouldn't even necessarily know that those ethics exist. Do they probably adhere to them accidentally? Yes. But I'd suspect the average RSE couldn't reliably list anything in the SE Code of Ethics. > First paragraph, something is missing here / incomplete sentence/thought: "Central to that code is the RSE's obligation to In addition to the values..." > I had a bit of a hard time following the computer-based modeling paragraphs / understanding why a discussion of them was happening until the second to last sentence of the paragraph that starts with "The relationship between initial state..." - we agree with the reviewer that many RSEs are probably unaware of these code of conducts. However we feel that this is an important aspect for RSEs going forward. They will need at least some basic familiarity with it to support their future work. - add sentences to explain why these values are stated explicitly here even though many practioners will learn about these values by following the examples of their peers and mentors. - reworded the paragraph on computer-based modeling to improve flow. - fixed in markdown version of the paper ## Reviewer 1 Feedback 4: > can you include a footnote to any digital information on the Paderborn workshop? > Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491 > Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) > Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well > Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc. We thank the reviewer for their feedback! In more detail: - We made the original session pads available on zenodo and linked them in the bibliography. "Section 4.1.2 - there are multiple research software maturity models/frameworks that have been proposed that adapt SWLC. See, for example, M. R. Mundt, W. Burgess and D. M. Vigil, "A Tiered Approach to Scientific Software Quality Practices," in Proceedings of the 2022 Improving Scientific Software Conference (No. NCAR/TN-574+PROC). doi:10.5065/98kd-b491" - We thank the reviewer for this reference and augmented the section on the software life cycle with it. "Section 4.1.5 - I recommend adding a note here for "as applicable," e.g., some RSEs at some institutions may not be able to share code publicly because of security or institutional requirements (though they should still use whatever they can for version controlling) Section 4.2.4 - Similar note to 4.1.5; there should be something about "adhering to institutional policies" as well" - We qualified it in both sections accordingly. "Section 4.4 (Tasks and Responsibilities) - When talking about RSE communities, it might be worth it to reference some of them, e.g., UK-RSE / Soc RSE, deRSE, US-RSE, RSE-AUNZ, RSE Asia, RSSE Africa, etc." - We thank the referee for this suggestion, and we took then the opportunity to link to the overview page of the international RSE council, which lists all national groups, and thereby also will be updated in the future. ## Reviewer 1 Feedback: Section 3.1 > Section 3.1.1 - this almost might be better if phrased as "Data Security" because that's kind of the crux of the paragraph Good point, we have renamed the section. > I notice that "funding methods" is missing from these challenges; there has been a lot of discussion about unreliable funding methods for software and, as a result, RSEs (e.g., https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886129, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9470770, https://pure.manchester.ac.uk/ws/portalfiles/portal/54140648/StateOfTheNationReport2017.pdf, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10071971) > There is also a lack of "RSEs being integrated into existing teams and having to fight that team's culture". Maybe this is too niche to bring up, but it is a challenge that has been spoken about amongst RSE circles (e.g., "How can I get an existing team to change their processes when they are so stuck in their ways?") We thank the reviewer for his/her feedback. We now mention the funding problem in the future work section of the paper. We thank the referee for the additional references, Since we don't feel that is a challenge that has a stronger influence on the education of an RSE than it would have for any other domain scientist. The Integration into teams is now mentioned in the Tasks-and-Responsibilities section. ## Reviewer 1 Feedback: Section 5 > Section 5.2 > I disagree with some of the claims here (e.g., license discussion for Bachelor's degree seems like too much). Generally, though, this section is nice. However... > Not all RSEs have PhDs. Most of them do, yes, but many RSEs who do NOT have PhDs are still wildly successful without having gained the proposed skills as PhD students. How do you address that scenario (i.e., where an RSE stops after a Bachelors, Masters, etc.?) We agree that a full license discussion would be too much for a Bachelor's degree, we really mean a very basic awareness, e.g. that different licenses exist and may come with obligations like copyleft. This would fit in a more general discussion around good scientific practice as a primer to a Bachelor's thesis. We expanded on what we mean by awareness to hopefully make this clearer. Sections 5.2 is about RSE skills that academic researchers may need without being or ever becoming RSEs, so this would not be the place to address this issue. We have expanded the introduction to make this distinction clearer. However, we agree that a PhD is not (and should not be) a requirement to work as an RSE and as hinted at in the future work section we are working on composing a curriculum for a Master's degree in RSE. > Section 5.3 (Project team structures) - there is a gap here: "The single RSE on a team of not-RSEs who does not have a central RSE team connection." These do exist (sadly). We have clarified that this type of RSE (alone in a team of non-RSEs) is also meant in the category "Individual RSE (Locally-based)". > Section 5.4.1 - formatting weirdness in the Research Skills sub-list (pg 22) fixed, thanks for reporting! View more View less Competing Interests No competing interests were disclosed. reply Respond Report a concern Mundt M. Peer Review Report For: Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions [version 2; peer review: 2 approved] . F1000Research 2025, 13 :1429 ( https://doi.org/10.5256/f1000research.173278.r345505) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/13-1429/v1#referee-response-345505 Alongside their report, reviewers assign a status to the article: Approved - the paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations - A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved - fundamental flaws in the paper seriously undermine the findings and conclusions Adjust parameters to alter display View on desktop for interactive features Includes Interactive Elements View on desktop for interactive features Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Stay Updated Sign up for content alerts and receive a weekly or monthly email with all newly published articles Register with F1000Research Already registered? Sign in Not now, thanks close PLEASE NOTE If you are an AUTHOR of this article, please check that you signed in with the account associated with this article otherwise we cannot automatically identify your role as an author and your comment will be labelled as a “User Comment”. If you are a REVIEWER of this article, please check that you have signed in with the account associated with this article and then go to your account to submit your report, please do not post your review here. If you do not have access to your original account, please contact us . All commenters must hold a formal affiliation as per our Policies . The information that you give us will be displayed next to your comment. User comments must be in English, comprehensible and relevant to the article under discussion. We reserve the right to remove any comments that we consider to be inappropriate, offensive or otherwise in breach of the User Comment Terms and Conditions . Commenters must not use a comment for personal attacks. When criticisms of the article are based on unpublished data, the data should be made available. I accept the User Comment Terms and Conditions Please confirm that you accept the User Comment Terms and Conditions. Affiliation ✕ refresh Please enter your institution. Note: To add your institution or organisation, start typing the name and then select the correct name from the list. Where applicable, the name will appear in both the original language and in English. Do not paste in the name. If the name does not appear in the drop-down list, we will display the information you have entered. ✕ refresh Country/Region * USA UK Canada China France Germany Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Cook Islands Costa Rica Cote d'Ivoire Croatia Cuba Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Federated States of Micronesia Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and Mcdonald Islands Holy See (Vatican City State) Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo (Serbia and Montenegro) Kuwait Kyrgyzstan Lao People's Democratic Republic Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Minor Outlying Islands of the United States Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea North Macedonia Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russian Federation Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Is South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand The Gambia The Netherlands Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu UK USA Uganda Ukraine United Arab Emirates United States Virgin Islands Uruguay Uzbekistan Vanuatu Venezuela Vietnam Wallis and Futuna West Bank and Gaza Strip Western Sahara Yemen Zambia Zimbabwe Please select your country/region. You must enter a comment. Competing Interests Please disclose any competing interests that might be construed to influence your judgment of the article's or peer review report's validity or importance. Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Please state your competing interests The comment has been saved. An error has occurred. Please try again. Cancel Post var lTitle = "Foundational Competencies and Responsibilities...".replace("'", ''); var linkedInUrl = "http://www.linkedin.com/shareArticle?url=https://f1000research.com/articles/13-1429/v2" + "&title=" + encodeURIComponent(lTitle) + "&summary=" + encodeURIComponent('Read the article by '); var deliciousUrl = "https://del.icio.us/post?url=https://f1000research.com/articles/13-1429/v2&title=" + encodeURIComponent(lTitle); var redditUrl = "http://reddit.com/submit?url=https://f1000research.com/articles/13-1429/v2" + "&title=" + encodeURIComponent(lTitle); linkedInUrl += encodeURIComponent('Goth F et al.'); var offsetTop = /chrome/i.test( navigator.userAgent ) ? 4 : -10; var addthis_config = { ui_offset_top: offsetTop, services_compact : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_expanded : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_custom : [ { name: "LinkedIn", url: linkedInUrl, icon:"/img/icon/at_linkedin.svg" }, { name: "Mendeley", url: "http://www.mendeley.com/import/?url=https://f1000research.com/articles/13-1429/v2/mendeley", icon:"/img/icon/at_mendeley.svg" }, { name: "Reddit", url: redditUrl, icon:"/img/icon/at_reddit.svg" }, ] }; var addthis_share = { url: "https://f1000research.com/articles/13-1429", templates : { twitter : "Foundational Competencies and Responsibilities of a Research.... Goth F et al., published by " + "@F1000Research" + ", https://f1000research.com/articles/13-1429/v2" } }; if (typeof(addthis) != "undefined"){ addthis.addEventListener('addthis.ready', checkCount); addthis.addEventListener('addthis.menu.share', checkCount); } $(".f1r-shares-twitter").attr("href", "https://twitter.com/intent/tweet?text=" + addthis_share.templates.twitter); $(".f1r-shares-facebook").attr("href", "https://www.facebook.com/sharer/sharer.php?u=" + addthis_share.url); $(".f1r-shares-linkedin").attr("href", addthis_config.services_custom[0].url); $(".f1r-shares-reddit").attr("href", addthis_config.services_custom[2].url); $(".f1r-shares-mendelay").attr("href", addthis_config.services_custom[1].url); function checkCount(){ setTimeout(function(){ $(".addthis_button_expanded").each(function(){ var count = $(this).text(); if (count !== "" && count != "0") $(this).removeClass("is-hidden"); else $(this).addClass("is-hidden"); }); }, 1000); } close How to cite this report {{reportCitation}} Cancel Copy Citation Details $(function(){R.ui.buttonDropdowns('.dropdown-for-downloads');}); $(function(){R.ui.toolbarDropdowns('.toolbar-dropdown-for-downloads');}); $.get("/articles/acj/157778/185339") new F1000.Clipboard(); new F1000.ThesaurusTermsDisplay("articles", "article", "185339"); $(document).ready(function() { $( "#frame1" ).on('load', function() { var mydiv = $(this).contents().find("div"); var h = mydiv.height(); console.log(h) }); var tooltipLivingFigure = jQuery(".interactive-living-figure-label .icon-more-info"), titleLivingFigure = tooltipLivingFigure.attr("title"); tooltipLivingFigure.simpletip({ fixed: true, position: ["-115", "30"], baseClass: 'small-tooltip', content:titleLivingFigure + " " }); tooltipLivingFigure.removeAttr("title"); $("body").on("click", ".cite-living-figure", function(e) { e.preventDefault(); var ref = $(this).attr("data-ref"); $(this).closest(".living-figure-list-container").find("#" + ref).fadeIn(200); }); $("body").on("click", ".close-cite-living-figure", function(e) { e.preventDefault(); $(this).closest(".popup-window-wrapper").fadeOut(200); }); $(document).on("mouseup", function(e) { var metricsContainer = $(".article-metrics-popover-wrapper"); if (!metricsContainer.is(e.target) && metricsContainer.has(e.target).length === 0) { $(".article-metrics-close-button").click(); } }); var articleId = $('#articleId').val(); if($("#main-article-count-box").attachArticleMetrics) { $("#main-article-count-box").attachArticleMetrics(articleId, { articleMetricsView: true }); } }); var figshareWidget = $(".new_figshare_widget"); if (figshareWidget.length > 0) { window.figshare.load("f1000", function(Widget) { // Select a tag/tags defined in your page. In this tag we will place the widget. _.map(figshareWidget, function(el){ var widget = new Widget({ articleId: $(el).attr("figshare_articleId") //height:300 // this is the height of the viewer part. [Default: 550] }); widget.initialize(); // initialize the widget widget.mount(el); // mount it in a tag that's on your page // this will save the widget on the global scope for later use from // your JS scripts. This line is optional. //window.widget = widget; }); }); } close Error Close Add Reset F1000.MICROSERVICES.AFFILIATION = ''; $(document).ready(function () { $('.js-affiliations-form').each((index, form) => { new AffiliationForm({ formId: form.id, institutionErrorSelector: '.comment-enter-institution', departmentErrorSelector: '.comment-enter-department', placeSelector: '.js-add-comment-place', stateSelector: '.js-add-comment-state', zipCodeSelector: '.js-add-comment-zipcode', countrySelector: '.js-add-comment-country', countryErrorSelector: '.comment-enter-country', }); }); }); $(document).ready(function () { var reportIds = { "345508": 0, "412212": 0, "345505": 41, "345504": 0, "412211": 0, "345507": 0, "345506": 0, "345501": 32, "345500": 0, "345503": 0, "345502": 0, "345499": 0, }; $(".referee-response-container,.js-referee-report").each(function(index, el) { var reportId = $(el).attr("data-reportid"), reportCount = reportIds[reportId] || 0; $(el).find(".comments-count-container,.js-referee-report-views").html(reportCount); }); var uuidInput = $("#article_uuid"), oldUUId = uuidInput.val(), newUUId = "28ae4b65-4e32-42c8-8d8e-60f53e1352ae"; uuidInput.val(newUUId); $("a[href*='article_uuid=']").each(function(index, el) { var newHref = $(el).attr("href").replace(oldUUId, newUUId); $(el).attr("href", newHref); }); }); An innovative open access publishing platform offering rapid publication and open peer review, whilst supporting data deposition and sharing. Browse Gateways Collections How it Works Contact For Developers Cookie Notice Privacy Notice RSS Submit Your Research Follow us © 2012-2026 F1000 Research Ltd. ISSN 2046-1402 | Legal | Partner of Research4Life • CrossRef • ORCID • FAIRSharing R.templateTests.simpleTemplate = R.template(' $text $text $text $text $text '); R.templateTests.runTests(); var F1000platform = new F1000.Platform({ name: "f1000research", displayName: "F1000Research", hostName: "f1000research.com", id: "1", editorialEmail: "[email protected]", infoEmail: "[email protected]", usePmcStats: true }); $(function(){R.ui.dropdowns('.dropdown-for-authors, .dropdown-for-about, .dropdown-for-myresearch');}); // $(function(){R.ui.dropdowns('.dropdown-for-referees');}); $(document).ready(function () { if ($(".cookie-warning").is(":visible")) { $(".sticky").css("margin-bottom", "35px"); $(".devices").addClass("devices-and-cookie-warning"); } $(".cookie-warning .close-button").click(function (e) { $(".devices").removeClass("devices-and-cookie-warning"); $(".sticky").css("margin-bottom", "0"); }); $("#tweeter-feed .tweet-message").each(function (i, message) { var self = $(message); self.html(linkify(self.html())); }); $(".partner").on("mouseenter mouseleave", function() { $(this).find(".gray-scale, .colour").toggleClass("is-hidden"); }); }); Sign In Remember me Forgotten your password? Sign In Cancel Email or password not correct. Please try again Please wait... $(function(){ // Note: All the setup needs to run against a name attribute and *not* the id due the clonish // nature of facebox... $("a[id=googleSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("GOOGLE"); $("form[id=oAuthForm]").submit(); }); $("a[id=facebookSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("FACEBOOK"); $("form[id=oAuthForm]").submit(); }); $("a[id=orcidSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("ORCID"); $("form[id=oAuthForm]").submit(); }); }); If you've forgotten your password, please enter your email address below and we'll send you instructions on how to reset your password. The email address should be the one you originally registered with F1000. Email address not valid, please try again You registered with F1000 via Google, so we cannot reset your password. To sign in, please click here . If you still need help with your Google account password, please click here . You registered with F1000 via Facebook, so we cannot reset your password. To sign in, please click here . If you still need help with your Facebook account password, please click here . Code not correct, please try again Reset password Cancel Email us for further assistance. Server error, please try again. If your email address is registered with us, we will email you instructions to reset your password. If you think you should have received this email but it has not arrived, please check your spam filters and/or contact for further assistance. Please wait... Register $(document).ready(function () { signIn.createSignInAsRow($("#sign-in-form-gfb-popup")); $(".target-field").each(function () { var uris = $(this).val().split("/"); if (uris.pop() === "login") { $(this).val(uris.toString().replace(",","/")); } }); });