P2P Models Handbook
What is P2P Models
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.
Some initial words
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 work1:
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.
1 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
Ostrom’s Principle 1: Resources are clearly defined
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 research2.
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 versa3. We are a small team and we like to have fun together but also to get things done.
Roles in the project
While the spirit of cooperation prevails and many tasks are performed simultaneously, there are roles that address specific tasks. We are a team with diverse backgrounds and roles, and we always try to combine social research and free/libre technologies to foster social and economic justice4. From our point of view, working horizontally has to do with a transparent way of doing things and with flat decision-making. During our first months, we organized ourselves in a less structured manner, resulting in a lack of efficiency and some bad feelings. That’s why we have been refining the model and implementing specific roles.
Samer Hassan is P2P Models’ Principal Investigator. Activist and researcher, Faculty Associate at the Berkman Klein Center for Internet & Society (Harvard University) and Associate Professor at the Universidad Complutense de Madrid (Spain).
He has the role of strategic decision making with the rest of the team, maintaining the big picture of the project, holding meetings with advisors and seeking out new horizons and sources of funding in order to give continuity to the research. You can ask him about everything, but especially if you have concerns about what path to take in terms of research. He is not present in day-to-day work or decisions. Nevertheless he does not necessarily have the last word. If someone disagrees with him, the debate can be taken to our quarterly strategic meetings.
The Computer Science area is very important for technical projects. It leads the decisions on which type of technology to use or implement and continues feeding both the github and documentation associated with any prototypes. They also write research articles about the technology and discoveries we are making.
The Administration area is responsible for carrying out all actions needed to cover administrative requirements for bureaucratic processes related to P2P Models operations. Specifically, this area is responsible for management related to the purchase of equipment, travel, contracting services, hiring of new team members, project justification and deliverables, expense management, audits, technical and financial monitoring of the project, supporting the PI in the preparation of reports, budget monitoring, support in organizing workshops, etc. The rest of the team will be in charge of facilitating this area’s work and managing their own personal affairs (leave, individual contracts, collection, organization and maintenance of documentation in Drive – yes, we use Drive – vacations, maintenance of their devices and work material, etc.). When there is a need to look for stable or occasional staff, the area in need will be responsible for the whole process.
We give a lot of importance to Communication and dissemination. This area is in charge of disseminating ideas and of determining what information should or should not be communicated. It is also in charge of helping the team with the general promotion of blog posts and organization of their content. The rest of the team is also responsible for facilitating the work of the communication area5.
Design is a very important branch of our research. We know that many times technological projects don’t give much importance to design methodologies and processes or the user experience. The designer is responsible for acting as a bridge between sociological and the technical aspects, on the one hand contributing to the sociological analysis and, on the other hand, adding value to the technological side of things. They will have to validate the technical aspects of the front end and conduct user testing and will also be responsible for organizing co-creation dynamics among the community’s stakeholders.
The Social Research area is responsible for designing, collecting, generating and analyzing empirical data concerning the communities selected as P2P Models case studies. This data is intended to inform the development of prototypes, but also to be employed in contributing to scientific literature in the form of journal articles, as well as other forms of dissemination, e.g. blog posts. In short, the social researcher involved acts as a liaison for each case study. They are the person responsible for sustaining relationships and coordinating interactions between P2PModels and key community informants.
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.
Newcomers and project exits
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.
Stability in the project
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
Ostrom’s Principle 2: Collective-choice arrangements that allow most resource appropriators to participate in the decision-making process
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.
Meetings & Organization
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:
Every day, the first thing we do is to log in to Slack, tell everyone what we are going to do with our day and manage regular conversations with the team.
(The whole team except the PI) We like to start with a round about how we’re feeling, talk about how our work is going and decide how to deal with pending issues. We then address outstanding weekly issues and make an action plan for how each one will be completed for the following week by the assigned person.
Frequent Case Study Meetings:
We follow up on weekly case study work, sharing the progress we have made individually and determining objectives, milestones and next steps.
Quarterly Strategic Meetings:
The whole team plus the PI discuss the next strategic steps within the project, following mid-term objectives.
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 succeed6. 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 🤫
Ostrom’s Principle 3: Regular monitoring of users and resource conditions
Working according to our objectives helps us to focus on our daily work. Although it is not easy, we are getting better and better. We set quarterly goals that we review at strategic meetings. With this analysis we get a clearer picture of what we should focus on and if we have met our expectations. Long term objectives can be found in our whitepaper (as working packages).
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. 😌
Ostrom’s Principle 5: Conflict resolution mechanisms
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.
Ostrom’s Principle 6: Congruence between benefits and costs
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.
Holidays, leaves, care and personal work-life balance
For holidays, we observe the following days:
- Summer vacation: 30 calendar days (preferably in August)
- Easter week
- Christmas: 2 weeks
- Bank holidays
- 5 days for personal affairs (construction work at home, care of human or animal family members, etc.). These should be marked in the collective calendar and notified to the rest of the team.
Note that sick leave days are not included here. The number of sick leave days is unlimited, as long as they are certified by a public health professional.
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.
Coverage of expenses
As mentioned above, there is an annual budget of €1000/person, non-accumulative.
Hackathons are included in training.
Stable freelance members of the team can also have a budget for training.
Talks and broadcasts
Each person (internal or external) can invite one person to give a talk at the university.
Travel expenses, per diem and remuneration are included.
An attempt will be made to pay through the department if possible. Otherwise, payment will occur through previously arranged means.
Colleagues may transfer invites to each other (if you do not use your chance to invite someone to speak, you may pass it on to someone else).
The issue of any travel expenses is raised at the general meeting, and we estimate the cost, number of days and reason.
Depending on the reason, the assembly decides whether or not it will enter into the project.
The normal rule is that only one person attends, but if there are more people that want to attend, it will be brought up in the weekly meeting.
These are covered, but they are also brought up in weekly meetings. We try to be careful with the distribution of doctoral stays among members of the project. Boundaries will be set, but details are still to be decided.
Small expenses generated by the members of the team (taxi, mail or courier services, snacks if there were face-to-face meetings) are covered by the project.
We love science, but also free time, so we try to be aware of time and make the most of it7. 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
Ostrom’s Principle 8: Organization in the form of multiple layers of nested enterprises
Being a part of the university has certain advantages and privileges, but as you surely know, with great power comes great responsibility8. For this reason, all members of the project are invited to participate in academic life.
Participation in daily university tasks
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.
English Bachelor/Master theses
are useful for the project. If you are interested in writing one, great! We encourage you to do it. They will have to focus on topics related to the project and must not disturb your commitment to and daily work for P2P Models.
are one of the most important deliverables of P2P Models. They will be included in the list of project publications and, once finished, will be uploaded to the university’s preprint service. We would also like you to credit anyone who has helped in order to give visibility to everyone involved (illustrations, figures, graphics, feedback, etc.).
We also like to disseminate articles in order to reach different audiences. To this end, all team members will write blog posts about their different areas of knowledge or other topics related to the project. We will also take the opportunity to say thank you to the whole team, including those who do a lot of invisible work (management), without which you would not be able to spend your time writing quietly. 😉
GRASIA’s agreed responsibilities
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.
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.
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 vulnerable9. 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.
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?”).
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).
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.
Collaboration with other projects
On the other hand, we collaborate and work with other researchers and projects as well.
Decentralized science. This is a spin off of P2P Models. It is a project that uses emerging distributed technologies such as Blockchain and IPFS and proposes a decentralized publication system for open science. The proposed system provides (1) a distributed reviewer reputation system, (2) an Open Access by-design infrastructure and (3) transparent governance processes. Decentralized science works autonomously and also attracts its own funds, but at the same time, it coordinates every few months with P2P Models to work on papers and grants.
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