Proposal: Upgrading the HSDS Governance model

Thanks to @devin and @mrshll, we’ve assembled a proposed upgrade to the governance model for HSDS in this document here.

The document contains a set of defined roles, a proposal for a new standing committee to oversee development of HSDS, and a detailed process for managing specification updates across different levels of significance. (The document also includes, in the final section, the current description of our governance model for reference.)

I encourage questions or comments on this document – by default, we’ll give this request for comment period at least two weeks.

During this period, we have a standing technical meeting – on March 13th at noon ET – which is an opportunity for us to discuss any issues that might arise. If you don’t have that on your calendar, let me know and I’ll send you the invite.

If any significant issues emerge during this period, especially anything on the non-technical side, I will organize at least one dedicated call in which they can be addressed. Anyone should feel free to submit their own proposal here, either as a derivation of this one or even a new alternative.

Let me know if you have any questions or suggestions – thanks!

1 Like

Thanks @bloom, @devin and @mrshll. I’m pretty happy with this document now.

As I previously explained, the UK Government Data Standards Authority approved Open Referral UK as a profile of Open Referral (international) on the understanding that the Standard remains open, free from vested interests and with an open/transparent change control process. That remains the case. I’ve suggested one further small change in the document to confirm it.

I understand that there remains freedom for individual profiles to be defined based on the core Open Referral specification, as we have done in the UK. Given the increasing importance of Open Referral in the UK, I want to draw the document to the attention of @Jukesie and @emanukgb.

@bloom @devin

I’ve added a comment to the doc with a link to a proposal template we’ve put together.

We’re thinking it could be used for singular/specific requests or groupings of similar/related requests to support the ‘Issues and Proposals’ through to ‘Version Upgrade Proposal’ stage.

At which point, we (ODSC) would be looking to synthesise all of the approved proposals into a final proposal for the upgrade in it’s entirety, ready for the next stage - ‘Requests for comments and community input’.

@MikeThacker @ftravais-solinum @skyleryoung - You will see we’ve included a ‘Considerations for existing Profiles’ section.

Dan

1 Like

We’ve gotten good feedback on the proposal and have made minor clarifications – though no major changes. See here.

We’ll give some more time for any other input to come thru, and otherwise expect to approve the proposal after the next standing technical meetup (on April 10th).

OK I have updated the Governance and Participation page on our website, and also pushed an update to the technical governance documentation page in the branch that @Dan-ODS set up for this purpose.

@Dan-ODS when you’re back we’ll check in to affirm and assuming everything checks out it can be pushed live.

We’ll have to update this documentation again when the Technical Committee is formed, and then again when it’s chartered.

1 Like

All merged Greg. Here’s the link as I expect we’ll be wanting to direct people to it from the website - Specification Governance — Open Referral Data Specifications 3.0.1 documentation

@bloom @devin @klambacher @MikeThacker @skyleryoung @SarahP

@mrshll has created Summaries of Proposed Issues for 3.1

This is off the back of the discussion we had at March’s Technical Meetup where we agreed this as an intermediary step to help the forming technical committee engage (without having to parse meaning from github issues) before taking proposed items through the formal proposal process.

There is no immediate need for feedback as we are planning for next steps to be guided by a fully formed and chartered technical committee

Thanks,

Dan

Hi all,

See my comments in on issue 508 related to the process and how we plan to follow it.

@klambacher you weren’t a member of OR on github so have just invited you. @SarahP I can’t find you on github can you share you username so I can invite you?

Thanks,

Dan

Hi Dan,
I thought I had an account but it appears I didn’t. You should be able to find me now.

Username: SPottelberg

1 Like

‘Technical Committee Review.’

In our flowchart, we say this step in the process consists of ‘Committee and stewards review issue classifications, refine issues and prioritize them for codification.’

Options for how we can go about this:

1. Steward-Driven Prioritisation

Similar to the approach for version 3.1, Technical Stewards would handle issue triage, classification, and prioritisation asynchronously, then share a prioritised list with the Technical Committee for feedback and sign-off. Although this method received positive feedback, some felt it allowed the stewards too much influence.

2. Collaborative Prioritisation

Under this option, Technical Stewards would initially triage and classify issues asynchronously, then collaborate with the Technical Committee in one or more of the following:

  • Technical Committee meetings
  • Dedicate priority-setting meetings
  • Within a dedicated working group

To collectively review and prioritise issues that the stewards would develop into formal proposals.

3. Committee-Driven Prioritisation

With this approach, stewards would triage and classify issues, after which committee members could independently review and prioritise them, determining which issues should proceed to formal proposal. This reflects feedback that the stewards should be guided by a committee actively representing community needs.

Options 2 and 3 would require stewards to format and organise issues clearly to enable committee engagement—for example, summarised issue overviews, thematic tagging, and consistent formatting.

Feel free to leave comments but we will discuss next Wednesday meeting.

I’ve also added this to github issue #475

Dan