I think the international group hopes to have a meeting on aggregators (aka federation tools) - see here. It would be good for you to join that if/when it is firmed up.
@bloom I included OR/OA as an agenda item due the amount of related activity across the forum and to see if there weāre emergent discussions to be had; rather than to discuss anything specific.
Same goes for taxonomies really.
Judging by comments, I donāt think we have anything concrete to discuss as a group and as lines of communication are open via the threads leaving it until June makes sense to me.
Iām happy either way, but will not amend the invite until I hear back from you.
Hi folks ā looking forward to our standing technical meetup on June 12th. (if youād like to attend but donāt have it on your calendar, let me know and I will send an invite.)
Hereās the video and transcript from our meeting last week (12th June) then see below for a summary of discussion points and follow-up actions.
Key discussion points
Committee Formation:
Membership to start with 5 (Devin, Kate, Sarah, Skyler, Mike). Ideally weād get 2 more with the aim of adding diversity going forward.
Charter development is the responsibility of the committee but Greg happy to support.
Charter format (brainstorm):
Purpose & Values
Member roles & Primary responsibilities (to inc. advising on tooling)
Joining & Leaving process
Setting priorities
Decision-making process
Dissolution.
Devin to take the lead on charter development on behalf of the committee.
3.1 Backlog Review:
Matt walked through what was intended to be a very informal summary doc created in response to feedback regarding the difficulty people we weāre having parsing meaning from the github issues.
The doc being restricted was an oversight and was not intended to be kept from view as demonstrated by this post into the public forum. All agree on openness and creating opportunities for contribution from the broader community throughout.
We discussed how the summary doc fits in with the agreed process and reviewed the flowchart.
It was agreed that Github would be used for formal spec development and G-Doc for narrative summaries.
There was a request for timescales
Skyler and Kate emphasized the importance of the schedule table issue and careful consideration of referrals. There was agreement on setting up a seperate working group to pull together the proposal for this.
Community Survey:
Additional outreach now required to get responses from the broader community.
Summit Discussion:
Consensus to wait until 2025 for a summit.
Some expressed a preference for short, subject-specific deep-dive meetings.
Discussed the need for distinguishing between HSDS and Open Referral needs/audiences.
@klambacher fed back on her difficulty keeping up with forum as someone that steps in and out and is not able to engage in the dynamic, ongoing communication that the forum lends itself to.
Actions:
Devin: Lead the charter development on behalf of the committee.
Committee & @bloom: Think about how best to recruit 2 additional members going forward to enhance diversity.
Upgrade to 3.1:
@Dan-ODS: Ensure the summary documents (and all future dosc) are open and accessible.
ODS: Use GitHub for formal spec development and G-Doc for narrative summaries.
All: Share the survey with relevant people in their networks.
Summit
@bloom Consider short, subject-specific deep-dive meetings within or instead of a 2025 summit. @bloom Consider reviewing takeaways from last yearās summit to inform planning for the next one.
Communications:
@Dan-ODS to consider how we can communicate in a way that means people get the information they need based on their level of engagement.
Follow-up response to this as we did not really respond to request for this in the meeting itself:
The formation of committee and refinements to the process (which ODS are talking to @devin separately next week) will impact on how quickly we can get to the actual work. That said, our current contract comes to an end at the end of September so weād be keen to get 3.1 released by then (at the latest).
@MikeThacker-iStandUK@skyleryoung tagging you specifically as you expressed a need to move things forward (or atleast have an idea of timescales so expectations can be managed) based on your specific circumstances.
Follow-up response to this as we did not really respond to request for this in the meeting itself:
The formation of committee and refinements to the process (which ODS are talking to @devin separately next week) will impact on how quickly we can get to the actual work. That said, our current contract comes to an end at the end of September so weād be keen to get 3.1 released by then (at the latest).
@skyleryoung Matt will of course be keen to be a part of this. @klambacher I suggested you based on the relevant experience you shared in the meeting (but also aware youāre super busy - hence the ? after your name).
Acknowledgement that the process weāve followed for 3.1 differs to the above process and is not how weād expect 3.2.
Summary/request/comments from ODS in Matt and Danās absence:
For version 3.1, ODS had already pre-curated issues weāve perceived as important and in-demand.
It would be good to double-check the committee is happy to proceed with our curated list?
We did cover this to some extent at the last meeting where we went through the summaries for proposed issues but I think we ended up implicitly talking about the above.
Going forward, weāll involve the technical committee more in summarizing and prioritizing GitHub issues, with the format of engagement to be decided by the committee.
Whilst it could be an option to walk back some steps and do this for 3.1, our preference based on Matt going back on paternity leave for #6 months mid-october would be to avoid delays to make best use of the two months we have left with Matt.
Community Survey Updates?
From Dan:
No response from TPXimpact - Perhaps Mike could nudge?
Have asked Rob (ODS) and David (former ODS) to complete.
Working towards more effective comms:
From Dan:
It would be good to clarify how/if Greg and Mikeās responses to my email align?
Several draft proposals for HSDS 3.1 were reviewed, with additional input gathered on location types (redacted, mobile) and capacity management
The technical committee charter was iteratively updated based on member feedback
UK HSDS tooling development was highlighted as an area for the committee to monitor and provide input
HSDS 3.1 Proposals
Matt Marshall presented draft proposals across various 3.1 issues, seeking committee review/involvement
Discussion on āredactedā location type for privacy, with nuances around field vs record redaction
āMobileā location type proposed to indicate services delivered via mobile unit
Capacity management remains a complex issue, may require flexible approach given varying needs
Technical Committee Charter
Statements added around meeting openness, decision-making process, membership terms
Process outlined for adding new members (nomination > committee decision > probationary period)
Need to further specify provisions for removing members if required
Subcommittees allowed but canāt make formal decisions without full committee approval
UK HSDS Tooling Development
Funded work underway in UK to develop HSDS validator tool
Outputs could potentially serve as validator for entire initiative
Committee will have opportunity to shape process and provide feedback
Agreed actions:
MM forum post summarising what I presented at the meeting, with links for those who werenāt there.
Iteration on the Location Type of āRedactedā proposal to clarify that we are also suggesting that we add guidance to the docs explaining implications and how to use it.
GB making updates in the charter, for review and approval next week.
Skyler to work with Matt and be in touch with Rob Redpath about the schedule / events issue.
Kate to share example of capacity schema with Matt, and Skyler to ask WellSky for their example schema.
GB will be in UK for next meeting, we can review the underway development of the UK validator.
Iteration on the Location Type of āRedactedā proposal to clarify that we are also suggesting that we add guidance to the docs explaining implications and how to use it.