Is your feature request related to a problem? Please describe.
There is currently no good practiice guidance on when PHS analysts should host code in repositories on GitHub and when they should use the internally hosted repositories on the Gitea for PHS platform.
Describe what you'd like
The good practice guidance could be either within existing PHS documentation on using Git and version control, or could be as a separate document.
Guidance can explain the difference between Gitea for PHS and Github and strengths and weaknesses of both.
Guidance can set out a preference for using Github, and why this is important from a transparency and open data perspective (some of this is in existing guidance) - some additional guidance would be helpful
Guidance can provide examples of when use of Gitea may be appropriate.
Guidance can be provided on how to migrate code from PHS Gitea to Github, for example where a new publication is being produced or a section is being added to a publication, how code can be migrated to Github and made public once data is published.
Guidance should not be proscriptive, but can hopefully encourage PHS analysts currently reluctant to use version control hosted on GitHub or PHS Gitea, to start using version control and hosting code on at least one of these platforms..
Guidance can enhance existing good practice; where teams are already sharing code for publications on GitHub, the guidance should not conflict with existing good practice.
Describe alternatives you've considered
Analysts use their best guess of when it is appropriate to use GitHub or Gitea for PHS.
Argument against:- This leads to inconsistency in which some PHS code is hosted on Github and some on PHS Gitea with some teams using one, and some using another. Some code is placed on the PHS Gitea and not on GitHub, and is not publicly accessible when it should be.
Analysts don't use version control at all, for code related to sensitive analysis or publications, because of concerns about hosting this code on a non-secure platform.
Argument against:- We want to encourage use of version control for all coding within PHS, without guidance on when PHS Gitea can be used, and it's advantages for more sensitive data and projects, there is a risk that analysts will choose not to use version control at all as the project is deemed 'too sensitive to go on a public platform'.
Additional context
Some PHS analysis involves analysing data related to very sensitive topics, where analyses are only published internally or only released as management information and are not published in the public domain.
In other cases initial coding work may be to create a new publication or a new section of the publication where no data is currently published in the public domain.
In these cases although, no data will be included in the code, the code itself potentially may reveal information about data held which may be sensitive, either commercially sensitive, or sensitive for various GDPR related, confidentiality and / or Information Governance reasons.
Whilst it may be possible to partition off sections of code that hold 'sensitive' material and not publish them on GitHub, this is not always practical in the initial development phase of coding, and may not be possible or practical at all, depending on the information and data analysed by code for a project or publication.
Whilst there is already some discussion of the value of publicly hosting code and making it open and transparent in existing PHS GitHub documentation, making this more explicit and emphasising the value of this further, could be helpful in encouraging all analysts, whatever project they are working on, to make code public on GitHub where possible.
Suggested example workflows for working on code on more 'sensitive' projects or for more management information or new publications, where analysts may be reluctant to host code as a public repository on GitHub could be useful.
An example could be where code is initially worked on and pushed to a repository in the internal Gitea for PHS, then either all the code (e.g. once data is published for the first time) , or some of the code - where sections of code are deemed too sensitive to share, are migrated to GitHub within an agreed time scale.
More than one example of a workflow will likely be helpful.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent