Inconsistent repository name and issues content

[giumas]

The repository is named "S-102-Product-Specification", but it contains issues that are not limited to the product specification, but related to the project team in general (for example, https://github.com/iho-ohi/S-102-Product-Specification/issues/19).

The 2 proposed options are:

• To rename the repository to something more general like "S-102PT" (similarly to https://github.com/iho-ohi/S130PT).
• To create one (or more) repository where PT issues not strictly related to the PS are handled. This seems the approach taken by S-101 PT: https://github.com/iho-ohi/S-101-Test-Datasets, https://github.com/iho-ohi/S-101_Portrayal-Catalogue, https://github.com/iho-ohi/S-101-Documentation-and-FC

[hasel001]

@giumas, I think your proposals are a great discussion topic for the PT12 meeting coming up.

I will muddy the water a bit further and ask the following:

Suppose one of us is approached by an S-102 stakeholder who either wants to provide feedback or to find a point of contact for a technical question. Might it be in the PT's best interest to have an outward-facing way for those stakeholders ledge their query? I can envision a GitHub Wiki site fulfilling those functions, but I am eager to hear everyone's opinions as to the best method of approach.

(By adding the above sidebar, my aim is to provide more fuel for the original decision by putting into context. That is to say, I'm not meaning to hijack the topic.)

Thoughts?

[RohdeBSH]

Hello everyone,

As I have said many times before. I think the approach of the S-101 repositories is an absolute nightmare. Whether it's PS, FC, PC or test data, it all belongs together. It is the combination of the information that makes the S-102. Individually, the information is useless. We should generally aim for "single point of information", that makes it easier for everyone. How should the different repositories be handled in a version-safe way? Example: The PS is already on version 2.2.0 in its repository in the main branch, the FC is still on version 2.1.0 in its repository in the main branch, and the PC is still on version 1.0.0. This is pure chaos for the information seeker.

I agree with @giumas is that the name of the repository is not optimal chosen. However, I can accept this, because FC, PC and test data are derived from the PS.

The current structure with all versions on the contemporaneous in the Main-Branch I also do not consider optimal. It would be better to have only the productive/active version in the main branch and the older versions as release and newer ones as dev branch. Then all data PS, FC, PC and test data could be stored on one hierarchy level. The question is how Metanorma deal with it (@ronaldtse).

I would create new folders in the current structure for the other data, then split them into the versions as well. Also I would delete the “reference-docs” folder, because I think it is not necessary. See https://github.com/RohdeBSH/S-102-Product-Specification_Structure

The labels on the issues can be used to control and identify different things. It just has to be used. The existing labels can be viewed on the GitHub page.

[ronaldtse]

The question is how Metanorma deal with it.

Metanorma can be configured to take any source path present in metanorma.yml, so feel free to first adjust the structure as preferred, and we can update/remove the obsolete paths from metanorma.yml.

[giumas]

The labels on the issues can be used to control and identify different things. It just has to be used. The existing labels can be viewed on the GitHub page.

@RohdeBSH, I cannot assign labels.

[ronaldtse]

@giumas I don't have access to assign labels either (I'm do not have write access to this repo). Perhaps @iho-ohi @RohdeBSH can help?

[giumas]

I agree with @giumas is that the name of the repository is not optimal chosen. However, I can accept this, because FC, PC and test data are derived from the PS.

Thus, renaming the repository S102PT would work even better given that the S102PT develops the S-102 Product Specification, and "FC, PC and test data are derived from the PS".

[RohdeBSH]

Oh, I didn't know that. I thought you all could assign the labels. Then only the contributors can do that.(?) But then it's weird that @ronaldtse can't do it. I don't have more rights than a contributor and it works for me.

[ronaldtse]

@RohdeBSH I'm likely not assigned a "contributor" role in this repository 😉

[hasel001]

BSH has action to draft a workflow/structure diagram and circulate among the PT (to occur during this meeting at a break). Lawrence has action to produce, revise, and circulate among the PT for review and comment. (PT12, 14Feb2023, lhh)

[RohdeBSH]

Here is our idea for handling proposals on GitHub.

[hasel001]

Agreed in S-102PT16 to close given lack of action.