P2P Models is a large research project focused on building new types of Collaborative Economy organizations, which are decentralized, democratic, and economically sustainable, harnessing the potentials of blockchain and other decentralized technologies. 

We combine social research and free/libre/open source (FLOSS) technologies to foster social and economic justice. Our challenge is to co-create inclusive decentralized tools and theories. We are a multidisciplinary team, made up of a mixture of professionals and academics from different areas such as sociology, computer science, communication and design.

Among our spiritual guides we can highlight Yochai Benkler, who is a pioneer in the study of Commons-Based Peer Production and the person who coined the term. The values and practices of Commons-Based Peer Production inspire our day-to-day work and the way in which we frame our research, Elinor Ostrom, with her theory for managing the Commons, and Coraline Ada Ehmke, not only for her support of free/open source software but also for her Post-Meritocracy Manifesto and her Code of Conduct for free/open source projects. With these two geniuses in mind, we try to govern ourselves in a horizontal, post-meritocratic and feminist way. Of course, we don’t always succeed, but we constantly revise our approach to team management and try to do our best. 

As for our approach to the commons, we try to apply Ostrom’s principles to our daily work. Since we started in 2018, we have significantly changed our way of working, discarding some things and incorporating others in order to move on to new accomplishments. It has been, and continues to be, a difficult journey, but in the end we are quite proud of how we do things. 

Regarding our approach to software, we are an active part of the FLOSS community. Of course, all our developments and pilots are open-licensed and publicly available (in Github) so that they may be shared, modified and adapted. We also invest plenty of effort into explaining what we do in our blog in order to reach non-techie audiences. 

This handbook is a first draft where we present our principles and way of working. It is a guide to help us rethink and focus on how we work, and at the same time, it clarifies and reduces uncertainties to newcomers. We would also love to be able to use this document to help other groups that are trying to run in a more non-hierarchical and decentralized way. After all, nobody ever said it would be easy.

As a project and as a team, we have a set of values that we apply to our daily work¹: 

As fans of the commons, we have created a handbook that follows the same structure as Ostrom’s management principles (listed for instance in our groundbreaking Ostrom & Blockchain paper). We have also included, in footnotes, Post-Meritocracy Manifesto principles in this document. If you would like to get to know us better, keep reading and the next few pages will give you a taste of what it’s like to work with us.

¹ Post-Meritocracy Manifesto. Principle #12. We strive to reflect our values in everything that we do. We recognize that values that are espoused but not practiced are not values at all

In such a small team, we consider our primary resources to be our heads, hearts and hands, i.e. the people that make up the team. Of course we also have material assets, such as computers and money. In P2P Models we believe in collective decision making, collective and individual responsibility, group capacities and self-organization. We also try to avoid micromanagement. If you are a newcomer or junior, of course you will be helped, supervised and mentored by someone with more experience, but we also expect you to be proactive in order to facilitate shared work.

Sorry, we are in pandemic and we don’t have a better team photo

We are organized by areas of expertise and case study research. For each case study there is one person in charge, and the areas of expertise are: Social Research, Development, Communication and Management and Design. Being a highly multidisciplinary project, many times we have to understand a little bit of everything.

We embrace all areas as equally important, and although we are a tech project, we don’t believe that technology is more important than social research².

Each working group is self-organized and has the power to decide the methodology and technology to use in that particular case study. The team is responsible for the progress of the case study and day-to-day workflow. The decisions around each case study will be made within the team, understanding that they have more information and are better qualified. If there are decisions concerning external budgets or money that needs to be allocated to each case, they will be taken to the weekly work meeting. We haven’t yet established criteria for the allocation of extra resources. For now such decisions are made collectively and case by case. 

The well-being of the team means that sometimes we have to think about the common good while making sure that everyone feels comfortable with each other. We think that the global well-being favors the individual and vice versa³.  We are a small team and we like to have fun together but also to get things done.

Sometimes we need to contact other professionals for help in improving some aspects of the project. They may be used occasionally or on an on-going basis, and the established rates are: €20/hour for stable and €30/hour for occasional collaborations. 

We know that getting in and out of an ongoing project is not easy. When a newcomer arrives, we provide her/him with a godmother who helps the person in all new project matters: signing up for the tools, getting a laptop and other devices, moving between sites and shared workplaces, etc. in order to make the onboarding process easier.

If someone, for whatever reason, wishes to abandon the project, we would like to be notified at least one month in advance. On the agreed date that the contract ends, we need all materials provided by the project (such as computers or hard drives) to be returned as they belong to the university, not to us. It is the user’s responsibility to return the materials in good condition.

The project needs stability in order to have robust results and impact. 

In addition, the culture we are trying to create implies a high level of involvement and collaboration between team members. If people frequently join or leave the project, it generates instability, problems, delays, and general discomfort. Therefore, we would like to ask for a long-term commitment to the project, on both sides. This means:

• The project assures you a contract of one year, and, in return, you assure that you are not going to leave the project for the same period of time. After one year, this agreement will be reviewed. 
• Unexpected situations may arise. We would like to be able to solve them within the scope of the project. For example, if for personal reasons it is necessary for you to move to another country for a while, the project may allow you to work remotely. These decisions are made according to personal needs and the project’s needs.
• If a person leaves the project, we would like to receive notice at least one month in advance (not counting summer vacations) so that we can plan accordingly, open a position and find a replacement, allowing for an acceptable transition period. UCM is an old institution with very slow and tricky bureaucracy, meaning that it takes time to integrate newcomers.
• If you leave the team on good terms and respecting these conditions, the PI and other members of the group can help you to find another job and make new contacts, or write recommendation letters that will help you find your dream job.

We are quite strict about commitment. Stability is important for the project, and the added stress of bureaucracy can just end up making things difficult. 😅 It takes so much time and work to open up a new position. All this bureaucracy is exhausting and thankless work, but it’s something that we have to deal with – not because of our own structure, but because of the university. If we could, we would eliminate it from our daily life. After all, research is what we really love doing.

Our workplace can be considered as a resource as well. We like people – meeting with them, having a coffee, getting personal and talking more informally about our projects, forming networks and personal relationships. P2P Models has a physical space in the Department of Computer Science at the Universidad Complutense de Madrid (office no. 409). We try to meet at the department at least two or three days per week and work remotely or in the office the rest of the time (you will always have a desk and a chair). 

As we write this, we are in the midst of the second wave of COVID-19, with Madrid being one of the cities most affected by the pandemic in Spain. We have been working exclusively online since March 2020, adapting all of our teamwork dynamics to this new and unusual normality.

2. Post-Meritocracy Manifesto. Principle #11. The field of software development embraces technical change, and is made better by also accepting social change

3. Post-Meritocracy Manifesto. Principle 2. We believe that interpersonal skills are at least as important as technical skills

4.  Post-Meritocracy Manifesto. Principle 3. We can add the most value as professionals by drawing on the diversity of our identities, backgrounds, experiences, and perspectives. Homogeneity is an antipattern

5. Post-Meritocracy Manifesto. Principle 8. We acknowledge the value of all contributors as equal to the value of contributors who are engineers

Since starting in 2018 we are continuously trying to improve and move towards horizontal decision-making. We began with very loose rules, and it didn’t work. We thought that the best way to work together would be to rely on the common sense of our team members, but we learned that common sense is the least common of the senses. Instead of applying the principles of commons management, we were applying the tyranny of structurelessness. Conflicts appeared, as did uneasiness within the group. 

Since governance is a topic that we love, we have researched and learned a lot. We have made mistakes, laughed, and sometimes gotten angry. In all the communities we have studied since P2PValue, there are people involved to varying degrees (1-9-90 Theory) and invisible power dynamics, so it is good to be able to detect them. 

In order to break with these bad dynamics, we established work flows and responsibilities (see above), and we had a meeting resulting in this handbook. Important decisions in P2PModels are made in a weekly assembly by trying to reach the most complete consensus possible. In these meetings, we discuss the general state of the project and establish working groups for case studies or specific tasks. We give decision-making power to these small groups, trying to make sure that each person is heard and that decisions are reached, to the extent possible, by consensus, empowering the whole team. Strategic decisions are made with the help of the Principal Investigator.

Although we tried to follow principles of Agile Methodology and made use of bi-weekly objective meetings. However, it did not work for us because, being a highly interdisciplinary team, we found that what is useful for technology, was not so useful for social research or paper writing. Therefore, the mixed method tools that are currently working for us are:

We try to limit meetings and make them short, effective and direct, not lasting more than 1–1.5 hours. If we can solve something asynchronously, let’s do it that way! Remember:

As good internet geeks and product makers, we like to browse and continually bring new proposals to the table. We try to give priority to free software, but we don’t always succeed⁶. After much debate and experimentation with different tools, we finally settled on these, at least for the moment. Does it seem like we use a lot of tools? Well yes, we do. 😅

• Daily communication: Slack
• Weekly planning and follow-up tasks: Trello
• To communicate with the PI: Email, Telegram
• To work on, comment on and save documents without confidential information: Drive
• To schedule meetings and other events: Google Calendar
• Online calls: Whereby. Sometimes, we use Jitsi too.
• Asynchronous decision making: Loomio
• Publications and outreach: our own Blog and Medium and scientific publications
• To socialize or for off-topic issues: Telegram groups
• Social analysis (CAQDAS): NVIVO
• Code repository: Github
• Bibliographic references in papers: Zotero 
• To manage job offers: ODOO
• Design prototypes: invision

6. Post-Meritocracy Manifesto. Principle 10. We are devoted to practicing compassion and not contempt. We refuse to belittle other people because of their choices of tools, techniques, or languages – in this case, we apply this principle to ourselves. We practice compassion with ourselves when we use Drive 🤫

Recently, we have also established revisable personal goals together with the PI with the intention of nurturing the personal career of each team member, as well as ensuring the completion of their work within the project. Case study goals help simplify our long term objectives, transforming these objectives into actions to be carried out.

We like to be proud of our work, as a team and as individuals. In the near future, we would like to work on an open document that can determine our “Definition of Pride” around different variables: academic and social impact, quality in our different branches of development (UX, writing clean code, standards, methodologies, etc.), but this is a huge task that we will address on another occasion. 😌

In every group of people there are conflicts; this is natural and inevitable. There are always misunderstandings, tensions, or discomforts, which if not managed, become more drawn out, entrenched, and frequent. 

Therefore, if you have a conflict with someone about something, and for whatever reason the situation is becoming uncomfortable and difficult to manage, we ask you to bring it either to the regular team meeting or to the Principal Investigator (PI) (whichever is more comfortable) to see how to solve and/or alleviate it as much as possible. We need to discuss and define a more clear process for this.

We understand the project as a common good that, on one hand, aspires to contribute results and literature to the scientific community and, on the other hand, provides team members with knowledge, personal wealth and livelihood. Therefore, we try to be careful with the common resources that we have. These resources include money, of course, but also other material goods such as computers or devices and intangible goods such as time and personal work-life balance.

You can check the UCM work calendar here.

We try to offer good salary conditions, especially compared to the academic world in Spain. We have established a salary for juniors and another for seniors, trying to make them equal in order to eliminate salary gaps along lines of gender or technology. Salaries are transparent and known by every person of the team.

We also provide a series of benefits to those hired, including technical equipment such as laptops, courses and trainings, work trips, conferences, books, long research stays, etc., with all related expenses paid. In the case of trips, we typically end up paying more than the expenses incurred.

We love science, but also free time, so we try to be aware of time and make the most of it⁷. We are governed by the Estatuto de los Trabajadores in which our working day is agreed upon, but we prioritize flexibility and care more about results than hours worked. 

Thanks to the university agreement, our working schedule is not 40 hours a week, but 37.5, thus favoring a better work-life balance (yes, we know it is not enough, but it’s something). Nevertheless, we are goal-oriented and don’t support working overtime hours. Our goals are achievable under normal conditions. 

People in the team can choose their own working hours as long as you keep a consistent schedule in the mornings (between approximately 10:00 and 14:00), being available to work as a team or to address someone’s concerns regarding our daily work through Slack or Telegram. The rest of the time you may distribute your schedule as you wish, adapting it to your own needs. Obviously, there will be many exceptions to your daily routine, you just have to keep your team up to date. 

We are a goal-oriented team, and we allow each person to manage their own time. At the same time, you are expected to complete your regular and daily work, respecting deadlines and following the line of research and agreed objectives. 

You can check out the UCM work calendar and holidays here.

As mentioned above, research support staff is governed by the Estatuto de los Trabajadores, but you should consult with the section on Department Staff to make sure. 

• Summer vacation: 30 calendar days (preferably between July 15th and August 31st)
• Easter: 1 week
• Christmas (Department closing time): 2 weeks
• Personal days: 5 days
• Moving: 1 day
• You can take days off to care for human and non-human relatives 🐶🐱🐼. No justification is needed, but you must inform the team.
• Private matters or doctor’s appointments: As long as you give your team advance notice, there is no problem with taking a couple of hours off any day for something important (e.g., a doctor’s appointment for you or your child, a boiler check, etc.), and making them up at another time
• Outside of the summer season, you may take days off as you wish, but you must inform the team in advance.
• Teleworking: As we have been working exclusively online since March 2020, we think that the team should be available on Slack during working hours to facilitate online work.
• We firmly believe that physical presence in the workplace is not essential to carry out our work. However, we also understand that in the current pandemic circumstances, each team member may want to have a space where they can concentrate. Therefore, it is easiest for everyone to have access to the office in a way that presents the least possible risk. 
• We have agreed on a COVID-safe seating chart so that only a few team members will be in the office at the same time (3 people maximum). This seating chart is updated regularly.

7. Post-Meritocracy Manifesto. Principle 4. We can be successful while leading rich, full lives. Our success and value is not dependent on exerting all of our energy on contributing to software – or any other task, if you are not a software developer

Being a part of the university has certain advantages and privileges, but as you surely know, with great power comes great responsibility⁸. For this reason, all members of the project are invited to participate in academic life.

PostDoc team members have the option of teaching within the department to enhance their academic curriculum. Teaching is compatible with the project, although the time (percentage) dedicated to the project must be specified. 

P2P Models is a part of GRASIA, a Research Group on Agent-Based, Social and Interdisciplinary Applications. GRASIA has a welcome kit for people who are just starting out in order to make things easier for newcomers and for the rest of the teams.

As a member of the GRASIA research group, we have a series of duties that must be fulfilled.

Regular and daily work:

We do not control schedules or hours clocked in, and we allow each person to self-manage their own time as they see fit. At the same time, regular and daily work is expected, following the appropriate line of research and agreed objectives. 

Quality work:

Any work done is expected to meet high quality standards. In order to do so, each person is expected to try to do his or her job as well as possible at all times (not to do it just to see if it’s a good fit). Of course, this may require support and validation or review of their work by more senior members.

Professional ethics:

As a group we work with a focus on values and ethics, in a way that intersects with our work and other activities. This implies being aware of the consequences of our actions with third parties, especially with partners and not to promote or consent to discrimination against groups or partners, especially those most vulnerable⁹. This is also applicable when thinking about our work and how a new software development may harm or discriminate against more vulnerable people (e.g., respecting accessibility criteria).

Maintenance, facilitation and invisible tasks:

There are tasks that arise in daily work that are not included in our main tasks, but that facilitate our work and coexistence. For example, reserving a room for the next day, writing an email to a collaborator, correcting something on the group’s website or solving a bureaucratic problem. There are also other tasks that are not obligatory but make our day-to-day life more pleasant, such as remembering other people’s birthdays, maintaining an orderly space, welcoming a new person or providing emotional support in a moment of depression or despair. These tasks are usually considered “small” (they may take little time and/or are given little importance), “invisible” (they are not given recognition or visibility), “individualized” (they depend on individual initiative, on who “feels like” doing them), and often “feminized” (they fall to women and people trained in care). It is expected that all people participate in such tasks, and that group arrangements are made so that it is not always the same people who perform them.

Management of expectations:

Projects and, above all, those who are in charge of managing them (IPs and project managers) are organized around medium-term planning, agreed upon with the researchers. Each person is expected to comply with any plans and agreements, and if there is any reason that something will not get done, it is to be reported as soon as possible.

Autonomy:

A high degree of autonomy is expected in the daily work of each person. They should be able to self-manage their daily tasks and take into account that the more junior or new members will need more support at the beginning. This autonomy does not imply radical individualism; that is to say, it is expected that the group be respected and cared for and that the group be aware of how its own decisions affect agreements, planning and other collaborators.

Limits to autonomy and individual initiatives:

Flexibility is given to be able to seek out training (e.g. do a master’s degree or other courses) or to take trips and spend time abroad. At the same time, these initiatives should not significantly impair or diminish the time dedicated to one’s own work, their agreed upon responsibilities, or the collective work of other group members. Therefore, in such cases, efforts will be made to facilitate and take care of shared work, trying to make the negative impact as small as possible and not only thinking about one’s own interest (“How do I justify what I want to do?”) but also about the common good (“How can I make it affect the others as little as possible?”). 

Results:

Our group is part of a public university, and our funding is mostly public (either national or European). According to this framework, and with some exceptions, any product of our work must be shared publicly with free licenses as a contribution to the commons (e.g. free software in Github repositories). Of course, the authorship of those who have contributed will be respected, and issues of consent or privacy will be addressed before releasing any results (e.g. in the case of interviews). 

English:

Our group has international relevance and a wide international network of collaborators. Therefore, to facilitate collaboration with people from other cultures and maximize the impact of our work, the vast majority of our work is expected to be in English (e.g. programming, documentation, articles). Each person is expected to progressively improve their English language skills in order to produce high quality content. If funding is available, the group can finance English courses for those who need them.

Group activities and meetings:

Each person is expected to attend, to the best of their ability, group activities such as coordination meetings, workshops or organized workshops. Participation implies active listening and engagement with respect for everyone present and without “taking up space” or monopolizing speaking time. At the same time, all are encouraged to express their opinions, either to support an idea or to express disagreement.

Duties in the Department:

The ISIA Department allows us to enjoy its facilities, resources and staff. In return, the staff is expected to take a ~2 hour exam every quarter. Furthermore, it is also expected that there will be no abuse in the consumption or care of common resources, such as stationery, photocopiers, furniture, etc. It is also expected that bureaucratic processes involving the department are done in a timely manner, such as when requesting travel permits before traveling or preparing reports for scholarships or other calls. Those responsible for teaching are expected to respect the rules of the department and work in a professional and responsible way with the teachers of the subject in which they collaborate as well as the students. In general, the department’s management is very open and friendly and works actively to facilitate our work. Therefore, it is expected that if problems arise, they are communicated as soon as possible, working together to solve them and always assuming good faith from the other party. 

On the other hand, we collaborate and work with other researchers and projects as well.

8. Post-Meritocracy Manifesto. Principle 5. We have the obligation to use our positions of privilege, however tenuous, to improve the lives of others

9. Post-Meritocracy Manifesto. Principle 7. We have an ethical responsibility to refuse to work on software that will negatively impact the well-being of other people