After talking with @daniel-wicke today on publically publishing two R packages used in the project-ogre (see KWB-R/kwb.ogre#2 and KWB-R/kwb.ogre.model#1) it became obvious that we currently are lacking a company wide strategy for publishing code.
For this a workflow should be developed within FAKIN and implemented in the QMS. This for sure requires that the KWB management and the department leaders
I would propose the following:
-
100% publically sponsored projects (e.g. BMBF, EU, and so on): source code will always be published on https://github.com/kwb-r as public repository (i.e. it will be accessible for everyone) in case it is possible to the code does not contain security critical paths (e.g. to our company server) or confidential data. Code should be developed in such a way that ideally does not include both (security critical paths and confidential data). Making the code openly available will decrease our burden to install them (e.g. not each student needs to get an "access" token to install private repositories, as required for "contract" projects, see below).
-
Contract projects (BWB, Veolia): will be published as private repositories by default on https://github.com/kwb-r in case that the funder does not pre-define a specific workflow.
Could this topic also be addressed within one of the next management meetings @chsprenger ?
After talking with @daniel-wicke today on publically publishing two R packages used in the project-ogre (see KWB-R/kwb.ogre#2 and KWB-R/kwb.ogre.model#1) it became obvious that we currently are lacking a company wide strategy for publishing code.
For this a workflow should be developed within FAKIN and implemented in the QMS. This for sure requires that the KWB management and the department leaders
I would propose the following:
100% publically sponsored projects (e.g. BMBF, EU, and so on): source code will always be published on https://github.com/kwb-r as public repository (i.e. it will be accessible for everyone) in case it is possible to the code does not contain security critical paths (e.g. to our company server) or confidential data. Code should be developed in such a way that ideally does not include both (security critical paths and confidential data). Making the code openly available will decrease our burden to install them (e.g. not each student needs to get an "access" token to install private repositories, as required for "contract" projects, see below).
Contract projects (BWB, Veolia): will be published as private repositories by default on https://github.com/kwb-r in case that the funder does not pre-define a specific workflow.
Could this topic also be addressed within one of the next management meetings @chsprenger ?