Open Referral’s core team facilitates alignment and supports activities across the Open Referral network.
At a ‘global’ level, Open Referral’s core team consists of technical and institutional leadership. Core team members a) set the agenda for public discussions; b) oversee accountable administration of any grant funding or other resources in the Open Referral Initiative’s control; and c) make decisions in any instances in which the community cannot reach rough consensus. For each development cycle, Open Referral’s lead organizer (Greg Bloom) designates a lead technical steward to serve in the Core Team. The current technical steward is the Open Data Services Cooperative.
A standing Technical Committee oversees development of the Human Service Data Specifications.
[Updated Spring 2024.] The Human Service Data Specifications – Open Referral’s core technical product – are developed through transparent, consensus-based cycles that are facilitated by Open Referral’s core leadership, governed by a standing Technical Committee, and codified by the designated technical steward.
Technical committee members document and prioritize prospective changes to HSDS and help the technical stewards maintain a backlog of issues for further discussion. Committee members attend regular, open meetings with the Lead Organizer and Technical Steward where updates to HSDS are discussed. They also participate in discussion on the Open Referral Forums and HSDS Github repositories.
The committee consists of people with a track record of contributing input to the HSDS development process, and who are committed to upholding Open Referral’s mission, values, and principles.
The committee also can advise Open Referral’s Lead Organizer on issues related to the Open Referral community at large, and can make recommendations as to investments in development of tools and other tech that can support adoption and use of HSDS.
As of Spring 2024, the Open Referral Technical Committee is in formation
Upon formation of this body, the body will manage itself – beginning by writing a charter that establishes: how people are added/removed, how decisions will be made, how the body can be dissolved, etc. This can be authored by the founding members and reviewed by the technical steward, and must be approved by the lead organizer and fiscal sponsor.
The process for requesting changes to HSDS is open to anyone.
Input on Open Referral’s specifications and materials can be shared through several channels: our Github queue, our Community Forum, and occasional community Assemblies. The Technical Steward is responsible for receiving and synthesizing such input from across channels for review by the Technical Committee. The Technical Committee members are empowered to propose specific changes to the specifications; proposed changes that are met with rough consensus (i.e. most support and nobody objects) are acknowledged in the Forum advanced to the Technical Steward for codification. Upon receiving all outputs from the Technical Committee, the Technical Steward develops a fully specified proposal for a version upgrade, which is shared with the community for a Request for Comment period (usually of about two weeks). The Technical Steward receives any additional input through this period, and can call for additional meetings of the Technical Committee to seek consensus on additional changes as necessary.
In any instance in which consensus cannot be reached (which has almost never happened in Open Referral’s history) the Core Leadership reserves the right to make a direct decision – documenting the nature of the disagreement, the reasons for the decision, and the criteria by which the decision can be re-evaluated in the future. Upon achieving consent from the community for a proposed upgrade, the technical steward will implement the version change in machine and human readable formats with guidance documentation.
Open Referral’s workgroups are comprised of designated community members who advise on design, implementation and governance.
Workgroups may be formed by any set of members to operate in accordance with the Initiative’s values and principles, and are empowered to make proposals subject to rough consensus of the Initiative’s community. Workgroups can consist of at least two community members who agree to collaborate on a stated objective such as the development of Open Referral’s data specifications, implementation guidance, tooling, the governance model for Open Referral itself, etc. Workgroups should include at least one Subject Matter Expert to represent users’ needs, and at least one Lead Facilitator to be accountable for coordinating activities including setting agendas and taking detailed notes – all of which is expected to be reported on in our regular Assemblies (see below) and/or shared in Open Referral’s community forum with appropriate notice. Additional Workgroup members can be nominated by the community (including self-nominations by community members) and/or invited by core team members.
Workgroups should demonstrate that aspects of any proposal put forth are directly informed by perspectives and interests expressed by representatives of Open Referral’s primary beneficiary groups – and are expected to field and respond accordingly to any such feedback received externally. In instances where rough consensus cannot be attained, even after parties have put forth and evaluated alternative proposals and feedback from lead stakeholders of pilot projects has been solicited, Core Team leads reserve the right to make decisions (and will appropriately document the rationale for decisions and ensure the result of those decisions are subject to subsequent evaluation and possible revision).
The Open Referral network is convened in our Forum, Community Assemblies, and Network Summits
In semi-regular meetings open to all members of the community, we facilitate alignment around the mission of the Initiative. At semi-regular Assemblies, all are welcome to discuss issues of interest to the community as a whole. Anyone can join the Forum and request to be added to the calendar for these meetings. Assemblies are recorded and viewable here.
We host quasi-annual Summits (longer open meetings) in which we convene to share, learn, deliberate, and generate proposals. Summits are not decision-making events, but are critical opportunities for sharing knowledge, building relationships, and setting the agenda for future development. These events can generate and prioritize “user stories,” feature backlogs, and possible courses of action to meet the needs expressed by those user stories. (See this report back from the inaugural workshop.)
Local pilots implement data exchanges, evaluate our specifications, and contribute input to set our priorities for the future.
Open Referral focuses much of our work in local pilot projects. In pilots, project stakeholders collaborate to promote access to up-to-date resource directory data in their communities, by using Open Referral’s data exchange specifications to share resource directory data among existing and/or emerging systems. In return, stakeholders can receive facilitation, technical solutions and support, and other kinds of capacity-building when possible, helpful, and appropriate. Feedback from such stakeholders shapes the ongoing evolution of Open Referral.
Pilot projects’ objectives include short-term demonstrations of the value of open and interoperable resource directory systems, and strategic plans for long-term sustainability of such systems. Local pilot projects should consist of teams anchored around leadstakeholders (see below) who will be represented by some leadership structure (a ‘table’ or ‘committee,’ etc) – and ideally supported by some core coordinating capacity of their own (sometimes called a ‘backbone’ as in the Collective Impact coalition model). Pilot projects might also be supported by partners, i.e., organizations that provide material support, technical assistance and/or other in-kind resources – such as philanthropic funders, contracting agencies, civic technology networks, software vendors, etc., who can help with implementation, if not decision-making.
Stakeholders include any intended beneficiary of Open Referral’s work
As described by our User Personas documentation, these broad types of beneficiary user groups consist of: help-seekers, help providers, data administrators, and data analysts.)
Practically, most stakeholder groups are represented in Open Referral by the organizations that serve them (service/referral providers, technology vendors).
Lead stakeholders are voluntary representatives of specific stakeholder groups who commit to the design, implementation, and/or evaluation of Open Referral’s protocols and products through resource data exchanges and associated projects – typically in the context of pilot projects.
Lead stakeholders’ input is prioritized through all phases of Open Referral’s activities; in instances when Open Referral needs more insight to make a decision, we engage with lead stakeholders to solicit relevant feedback from their stakeholder communities.
- Return to the Organizational Overview here.
- Join Open Referral’s community forum here.