Topics for noresm-telecon in March 2023

[DirkOlivie]

In view of a possible noresm-telecon in Jan/Dec 2023, we invite you to suggest topics which are relevant for the NorESM community. Possible topics :

• inform/share what goes on in various projects
• INES2 replacement
• NorESM2.0.6 release, status of NorESM2.2, status of NorESM2.3
• information on new storage system
• some (relevant) highlights from the winter AMWG meeting 2023 (in Boulder)
• scientific highlights
• ...

[TomasTorsvik]

Branch structure, permissions and naming in NorESM repository

• Is the current NorESM branch structure fit for purpose (see discussion Discussion on role of NorESM master branch #415 )?
• Should we "get with the times" and rename the default branch from master to main ?
• Should we enforce some kind of branch protection rules on the default branch (e.g. Require a pull request before merging)?

[TomasTorsvik]

NorESM on gitHub

• Who has admin rights on the different repositories in NorESMhub? This information is hidden for "normal" members/contributors/maintainers. Does anyone have an overview?
• Should we have a policy of minimum 2 admins per repository (if this is not already the case)? Or maybe it is not needed for all repositories, only main NorESM components?

[TomasTorsvik]

NorESM documentation: should this be in a separate repository?

• As an experiment, I have created a new repository for the NorESM documentation: NorESM-docs. At the moment it is only used to test building documentation on Read-the-Docs, but in principle it could be used as the main repository for the NorESM documentation. Some arguments for and against:
• PRO: We want documentation contributions from as many NorESM users as possible, but probably we don't want to open up for everyone to change NorESM config settings in the NorESM repository. A separate repository could make it easier to separate the "protected" part from the "open" part of the current NorESM repository.
• PRO: It could lower the threshold for new contributors to contribute to the documentation if there is no chance that they will mess up the main NorESM repository.
• CON: Further fragmentation of the NorESMhub system. NorESM is already fragmented since the components reside in separate repositories, but it may add to the confusion to have an additional repository to deal with for the documentation.
• PRO?/CON?: Unlink documentation from NorESM branches. At the moment the documentation in noresm2 and master are almost identical, and we need to take extra steps to sync updates between the branches. On the other hand, there is no ambiguity about which NorESM branch the documentation is related to when it resides inside the same branch. This could become a problem with a separate repositroy.