In June 2020, we had the opportunity to join a discussion on open contracting and inclusion organised by HIVOS. Participants shared their thoughts on a newly published paper by Michael Canares and Francois van Schalkwyk that is part of a set of research papers supported by Hivos at the intersection of public procurement, inclusion and participation. ILDA have just published one article about inclusion in Latin America and will soon publish another one on open contracting and participation in the same region. This blog post is a reflection inspired by that conversation.(*)
Open data standards are political, yet they are built in technical spaces devoid of political or social implications. Often what gets prioritized in their design is technical interoperability, not human understanding. Sometimes we focus so much on building the technology that we forget to focus on power and to address the new power dynamics formed. Even if we try to contain it to technical spaces, standardization is more than a technical process. It is an exercise that enables data production and use to be reconsidered. Standards are not only shaping how data is produced but are also bringing about silent, localised changes in bureaucracies (**). Therefore, it is important for us to not only understand how powerful open data standards can be in creating changes, but to also address some of the challenges that are part of their design and implementation.(***)
One major challenge is the harms biases can bring when designing an open data standard (****). Biases are multi-layered and manifest in different ways. We carry our own biases and experience them in our daily lives. They can be about gender, race, age, and class, among others, and result in different types of discrimination. For example, biases manifest in how design processes are shaped. Open data standards is a field with territories like many others. A woman might be able to become a gender expert in an organization because she is a woman. She will not, however, be given the same opportunity to advance in a technical role such as standards. That requires domain expertise, which is argued to be different.
For some of us who have witnessed how standards are shaped, we have seen that standard-setting is a political exercise, where each participant does not only carry a set of biases, but also interests, oftentimes conditioned by the organizations that they represent. Who speaks the loudest among those sitted in a workshop room, are the ones who get heard. In some cases, hearing a particular voice and considering it is dependent on what the owner of that voice is bringing. Does he/she/they bring with them financial resources? Did his/her/their organization fund the standards workshop? Or does his/her/their organization represent a coalition of important actors on which the application of the standards and its potential success is dependent on? The imbalance in power structures often hinder a free exchange of ideas and the role of facilitators in breaking notions of power and powerlessness among the different participants is crucial.
The demographic of open data standards designers was and still is for the most part male, white and from the global North. Even though open data standards designers have invited various people to participate in the design process, we wonder: How were they invited to be a part of the process? What is their role(s) in the design process? Was their participation a last minute add on? If marginalized groups and underrepresented sectors are invited to these discussions, is the intention really to include their views or just to fulfil inclusion statistics? When we look at diversity and representation in numbers, things appear to look inclusive at conferences, workshops, and events. But, in many cases, designing open data standards happens behind closed doors. There is no panel. Possibly a workshop – but who gets invited? Who actually joins? And whose voice gets heard and included? How participatory are these exercises? Who is at the table when no one is there to take a picture?
It is easy for open data standards to remain the same when the design process happens behind closed doors. Even if there are well-intentioned motives for opening up standards, the group that created this movement was and still is homogenous. However, given the power of standards, it is no longer acceptable to discuss or design standards with just one single voice, no matter whose voice it is. We caution away from walking the fine line between being truly included and being included as a token in a technical conversation about standards. For this reason, we need to resist sexism, racism, and colonialism in its many forms. Women should not be the only ones to talk about gender. People of colour should not be the only ones to talk about race. People from the global South should not be confined to a global South perspective. When designing open data standards, we need all voices possible at the table to provide their expertise – technical and beyond – to be heard and listened to.
We propose three dimensions for inclusive-by-design framework, an invitation to a conversation:
By including multiple perspectives in the design process
When designing standards or any other tool, every decision has the potential to include or exclude people and social groups. These decisions should be taken into consideration at the beginning of these design processes and not as a desirable aftermath which is not calculated in advance. This diversity of opinions and worldviews have to be included not just as a consultation over the final product but understanding that these voices should be part of the creative process.
Despite this need to include as many voices as possible, we are mindful that it is not feasible to include all voices. Therefore we must strive to include as many views as possible that are relevant to the exercise and take a conscious decision since the very start of the project. In this sense, the basic questions that need to be answered:
- Who is at the table? – while it is impossible to consider and invite all, there has to be rationalization of who needs to be there. Moreover, there is also a need to be explicit and transparent about who makes these decisions and why.
- What are the roles of people in the standard setting process – will everyone get a stake, how are their inputs considered?
- How do we involve as many perspectives as possible – will there be feedback loops? How is consultation conducted with those outside the people sitting on the workshop table? What is the criteria for making the final technical decisions?
- What are the needs identified by the people, the constituencies they represent, and the expanded community of experts who participated in workshops and events?
By considering multiple users, their contexts, and their different needs in standard setting
Because standards affect different countries, governments, and entities, standard-setters need to take into account how standards will impact on varying implementation experiences, costs of compliance, and contextual challenges faced by these countries. Data standards developed in the past, seem to be that data structures, management systems of countries are significantly different, even enabling legislation. For example, existing legal frameworks and practices from the open data standard created to record femicides in Latin America differ from one country to another (Fumega, Scrollini and Rodríguez, 2017). This raises several questions:
- Whose legal standard, whose technical standards are we talking about here? What do we do with differences in legal regimes and differences in technical capabilities?
- How do we factor differences in contexts into the standards we are proposing? How do we balance universality with contextuality?
- How do we standardize methodologies?
By being explicit about roles and relationships during implementation
To ensure sustainability throughout the standard process, we recommend a feedback loop before and after its implementation in an agile way. This cannot be achieved without appointing clear roles and relationships. Clear frameworks are also necessary to understand and support the role each actor is expected to play. This includes an awareness, introspection, and analysis of the worldviews that those designing the standard bring. We need to take into account how the standard will impact the varying implementation experiences, costs of compliance, and contextual challenges brought about by the overall ecosystem of the entity it is being built on. Therefore, it is important to know:
- What are the expectations?
- What are the roles and responsibilities for each of the actors involved?
- What are the incentives for each actor?
- What are the available resources?
These are some of the questions that need to be answered. So are we all in the picture? The short answer is no. To be truly inclusive, the implementation of standards and their policies need to multiply voices at the very beginning of the design process to help solve problems for the many, not just a select few. In this reflection piece, we have added a few recommendations. However, similar to our call to open data standards design processes, we need as many voices as possible. Therefore we want an open conversation to try and find some answers and bring more views to this field. Do you want to join us?
(*) We would like to thank Jorge Florez for his valuable comments on a draft of this blogpost.
(**) See Fumega, Scrollini and Rodríguez (2017). Brief English version: http://www.gencat.cat/eapc/epum/N7/pdf/EPuM7Fumega.pdf
(***) We note the limitations of this field. We need to first start with more inclusion in the group of people that this topic is relevant for.
(****) Bias is an interference based on a prejudice or a preconceived idea due to a specific worldview.
Originally published at https://idatosabiertos.org.
