Annual review of SOP0007: GDI-SOP0007_sop-template-creation.md

[M-casado]

Summary

Revisioned SOP0007 to update it to latest changes in the process, adding links to documentation and mainly removing any steps related to ZenHub.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New content (non-breaking change which adds new content)
• Modified content (non-breaking change which modifies existing content)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Motivation and Context

Motivated by the annual review process.

References

#67

Changes Introduced

• Updated content
• Removed ZenHub steps

Review

The major content has been reviewed thoroughly in the previous development rounds, and by the T4.3 members that used the SOP.

Additional Notes

NA

Checklist:

General Compliance:

• My changes follow the code style of this project (GDI SOP Style Guide) and the file naming conventions of the file accessioning proposal.
• I have verified that all new updated content is accessible, including checking that all external references are readable (i.e., no broken links). These may include references to external resources that should be resolvable, and internal references among SOPs.
• I have properly added this PR's changes to the repository CHANGELOG.md.

Only applicable if the PR includes new, or changes to, GDI SOPs (i.e., documents at sops/):

• My SOP-related changes adhere to the Generic SOP Template, including format and required fields.
• I have consulted the Charter, ISM, and ORR documents to ensure compliance.
• I am complying with the established procedure for SOP creations and modifications, including respecting review phases and notifying needed contributors for reviews.

[M-casado]

The SOP review is finished, @GabiRinck

[jdylan]

At the OC meeting on 13/05/2026 we discussed the 'procedures' of the review process and tried to clarify specific responsibilities form the OC / SDPC steps, e.g. assigning individuals etc.

The overview of the process from the committees perspective is as below:

1. After a SOP request is received in the repository, the OC evaluates the request. If it is valid, the OC assignes and OC member to prepare the SOP draft from the GDI General SOP template. The OC member is assigned for step 2.
2. The OC member shares the template with the authors (OC/SDPC or nominated experts) to write the SOP (i.e. fill in the content).
3. After the drafting is completed, the OC shares the draft internally or with experts to review for completeness.
4. Both committees (OC/SDPC) approve the reviewed document.
5. The OC then shares the approved SOP with the GDI MB for authorization.
6. GDI MB reviews the SOP and authorises or requests changes (repeat from Step 3)
7. The OC accessions (7.2.)the authorised SOP according to the agreed process and the SOP goes into production.
8. The OC initiates periodic review cycle (7.3.), if updates are needed then repeats steps 3-6.

The above attempts to clarify the responsible party to ensure there is no duplication of effort and task are done on time.

[M-casado]

@jdylan , if I understood your suggestions correctly:

• The handling of a request is no longer done by members of SDPC and OC, but OC alone. This way, SDPC would only be asked to approve SOPs (along OC), but not to manage their development.
• Step 8.2 (to create the RFC discussion) may be redundant. So far, to be fair, we haven't gotten much engagement in any of the RFCs except one, and it was from members of T4.3 ourselves.
• Re. the MB authorisation, are there any changes suggested by the OC to the MB's veto-period at all, or it remain as is? Your phrasing implies an explicit authorisation from MB, but we have not worked with that model in the past, and instead relied on explicit approval, but implicit authorisation.

If there are any other changes, let me know and I'll add them to this PR. So far, your listed steps match the existing ones (in my opinion), except for the three things mentioned above.

[GabiRinck]

Following the discussion we had at the OC meeting last week, my understanding is...

• "The handling of a request is no longer done by members of SDPC and OC, but OC alone. This way, SDPC would only be asked to approve SOPs (along OC), but not to manage their development." -> Yes, if there are any SDPC-related aspects, then they can be consulted, if necessary.
• "[Step 8.2](to create the RFC discussion) may be redundant. So far, to be fair, we haven't gotten much engagement in any of the RFCs except one, and it was from members of T4.3 ourselves." -> Yes, the OC will decide on the validity of the request.
• "Re. the MB authorisation, are there any changes suggested by the OC to the MB's veto-period at all, or it remain as is?..." -> I don't remember that we discussed any changes to the current process or making changes to the MB veto period - so I think it will stay as it is (unless you think we should make changes based on the comments you had from Troels; but this was not discussed at the last OC).
• Yes, I think basically the process remains very similar to what is currently described, but OC takes on the task of pushing the SOP through the system, only the SDPC's role in approving the SOP remains unchanged.
  @jdylan, please feel free to add to/correct these responses, as appropriate.

[M-casado]

Current status: https://github.com/GenomicDataInfrastructure/standard-operating-procedures/blob/main/sops/european-level/GDI-SOP0007_sop-template-creation.md#852-request-ocsdpc-approval

Communication to the OC/SDPC requesting approval was done on the 26th of May 2026.

[omllobet]

LGTM for approval as an SDPC member.

One small detail: I noticed that you made some American-to-British English changes. You may also want to change “finalize/finalized” to “finalise/finalised” for consistency.

[M-casado]

Thanks for the review @omllobet - I'll check the whole document in case there are more mixes of the language

[M-casado]

Pending approval from 2 people of the OC and 1 person from the SDPC

[GabiRinck]

As discussed, here are additional details which were discussed with the GDI operations committee. It would be great to incorporate these into SOP0007:

• Q: Review vs Approval (ie. are both roles mutually exclusive?) -> someone who participated in an SOP review can also be nominated as an approver of the same SOP

• Q: Those Committee Members, who are part of both the OC & SDPC, can they approve an SOP on behalf of both committees, or only one??
  -> A person who is a member of both committees can approve on behalf of both committees. If this happens, then 2 more approvers are required for the same SOP, one from each committee; i.e. each SOP will have 3 - 4 approvers.

• Expected timeframe for SOP approval: once an SOP approver is appointed, the approval step should be completed within 2 weeks.

• Where appropriate, the approval of a document can be delegated to another GDI member who is not a committee member.

• The OC/SDPC are each responsible for appointing respective SOP approvers. A rota may be implemented to share the responsibility evenly across the committee members. (I don't think the SOP should make a rota mandatory, but it's recommended, just a suggestion rather than a "must")

[M-casado]

@GabiRinck - I added the new changes, so now there's a new Delegate role, and the code is updated to expect these things. Also, the approver-delegate link is checked in the table at the top of every SOP, if there's any delegation.

Regarding the Approvers of this specific SOP, I think it's best to remove the "previous" approvers and just leave the latest ones: Oscar and you. Once you have approved it, let me know which committee you approve it as to add it to the table.

Finally, should I send a reminder to the OC/SDPC for the last 2 approvers (unless 1 approves as both committees)? Or is it in the agenda of the committees already?

Note that the ❌ appears in the GH workflows as expected because the approvers are not typed yet. Once I know who they would be, I'll add them here.