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 at least a lead technical steward to serve in the Core Team. The current technical steward is the Open Data Services Cooperative.
The Human Service Data Specifications are developed through transparent, consensus-based cycles that are facilitated by Open Referral’s core leadership and implemented by the designated technical steward.
When we have both sufficient need and resources to update the Human Service Data Specifications (roughly every couple of years), the Core Leadership announces a development cycle, initiates formation of a Technical Working Group, and elicits input from the community to set the agenda. These inputs can be shared through several channels: our Github queue, our Community Forum, and our Technical Working Group meetings. The Technical Steward is responsible for receiving, synthesizing, and responding to such input across channels. The Technical Working Group 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 advanced to the Technical Steward for codification. Upon receiving all outputs from the Technical Working Group, 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 Working Group 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 Technical Meetings, 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. Leadership and technical implementers convene monthly at brief Technical Meetings. 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.