# About
Contributor funding could become a growing part of how Web3 ecosystems manage and disburse their treasury assets to generate impact. The following resources provide some template documents and suggestions about how an ecosystem could experiment with a contributor funding process.
# Overview
Overview of the open source contributor funding experiment
An open source contributor funding experiment is looking to explore how contributors could be funded to help with developing the most impactful open source solutions in a Web3 ecosystem. This experiment was created due to the [open source contributor funding](https://docs.contributors.org/proposal/open-source-contributors) proposal.
**Why run this experiment?**
The goal and objectives around this experiment are focused on learning as much as possible about contributor funding and the effectiveness of a number of approaches that have been suggested from our [funding process analysis](https://funding.treasuries.io/). If successful this experiment could generate a large amount of impact and become a long term solution for a Web3 ecosystem. The experiment is inexpensive to set up and operate and has been designed to generate a range of insightful data points. This data can then be used to improve future iterations of the experiment and for comparing this funding process with other funding processes across the industry.
**Who’s involved in this experiment?**
* **Contributors** - Developers from the community will submit contributor proposals to be considered as a candidate. Candidates that get selected will be funded to work on open source initiatives that are most likely to generate impact for the ecosystem.
* **Voters** - Voters will be responsible for selecting the most promising contributor candidates to work on open source initiatives. The voters could be the founding entities or the community.
* **Community members** - Anyone in the community will be invited to provide feedback and interact with the contributors and the funding operator throughout the experiment.
* **Founding entities** - The founding entities will often be responsible for approving this experiment and allocating the funding to this initiative. They will be invited to provide feedback throughout the process and might also be responsible for handling contributor payments.
* **Funding operator** - The funding operator is responsible for managing the funding process experiment and keeping everyone well informed on what is happening, what the next steps are and with answering any questions or concerns that anyone has.
**What is the experiment process?**
1. **Priority suggestions - C**ommunity members will be asked to share their suggestions about what open source initiatives they believe would be the most impactful for contributors to focus on. Community members can upvote and comment on any existing suggestions.
2. **Contributor proposal submissions -** Community members are invited to submit contributor proposals with their personal and professional information. The community is then invited to give feedback before these proposals are finalised. Contributors are also then asked to give some feedback about the proposal submission process.
3. **Voting process** - Voters select the contributor candidates that they believe will generate the most impact for the ecosystem. Voting data and results will be released to the public and then voters will be asked to give their feedback about the voting process.
4. **Contributor onboarding** - The successfully selected contributors are onboarded into the funding process and invited to join any of the chat channels that have been created for communication. The initial tasks that contributors work on will be decided and added to a contribution task board.
5. **Monthly contribution period** - Contributors begin their monthly contributions and will keep a record of their contribution outcomes in a contribution log. At the end of the month the contribution logs of each contributor are checked and verified so that they can continue to receive future payments. Contributors will continuously update their contribution tasks with any progress that has been made. Community members are invited to give feedback to the contributors about any of the tasks that are being executed.
6. **Funding process completion** - Once the funding round is completed the contributors and the community will be asked to peer review and give any feedback they have to other contributors. Voters and contributors will then be asked to give their feedback and opinions about the funding process.
**How long will it take to complete?**
The experiment can run for as long as an ecosystem wants it to, however we currently recommend either 4 or 6 months as a suitable duration. This duration helps to better ensure there is enough time for contributors to make impactful contributions whilst also being cautious about the amount of funding that is being committed to the experiment. This shorter experiment duration is also useful for making more iterative changes and improvements to the experiment for any future funding rounds.
**How much will the experiment cost?**
The funding operator costs would come to around $5,000 to $10,000 depending on the scale and duration of the experiment. The majority of the experiment costs are dependent on how many contributors an ecosystem would like to trial the experiment with and what the maximum amount is that contributors could be paid each month. This determines the maximum potential cost of the experiment. The actual cost could be lower as the selected contributors might not request the maximum amount in their proposal. The final contributor costs will be based on the cost per month of the contributors that get selected multiplied by the duration of the experiment. Some example maximum experiment costings are as follows:
* **Example 1:** 6 month duration x 3 contributors x $10,000 max per month allocation + \~$10,000 funding operator = $190,000 maximum cost
* **Example 2:** 4 month duration x 2 contributors x $10,000 max per month allocation + \~$7,500 funding operator = $87,500 maximum cost
* **Example 3:** 4 month duration x 1 contributor x $8,000 max per month allocation + \~$5,000 funding operator = $37,000 maximum cost
**How will it be determined whether the experiment was successful?**
All contributions made by contributors during this experiment will be open source. Any feedback and data collected during the funding experiment will also be open source. The funding operator will make the experiments data available and easily accessible from a GitBook resource. A report will also be included that highlights any key insights, problems, opportunities and trends that were identified from analysing the experiment data. The data and any findings can also then be compared with other funding processes across the industry.
# Objectives
The overall goal and objectives for this contributor funding experiment
The overall goal of this contributor funding experiment is to learn as much as possible about operating a contributor funding process and the potential impact that contributor funding could have for Web3 ecosystems. This initial funding experiment will focus on [open source contributor funding](https://docs.contributors.org/proposal/open-source-contributors) and will trial a number of suggestions that have emerged out of some [funding process analysis](https://funding.treasuries.io/). The objectives for this experiment are focused on generating a large amount of data to learn about how these different approaches perform in practice. The data and feedback generated by this experiment will be highly insightful for analysing the effectiveness of contributor funding and the differences it has with other funding processes across the industry. The knowledge and experience gained from this experiment will also help with identifying the most promising ideas for improving this funding process for subsequent experiments. The following objectives are data focused and are intended to help with achieving the goal of learning as much as possible about operating a contributor funding process.
**Record prioritisation suggestion data**
A prioritisation suggestion board is going to help with learning about what priorities the community thinks are important and how those priorities get addressed or change over time. A separate priority process means that suggestions can be submitted at any time and receive upvotes at any time. It will be insightful to understand how these priorities influence the efforts of the contributors and what impact this process could make for supporting a more flexible and dynamic contribution process that can respond to these suggestions. Measuring this objective:
* Priority suggestions - The priority suggestions board will be publicly available to allow any community members to make suggestions and upvote or give feedback to existing suggestions. This data can be collected and analysed at the end of the funding experiment to understand how this influenced the contribution outcomes.
* Contribution tasks - A contribution task board will be public and enable anyone in the community to see what a contributor is working on. This board will provide data about what actual contribution efforts get focussed on which can then be compared to the priorities that have been suggested. It should also be insightful to see how community members give feedback to contributors based on the tasks they are executing and the priorities which are currently being suggested and endorsed by the community.
* Contribution logs - Contribution logs will make it easier to see exactly what contribution outputs have been delivered. The aggregation of these contribution outputs can be analysed and compared with the suggested priorities to see how the community suggestions actually impacted what got executed.
**Record contributor proposal data**
The submission of contributor proposals and the selection of those proposals can provide insightful data about what information is most important and which factors were the most correlated with proposal success. This data can help with future efforts to minimise the information that is needed for voters to make well informed decisions so that the voting process can become more efficient and scalable. Measuring this objective:
* Contributor proposals submitted - All of the contributor proposals submitted should provide useful data about how different people have approached writing a contributor proposal.
* Contributor proposal submission feedback - The proposers might have valuable feedback about the submission process and provide ideas about what other information could be added.
* Voting results - The results from the voting process can help with identifying any trends in how the voters responded to each proposal based on the contents of the proposal.
* Voting process feedback - Voters may provide feedback about the information that is included in the proposals and what information they believe should be included in the future.
**Record voting data**
[Expressive approval voting](broken://spaces/qIN4B3DGHPqKOl7e6VuV/pages/ZMa02Hs0lGdjavL6AuVR) is an adaptation of approval voting that should help to increase the expressiveness of this voting process. This suggested voting system will be used in the contributor funding experiment and the voting results data can be analysed to see how people vote in practice. This data will provide more evidence about how effective this approach is and whether it should be trialled in a larger experiment. Measuring this objective:
* Voting results - Expressive approval voting will be used in this funding experiment. This voting system can be trialled using existing services and tools such as Google Form and Google Sheets. Anonymised voting data can then be released to the public for further review and analysis.
* Voting process feedback - Voters will be asked to provide their feedback about the voting process when they complete the contributor selection decision process. This should help to identify any concerns or issues that people had with the voting approach and any suggestions for improvement.
**Record contribution task board data**
A public contribution task board should provide useful insights about how contributors coordinate themselves and execute different tasks. Contribution task data should help with providing some initial ideas about what might be needed if a custom solution was going to be developed to handle the suggestion and development of ideas.
* Contribution task board - Contributions tasks will be publicly created and managed on a contribution board. This data can be reviewed during and at the end of the funding process.
* Contribution task feedback - Any community member can provide feedback to a contributor about a task they are working on. It will be insightful to see how much feedback is given to contributors and what the value and impact is of the feedback given.
**Record contribution log data**
[Individual monthly contribution logs](https://funding.treasuries.io/contributions/contribution-verification/individual-monthly-contribution-logs) represent a simple and potentially highly effective way for recording and verifying contribution efforts. Contribution log data will help with making comparisons with other contribution verification approaches used in other funding processes to see which ones are most effective. Measuring this objective:
* Contribution logs - Contributors will be required to submit their contribution logs to provide evidence of the contribution outputs they have generated in that month. All contributions can be recorded publicly as all contribution outcomes must be open source. Contribution logs will be open source and available on a code repository for anyone to collect and review.
* Contribution attestations - Community members can give attestations about someone's contribution efforts. This will provide more evidence in situations where contribution efforts are harder to digitally record and verify.
* Funding process contributor feedback - Contributors will be asked to provide their feedback about the contribution log process once they have completed the funding process. This feedback could be highly valuable in understanding how simple or complex this process was for them and what the overall sentiments are.
**Record collaboration data**
A contributor funding process could help with creating a highly collaborative environment. Contributors in most cases will have the flexibility to work on any contribution area that they believe will generate impact for the ecosystem. Contributors are not tied to a single idea and can contribute towards many ideas or they can change the idea they are working on if something more impactful presents itself. Much of the data captured in this experiment should be useful for assessing how much collaboration has occurred which can then be compared with other funding processes. Measuring this objective:
* Priority suggestions - Priority suggestions will generate valuable information about how people collaborate and discuss different suggestions and how those suggestions eventually lead to executed ideas.
* Contribution tasks - Contribution tasks will show how contributors are collaborating together and with other ecosystem projects. Contributors may also need to respond to community feedback.
* Contribution logs - Contribution logs will highlight what actually happened and what was delivered. This data will be highly insightful to see how many ideas a contributor worked on, how they collaborated with different teams and which contribution styles were the most effective.
* Contributor peer reviews & feedback - Contributors and community members could provide insightful information about the impact and relevance of certain contribution efforts and how those contributions were valuable.
**Record voter and contributor participation time data**
Data about how long it takes voters and contributors to participate in this experiment will be useful for making comparisons with other funding processes. For contributors it will be useful to know how long it takes them to write their proposal to be considered as a potential contributor. For voters it will be useful to know how long it takes them to read and select the most promising contributors during voting. Measuring this objective:
* Contributor proposal submission feedback - Contributors will be asked to keep a record of how long they spend creating their proposal. A proposal submission feedback form will then help with capturing this information.
* Voting process feedback - Voters will be asked to keep a record of how long they spent reading profiles and selecting contributors. A contributor selection process feedback form will then help with capturing this information.
* Average read and write times - Estimated read and write times can be determined by taking the total number of words there are in a contributor proposal and multiplying that by the average time it takes someone to write or read that amount of text. These values can then be compared against the average voter and contributor values provided.
**Record voter and contributor opinions and preference data**
After the funding process experiment is completed the opinions and preferences of the contributors and voters who participated can be recorded. For contributors it will be useful to know what they thought of the process, what they intend to do next and whether they prefer this funding process versus other approaches. For voters it will be useful to know what they thought of the process and whether they believe it was effective or not overall. Measuring this objective:
* Priority suggestions - Anyone in the community can submit priority suggestions and provide feedback to any other suggestion that has been shared. This will be useful for finding out the breadth and diversity of opinion and preferences there are in the ecosystem.
* Contribution task feedback - Any feedback given could be useful for identifying different ways to execute a task or sharing things that the contributor might not have considered or known about.
* Contributor peer review & feedback - What other people say about another contributor could be very insightful for seeing some honest opinions and preferences that people might have about the contributors and funding process. This data could reveal a number of opinions and preferences such as what expectations were missed or how one contributor might have impacted them personally.
* Funding process contributor feedback - Asking contributors about what they thought of the funding process, what their next steps are in the ecosystem and whether they preferred this funding process versus other approaches could be highly valuable feedback. This information should be useful for spotting any trends in what contributors think about the funding process and what they end up doing next after having this experience. Contributors may end up working with collaborators they met during the funding process or they might prefer to continue being a funded contributor in a future funding round.
* Funding process voter feedback - Voters will be asked about what they thought of the funding process and how effective it was at generating impact for the ecosystem. Each voter could have a different perspective about what outcomes they expected to happen with the funding process. This feedback should help to identify shortcomings of the funding process or where it might have met their expectations.
**Record funding process outcomes data**
Each contributor could contribute towards a range of open source projects. These contributions will all be open source. At the end of the experiment the final contribution outcomes can be aggregated to better understand what outcomes have been achieved. Comparisons can then be made about what has been achieved using this experiment against what might have happened with another funding process. Understanding and comparing these outcomes should be highly valuable for determining whether a contributor funding process is a promising long term solution. Measuring this objective:
* Contribution logs - The contribution logs will point towards all of the contributions that each person has made and the different projects a contributor has collaborated with. These contributions can be aggregated together to understand what actual outcomes have been generated overall. It will also be useful for identifying any trends in how people contribute and which of those contribution behaviours have been the most effective.
* Funding process voter feedback - Voter feedback at the end of the funding process will provide valuable information about what the voters thought about the funding process as a whole based on the outcomes that were actually generated.
* Funding process contributor feedback - Contributors will give their feedback about the funding process at the end of their funded contribution period. Contributors may want to continue being funded by the same funding process or they might be looking to join an existing project team in the ecosystem. Learning about any of these outcomes would be highly valuable for understanding how successful the experiment has been for the contributors. Contributor feedback should also help with understanding the overall sentiment about what has been achieved and whether this format was preferable to them over any other funding approaches they might have experienced.
# Development roadmap
The development roadmap looks at what the initial focus points are for the experiment and what focus areas could be explored and further developed in the future.
**Initial experiment focus**
The initial experiment is entirely focused on learning as much as possible about operating a contributor funding process. This experiment has been created to explore the potential effectiveness of [open source contributor funding](https://docs.contributors.org/proposal/open-source-contributors). Several of the suggested approaches that emerged from the [funding process analysis](https://funding.treasuries.io/) will be trialled in this experiment. Many of these suggestions are highlighted below. Experimenting with new approaches whilst keeping the costs as low as possible will help with maximising the cost efficiency for learning as much as possible about contributor funding. This experiment should help with generating a large amount of data that can be further analysed to make comparisons with other funding processes. The key components of this initial experiment include:
* **Community prioritisation suggestions** - A public priority suggestion board will help with experimenting with [independent contribution systems](https://funding.treasuries.co/approaches/contribution-approaches) which can help with making the funding process more dynamic and flexible to sudden changes. It will be insightful to see what priorities the community suggests and which priorities they upvote during the funding process. It will also be insightful to see how contributors respond to these suggestions. A separate process for handling priority suggestions means that [preferences and opinions from the community](https://funding.treasuries.co/outcome-influence/voter-preferences-and-opinions) will be captured at any stage during the funding process. A separate and ongoing priority process can help to enable the community to contribute in the way they want to and as often as they like.
* **Contributor profiles** - Contributors will share personal and professional information about themselves to be considered as a candidate. Over time this will help with learning about what information is really necessary for voters to make an informed decision about which contributors could generate the most impact.
* **Contributor voter selection** - [Expressive approval voting](https://docs.treasuries.co/voting/score-voting-approaches/expressive-approval-voting-with-decision-disapprovals) can be experimented with during the contributor selection process. Voter feedback and the voting results data will help with learning about how easy it is to use this suggested voting system. [Delegated idea selection](https://funding.treasuries.co/approaches/decision-approaches) is where contributors are selected and funded to then decide themselves which ideas they will execute. Some experiments might choose to experiment with this suggested decision approach, whilst other experiments might initially have the founding entities decide what contributors will work on.
* **Contribution task board** - A simple contribution task board is a good starting point for exploring how ideas can be planned and executed in a public space. It would be useful to experiment with a more complete idea based system in the future that enables contributors and community members to share draft ideas that can be improved over time with collaboration until they are ready for execution. For now a simple contribution task board will suffice for this experiment.
* **Contribution attestations** - Attestations should be useful for the contributions that are not digitally recorded. Contributors can make requests to other people to submit attestations about their own contribution efforts so that there is more evidence that the contributor actually made a certain contribution. This process will be useful for learning about what kind of attestations people make about other people's contributions and how these contributions could be more easily recorded and verified in the future.
* **Contribution logs** - [Individual time based monthly contribution logs](https://funding.treasuries.co/approaches/contribution-verification-approaches) can be trialled in this experiment to see how easy this approach is for contributors and how effective it is for recording and verifying contribution efforts. Over time this will help with identifying what contribution efforts should be recorded and presented. This experiment can also help with seeing how easy it is to identify good or poor performers based on their contribution logs and how accurate or limiting this approach is for assessing overall performance. Both contribution logs and contributor peer review responses will help with creating a strong foundation for learning about [measuring contributor impact](https://funding.treasuries.co/approaches/impact-measurement-approaches). Measuring contributor impact could end up being one of the more reliable and effective ways to reward people for generating impact.
* **Contributor peer reviews & feedback** - A simple feedback process will help with documenting people's opinions and experiences with other contributors that they worked with. Community members and other teams may also want to give feedback to the contributors who were funded. This information should be highly insightful for learning about how contributors have collaborated with others during the funding process and what impact they generated overall. This feedback should help with revealing some of the overall sentiments about the funding process and how it performed. Responses that come out of these reviews and feedback should be insightful for thinking about how a [contributor's impact could be measured](https://funding.treasuries.co/approaches/impact-measurement-approaches).
**Future development ideas**
After the initial experiment is completed there will be a number of learnings that can be made by analysing the data that has been created and collected. These insights can help with guiding future experiments to continue learning about contributor funding. As effective approaches emerge the next step will be to start developing more complete solutions that incorporate the learnings from initial experiments. In a rough order of priority some of these potential areas of development could include:
* **Contributor profiles** - Identity solutions could help with making contributor profiles for storing and sharing personal and professional information about a contributor. Contributors would then be able to create their own identity profile which can showcase their contributions and involvement in each ecosystem.
* **Contribution logs** - Contribution logs can be increasingly automated over time to make it easier and quicker for contributors to record and showcase their contribution outputs. Tools and libraries that are already being developed in the industry could be directly integrated into a contributor funding process to improve how contribution logs are recorded.
* **Voting systems** - Voting systems can be developed or integrated into the funding process to replace the manual solution that is initially being used for the experiment. The initial experiments should help to identify any improvements that might be necessary before a voting system is properly developed.
* **Contribution workflow** - Tools that help with managing and voting on how contributors work on a daily basis and make decisions about who works on what and how an idea gets executed.
* **Contributor peer review & feedback** - Solutions that help with enabling contributors and community members to more easily review other contributors performance and provide feedback about their contributions or interactions they've had with them.
* **Idea coordination & discussion** - Systems that enable the community and contributors to better suggest, coordinate and discuss ideas that they could execute within the ecosystem.
* **Idea selection** - A voting solution that enables the community and contributors to share their opinions and preferences about which ideas they believe are the most promising to work on at that point in time. Solutions that will improve upon the initial task management solutions used in this suggested experiment will be those that can help to take an idea from the draft stages all the way through to the execution stage in a collaborative manner.
* **Priority coordination & discussion** - Systems that enable the community and contributors to better suggest and discuss the priorities they believe are the most important for the ecosystem to focus on.
* **Priority selection** - A voting solution that enables the community and contributors to share their opinions and preferences about which priorities they believe are the most important for the ecosystem. The main problem with using solutions such as Canny is that these priority suggestions would not be on chain in. the ecosystem. Participating users might not necessarily be community members so future solutions will be more directly connected to the accounts and users in the ecosystem.
# Experiment setup
Resources and suggestions for setting up a contributor funding experiment
This experiment is focused on exploring how effective an [open source contributor funding process](https://docs.contributors.org/proposal/open-source-contributors) could be for Web3 ecosystems. The following resources are intended to help with setting up this experiment.
**Experiment setup overview**
The [funding operator guide](/contributor-funding-experiment/experiment-setup/templates/guides/funding-operator-guide) covers the main tasks and responsibilities involved in setting up and operating this contributor funding experiment. In regards to setting up the experiment as a funding operator the main tasks involved can be separated into three distinct phases:
1. **Priority suggestions setup** - A priority board should be created first so that community suggestions can be shared. The priority suggestions will then be reviewed with the founding entities to assess whether there is a sufficient amount of impactful contribution areas to work on that justify the expense of funding some contributors to work on those areas.
2. **Proposal submissions setup** - If there are enough impactful contribution areas to work on the next step is to set up the proposal submission process so that community members can submit their proposals. The founding entities will then review these proposals to make a final decision about whether they want to continue the funding experiment based on the proposals submitted.
3. **Finalise funding process** - Once it is agreed that the funding process is going to continue and be executed the final step is to finish setting up any remaining tools and services and share the final funding process details with the community.
**Tech stack**
The following tools and services can be used for the funding process experiment. Founding entities can swap out these suggestions with other solutions that they prefer.
{% content-ref url="/pages/6JEr3DnFTOD3hh34wG3H" %}
[Tech stack](/contributor-funding-experiment/experiment-setup/tech-stack)
{% endcontent-ref %}
**Templates**
The following are some templates that can be used for setting up the funding experiment. This includes templates for guides, forms, questionnaires and Google Sheets.
{% content-ref url="/pages/K8Lxd2Dq4vsJcVlPRvVV" %}
[Templates](/contributor-funding-experiment/experiment-setup/templates)
{% endcontent-ref %}
**Approach & parameter decisions**
The founding entities will need to make a number of decisions about the approaches and parameter values it used for the funding process.
{% content-ref url="/pages/zcoteBMZ90oUQ9e93plw" %}
[Approach & parameter decisions](/contributor-funding-experiment/experiment-setup/approach-and-parameter-decisions)
{% endcontent-ref %}
**Time & cost estimates**
The total amount of time it takes for the community, contributors, voters and funding operator to participate in the funding process has been estimated. An estimated total cost has then also been applied.
{% content-ref url="/pages/nZfRHVrFY8vJKUEwSqht" %}
[Time & cost estimates](/contributor-funding-experiment/experiment-setup/time-and-cost-estimates)
{% endcontent-ref %}
**Contributor funding experiment example**
An example experiment has been setup to show how these templates and suggestions could be used to create a contributor funding experiment:
{% content-ref url="/spaces/ZE8rIZvI1VylVcwzSPzR" %}
[Experiment Example](https://example.contributors.org/)
{% endcontent-ref %}
# Tech stack
A list of suggested tools and services that can be used to create a contributor funding experiment
An experiment for contributor funding can be executed cheaply and easily using a combination of existing tools and services. The following is a list of the suggested tools and services that could be suitable for an initial experiment. Ecosystems can swap in any other tools and processes that they would prefer to use when running their own experiments.
[**GitHub**](https://github.com/)
Most of the funding process information can be stored in an open source GitHub repository. This includes the guides, links to any tools being used, the contributor proposals and the contribution logs.
[**GitHub Projects**](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)
GitHub projects can be used for the contribution board as this board would then be public and easily accessible in the same GitHub repository. This is a simple and lightweight solution that should be suitable for small experiments that only have a handful of contributors being funded.
[**GitBook**](https://www.gitbook.com/)
GitBook will be used to make all of the information stored about the funding process more presentable and easily traversable. Most community members will likely be viewing the funding process information using the GitBook interface.
[**Google Sheets**](https://workspace.google.com/products/sheets/)
Voters have a number of voting options that they need to choose from when casting a vote on each contributor. A Google Sheet voting form will capture those responses. To submit a completed voting form the voter would download the Google Sheet as a file and then upload that file to a Google Form for submission.
[**Google Forms**](https://www.google.com/forms/about/)
Google Forms will handle any questionnaires that will be shared throughout the funding process. A Google Form will also handle voting form submissions.
[**Canny**](https://canny.io/)
Canny will be used for handling priority suggestions from the community. Any community member can sign up using a social login to submit their own priority suggestions. Community members can comment on existing suggestions to give their feedback and also upvote any suggestions that they believe are the most important. Contributors will then take these suggestions into account when deciding how they should best spend their time to generate impact for the ecosystem.
[**Telegram**](https://telegram.org/)
Telegram will be used for the following conversations:
* Funding process chat - To answer any questions and concerns about the funding process
* Open contributor chat - To enable anyone in the community to give feedback and make suggestions about what the contributors are working on or to have any other relevant discussion.
* Internal contributor chat - For contributors to collaborate together and also communicate with the founding entities about their contributions, technical topics or other relevant topic areas.
# Templates
A list of templates that could be used for a contributor funding experiment
{% content-ref url="/pages/3eyRCYVPfbOxwHhWJ9fg" %}
[Guides](/contributor-funding-experiment/experiment-setup/templates/guides)
{% endcontent-ref %}
{% content-ref url="/pages/ZYuc2i2w7vqyQlutsLJZ" %}
[Forms](/contributor-funding-experiment/experiment-setup/templates/forms)
{% endcontent-ref %}
{% content-ref url="/pages/l8X5oyAQxtGgwSghkuso" %}
[Questionnaires](/contributor-funding-experiment/experiment-setup/templates/questionnaires)
{% endcontent-ref %}
{% content-ref url="/pages/VTnr9lOxVydNn8YFzX3V" %}
[Google Sheets](/contributor-funding-experiment/experiment-setup/templates/google-sheets)
{% endcontent-ref %}
# Guides
{% content-ref url="/pages/KkVFnxIFGg5qs06bMGEU" %}
[Community guide](/contributor-funding-experiment/experiment-setup/templates/guides/community-guide)
{% endcontent-ref %}
{% content-ref url="/pages/CWICdVqNpW1bdQF33xIr" %}
[Contributor guide](/contributor-funding-experiment/experiment-setup/templates/guides/contributor-guide)
{% endcontent-ref %}
{% content-ref url="/pages/jnpqKRhMuqi5jOv4IXgw" %}
[Contribution attestation guide](/contributor-funding-experiment/experiment-setup/templates/guides/contribution-attestation-guide)
{% endcontent-ref %}
{% content-ref url="/pages/KimBNqRCxIxY0CEJLU2h" %}
[Voter guide](/contributor-funding-experiment/experiment-setup/templates/guides/voter-guide)
{% endcontent-ref %}
{% content-ref url="/pages/7tkHIUQeQtG4IM7tbSUY" %}
[Funding operator guide](/contributor-funding-experiment/experiment-setup/templates/guides/funding-operator-guide)
{% endcontent-ref %}
# Community guide
The community includes everyone in the ecosystem. This means the guide is for the founding entities, contributors, voters and any other community members.
**Priority suggestions**
Anyone in the community can suggest new priorities that the contributors will consider when deciding where they direct their contribution efforts. Community members are also encouraged to upvote the most important suggestions so that contributors are aware of the priorities that the community believes are the most important.
1. **Review priority suggestions** - Go to the priority suggestions board \[LINK] and review any existing priority suggestions.
2. **Submit priority suggestions** - If a priority suggestion doesn't exist that you believe is important you can create one with a title and description. At the bottom of the description add a "Source:" heading and then list out any links that provide evidence about the relevance and importance of the suggested priority. Share any priority suggestions you created with other community members for them to review.
3. **Respond to existing priority suggestions** - Provide any feedback you have to any existing priority suggestions. Upvote the suggestions that you believe are the most important for the ecosystem to focus on.
**Contributor proposal feedback**
After the contributor proposals have been submitted the voters and wider community will be invited to provide any feedback and suggestions they have about the proposals. Contributors will then consider these suggestions and feedback provided before making any final changes to their proposal.
1. **Review contributor proposals** - Go to the funding project pull requests page \[LINK]. If there are many pull requests you can filter the pull requests by typing in "Contributor proposal" into the filter search bar. Review the pending contributor proposals by clicking on a proposal pull request and reviewing the "Files changed" tab.
2. **Provide contributor proposal feedback** - If you have any suggestions or feedback for a proposal you can leave a comment on the "Conversation" tab.
**Contribution board feedback**
The community can see what the contributors are working on at any given point in time. Community members might have feedback, advice or suggestions that they want to share to a task that is recorded on the contribution board. To provide contribution feedback:
1. **Review contribution board tasks** - Go to the contributor funding contribution board \[LINK]. Review the tasks listed across the board and identify any tasks that you want to comment on.
2. **Shared contribution task feedback** - Share a message in the open contributor chat \[LINK] that links to the task and then provide any feedback you have in the same message. The relevant contributor will respond to the message when they are able to do so. Check for a response later in the day or the following day.
# Contributor guide
Contributors have the goal of generating as much impact as possible for the ecosystem during their funded contribution period. Contributors should focus their efforts towards the open source initiatives that could generate the most impact for the ecosystem.
**Expectations & responsibilities**
* **Self accountability** - Contributors have the autonomy to decide where, when and how they work. It is up to the contributor to use their own time effectively. Contributors could be given full autonomy to decide on what they work on or they might need to collaborate with the founding entities to come to an agreement. Contributors should consider and take into account the priority suggestions that get shared and upvoted by the community when deciding how they should best allocate their contribution efforts.
* **Open source contributions** - Contributors can only work on open source initiatives as these solutions can then be used by the entire community.
* **Collaborative** - Contributors are expected to collaborate with anyone in the community and identify the biggest shared problems that could be worth resolving. More collaboration with the existing teams and projects should help with reducing the amount of duplicated efforts across the ecosystem.
**Contributor proposal submissions**
Contributors need to submit a proposal to be considered as a contributor candidate.
1. **Copy contributor proposal template** - Fork the GitHub project \[LINK] locally. Copy the [contributor proposal template](https://github.com/web3association/contributor-funding/blob/main/contributor-funding-experiment/templates/forms/contributor-proposal.md) or copy an example contributor proposal \[LINK] and create a file in the candidates folder.
2. **Fill in contributor proposal** - Update the proposal template with your own personal and professional information.
3. **Create pull request** - Submit your contributor proposal as a pull request with the title of "Contributor proposal - \[Your full name]". Use this [example proposal pull request](https://github.com/web3association/contributor-funding-experiment-example/pull/1) as a reference. Share your proposal pull request with the community and the fund operator.
4. **Review proposal feedback** - Answer any questions and resolve any issues that get identified. Consider any amendments you want to make before the proposal is approved and merged. Once the proposal is merged you will be included in the contributor selection decision.
5. **Complete proposal submission feedback questionnaire** - Fill in the contributor proposal submission feedback \[LINK] questionnaire.
**Contributor onboarding**
Contributors that were successful in the voting decision will now be onboarded.
1. **Review priority suggestions** - Review the priority suggestions that have been shared by the founding entities and community.
2. **Share preferences** - Indicate any preferences you have by commenting on the suggestions that you believe are the most important to work on and how you could help with addressing that priority.
3. **Join internal contributor chat** - Join the internal contributor chat channels to coordinate and collaborate with other contributors and the funding operator. Ask the fund operator for a link to join.
4. **Join contribution log chat** - Join the contribution log chat so you can share your monthly contribution log pull requests with the fund operator. Ask the fund operator for a link to join.
5. **Join open contributor chat** - Join the open contributor chat \[LINK] to coordinate and collaborate with the community.
6. **Set initial contribution tasks** - Agree on your initial contribution tasks that you will start working on by collaborating with other contributors and the fund operator.
**Monthly contributions**
Each month a contributor will need to complete a months worth of contribution efforts. Contribution outputs will be recorded in a contribution log and this will be checked and approved by the fund operator.
1. **Complete contribution period** - Complete a months worth of contribution effort. Contribution board tasks should be updated when a task moves along from any of the different execution stages such as from backlog to in progress to in-review to completed.
2. **Share future contribution intentions** - When you are close to finishing a contribution task you should share your next intended contribution task by moving it in the contribution board to the 'Ready' column. Share the task in the internal contributor chat so that others can check that their own contribution efforts won’t overlap with this contribution task.
3. **Create contribution log** - At the end of each month, document your contribution outputs and efforts in a contribution log. A [contribution log template](https://funding.contributors.org/contributor-funding-experiment/templates/documents/contribution-log-form) is available as a guide. There is also an [example contribution log](https://example.contributors.org/current-funding-round/funded-contributors/alice-adams/june-2024) to review as well as a pending [pull request example](https://github.com/web3association/contributor-funding-experiment-example/pull/2). You can also review some other contribution log examples in the [Web3 Association contributors](https://docs.web3association.co/contributors) documentation. Submit your contribution log as a pull request with the title of "Contribution log - \[Your full name], \[Month, Year]". Use this [example contribution log pull request](https://github.com/web3association/contributor-funding-experiment-example/pull/2) as a reference.
4. **Request contribution attestations** - Share your contribution log pull request with other contributors or community members so they can provide any attestations about any of the contribution efforts that you have made that are not as easy for others to verify.
5. **Share contribution log -** Share the contribution log pull request in the contribution log chat so the funding operator can review and approve it. Make any amendments to the contribution log that are suggested by the fund operator.
6. **Receive contribution payment** - The contribution log will then be approved if the contribution outcomes are fair and reasonable. For this experiment, if there are any concerns or issues around a contribution log it will be reviewed by the founding entities to make any final approval decision. Assuming the contribution log is approved, you will now be eligible for the next contribution payment.
**Completed funding process**
Once a contributors funded period is finished they should complete some final questionnaires.
1. **Share contributor peer review questionnaire** - Ask any suitable contributors and community members to fill in a contributor peer review & feedback \[LINK] questionnaire.
2. **Complete contributor experiment questionnaire** - Complete the contributor experiment feedback \[LINK] questionnaire.
# Contribution attestation guide
Some contribution efforts are not as easy to digitally verify. Contribution attestations are a way for people to vouch for another contributors contribution efforts. These attestations help to provide some evidence that a contributor has actually made the contributions they say they have.
**Contribution attestation process**
1. **Review contribution efforts** - Review the contribution efforts listed in the contributors contribution log. Determine which contribution efforts you are able to vouch for based on your own observations and involvement in those contribution efforts.
2. **Create contribution attestation** - Fill in the contribution attestation template information and post the attestation as a comment in the pull request. A [contribution attestation template](https://funding.contributors.org/contributor-funding-experiment/templates/documents/contribution-attestation-form) is available for reference as well as an [example contribution attestation](https://github.com/web3association/contributor-funding-experiment-example/pull/2#issuecomment-2253817574) on a contribution log pull request.
# Voter guide
Voters are responsible for selecting the most promising contributors that could generate the most impact for the ecosystem. Voters will need to read and compare a number of contributor proposals to make an informed decision about which contributor candidates they are going to vote for.
**Voting process**
Voters will select the contributor candidates that they believe will be the most effective at generating impact for the ecosystem.
1. **Review expressive approval voting guide** - If you are not familiar with [expressive approval voting ](/contributor-funding-experiment/experiment-setup/templates/guides/voter-guide/expressive-approval-voting-guide)you should review the [guide](/contributor-funding-experiment/experiment-setup/templates/guides/voter-guide/expressive-approval-voting-guide) provided.
2. **Register to vote** - Register with the fund operator to receive a voter ID. The voting form will require a voter ID for the voting submission to be valid.
3. **Fill in the voting form** - A Google Sheet \[LINK] has been created that has all of the contributor candidate proposals listed in the document. Review the contributor candidate proposals and then duplicate the template Google Sheet form and fill it in with your voting decisions. Once completed, download the Google Sheet as a Microsoft Excel file (.xlsx).
4. **Wait for voting results** - After the submission deadline the votes will be aggregated and the voting results will then be shared publicly. Votes will remain anonymous.
5. **Complete contribution selection feedback questionnaire** - Fill in the contribution selection decision feedback \[LINK] questionnaire.
**Completed funding process**
The participating voters should complete a final questionnaire when the funding round has completed.
1. **Complete voter experiment feedback questionnaire** - Complete the voter experiment feedback \[LINK] questionnaire.
# Expressive approval voting guide
Approval voting is where voters can approve as many proposal as they like. The voters full voting power is applied when they approve any proposal. The proposals with the most approvals wins the vote. Expressive approval voting will be used for this contributor funding experiment. Expressive approval voting is an adaptation of approval voting that will be used for the contributor selection voting system.
The main differences with expressive approval voting compared to approval voting are as follows:
* **Added disapproval option** - A disapproval option is added however when a voter selects this option it will not apply any voting power. A disapproval option is only available so that voters can express their disapproval of a proposal. This voting option can help with providing more feedback to proposers and also more insightful information for the community to consider.
* **Added confidence variants** - Approval and disapproval options will be split into three different confidence variants. For approval options these will include ‘Strongly approve’, ‘Approve’ and ‘Somewhat approve’. For disapproval options these will include ‘Somewhat disapprove’, ‘Disapprove’ and ‘Strongly disapprove’. Voters will now be able to express the confidence they have in their decisions. Selecting any of the approval options results in the same outcome - the voters full voting power will be applied and they are approving the proposal. Disapproval votes enable voters to express dissent however these votes would not lead to any change in the decision outcome as the voting power would not be applied. Disapproval voting options are only added to provide proposal feedback.
* **Added feedback options** - A list of suggested feedback responses are provided for the voter to consider. The voter can select the feedback option that most strongly aligns with the reason they are approving or disapproving the proposal. Voters can only select one of the suggested feedback options. The voter will also be able to give more specific feedback in a separate feedback box if they want to. The suggested approval and disapproval feedback options are described in more detail below.
* **Added decision disapproval option** - A voter is able to disapprove of the entire set of proposals. A voter may want to do this if they disagree with the decision being made or they believe the quality of the submitted proposals is not high enough. A decision disapproval outcome could then either be abandoned entirely or the decision process could be repeated when higher quality proposals get submitted.
* **Victory condition additional factors** - The approval confidence variants can be used as an additional victory condition factor in situations where there is a tie between proposals that receive the same amount of approval voting power. In these situations the confidence variants can be used as a secondary factor to determine which proposals the voters have the highest confidence in selecting. The disapproval voting options will still have no impact on the outcome of the decision. In the event that there is still a tie between the remaining proposals a ranked choice vote will take place between the tied proposals.
Approval feedback option descriptions:
* **High performance** - Contributor is a high performer. Evidence demonstrates innovative or novel contributions, strong leadership, history of generating impactful outcomes or strong ability to make high quality contributions.
* **Strong skills & expertise** - Contributor has highly relevant skills & expertise. Evidence could demonstrate expertise around architecture, tools or software, strong technical leadership or that they have highly relevant skills or qualifications.
* **High ecosystem involvement** - Contributor has been highly involved in the ecosystem. Evidence could demonstrate they are highly familiar with the community and culture or that they have already been actively contributing towards projects in the ecosystem.
* **Promising potential** - Contributor has promising potential in the ecosystem. Evidence provided might not be fully convincing at this stage. Enough evidence has been provided to demonstrate promising potential.
Disapproval feedback option descriptions:
* **Poor performance** - Contributor has demonstrated poor historical performance. Example areas of concern could be around their contribution outcomes, communication skills, work ethic, cultural alignment, ecosystem involvement or their overall professionalism.
* **Lack of relevant skills & expertise** - Contributor does not have sufficient skills or expertise for the role. Large amounts of support might be needed. There is a risk that it could take a long time for the contributor to learn the required skills to meaningfully contribute.
* **Lack of ecosystem involvement** - Contributor has not been actively involved in the ecosystem. The contributor might have a lack of understanding about the ecosystem, how it operates and how projects are being developed. There also could be concerns around cultural fit.
* **Lack of evidence** - Contributor has not provided sufficient evidence to demonstrate their potential. The evidence currently provided does not sufficiently demonstrate their skills & expertise, ecosystem involvement or historical performance.
* **Salary too high** - The salary requested by the contributor is too high. The evidence provided by the contributor does not support the salary expectations they have.
# Funding operator guide
The funding operator is responsible for ensuring the funding process is run correctly and on schedule. They will help to manage the tools and services and provide support to anyone that is participating in the funding process. Over the long term the responsibilities of the funding operator can be increasingly automated to the point where the role will likely not be needed.
**Priority suggestion board setup**
The first task for the fund operator is to setup a priority suggestion board that will help with identifying whether there are enough impactful open source initiatives to work on.
1. **Setup funding process chat channel** - A Telegram chat needs to be setup for answering any questions about the funding process. This will be shared publicly with the community.
2. **Setup priority suggestion board** - A priority suggestion board needs to be created using Canny. Anyone in the community should be able to submit priority suggestions on this board at anytime.
3. **Invite community participation** - The community should then be invited to submit their priority suggestions about what open source initiatives could be highly impactful to work on. The community should also invited to give their feedback to any existing suggestions and to upvote the ones they believe are the most important.
4. **Review suggestions** - The priority suggestions will then be reviewed with the founding entities to assess whether there is a sufficient amount of impactful contribution areas to work on that justify the expense of funding some contributors to work on those areas.
**Contributor proposal setup**
The fund operator now needs to setup a proposal process to let community members submit their contributor proposals.
1. **Setup GitHub and GitBook** - Add the funding process guides to a GitHub repository and setup a GitBook account to present this information on a website.
2. **Invite community proposals** - Invite the community to submit their contributor proposals to be considered as a candidate.
3. **Invite community proposal feedback** - Invite the community to give feedback to the proposals that have been submitted.
4. **Verify and approve proposals** - Verify the proposals to ensure they have the correct information included. Have a quick video call with the proposer to ensure they are a human. Once the proposal and proposer are checked and verified the proposal can be approved and merged into the repository.
5. **Setup and share contributor proposal submission feedback questionnaire** - Create a questionnaire to receive feedback from contributors about the proposal submission process. Share the questionnaire with the people who have approved contributor proposals.
6. **Review contributor proposals** - Review the contributor proposals with the founding entities to check the number and quality of the proposals submitted. The founding entities will then need to make a final decision on whether to continue the funding experiment based on the proposals submitted.
**Finalise funding process**
To finish setting up the funding process the fund operator will need to finalise any decisions and parameters with the founding entities before setting up any remaining tools and services.
1. **Finalise decisions & parameters** - Finalise the approaches that will be used for the funding process and decide on any remaining parameter decisions with the founding entities.
2. **Setup questionnaires** - Create the voting feedback, contributor peer review, contributor funding process feedback and voter funding process feedback questionnaires.
3. **Setup chat channels** - Create the open contributor chat, internal contributor chat and contribution log chat using Telegram.
4. **Finalise funding process information -** Update the GitBook resource to include all the dates and timelines for the funding process.
5. **Share funding process** - Share the finalised funding process information with the community.
**Voting**
The voting process will enable voters to select their preferred contributors that they believe could generate the most impact.
1. **Setup voting submission form** - Create a submission form for voters to submit their voting file.
2. **Setup voting form** - Create a Google Sheet voting form using the approved contributor proposals. This Google Sheet will be used as a voting template that the voters will fill in.
3. **Invite voter participation** - Share the voting form and the submission form with the voters along with a timeline about when they need to fill in and submit their votes by.
4. **Process voting results** - Once the voting submission deadline has passed the votes can be aggregated into a single file and shared with the public. The voting results should also clearly indicate who the successful contributors are.
5. **Share contributor selection decision feedback questionnaire** - Share the voting feedback form with the voters to fill in by a certain date. Follow up with any voters that haven’t filled this in prior to the deadline.
**Contributor onboarding**
Once the contributors have been selected the next step is for the funding operator to onboard the successful contributors.
1. **Invite contributors to join chat channels -** Only successful contributors should be invited to the internal contributor chat and the contribution log chat. All contributors and any community members can join the open contributor chat.
2. **Support setting initial contribution tasks** - Collaborate with the contributors to set the initial contribution tasks they are working on. Communicate with the founding entities as necessary to ensure there is sufficient alignment and agreement around what contributors will initially be working on.
**Monthly contributions**
Contributors will receive support and guidance from the funding operator during each contribution month. The funding operator will be responsible to verifying contribution logs so that a contributor can receive their next payment.
1. **Respond to community questions** - Each month it will be likely that community members and contributors will share concerns, opinions and ask questions about the funding process. These conversations could lead to improvements or changes to the funding process.
2. **Support prioritisation decisions** - Request feedback from community members and founding entities about the current priorities and tasks that are being planned for execution. Support any issues around prioritisation if they emerge.
3. **Support planning and collaboration efforts** - Contributors could benefit from some support when planning their contribution efforts and collaborating with others in the ecosystem. The fund operator can help with identifying ways to increase collaboration where possible between contributors and also between existing projects and the contributors. Fund operators can also help with preventing any overlapping contribution efforts where possible.
4. **Review and approve contribution logs** - At the end of each contribution month a contribution log will be submitted by each contributor. The fund operator will need to review these logs to check the outputs seem fair and reasonable. If there is a concern around performance it will be discussed with the founding entities. Provide any feedback where necessary to improve the structure or information that has been provided. If everything appears reasonable and well documented then the contribution log can be approved and merged.
5. **Release contributor payment -** Ongoing contribution payment will rely on the approval of contribution logs. Once a contribution log is approved the contributors next payment should be released.
**Funding process completion**
1. **Share contributor peer review questionnaire** - Invite contributors and community members to give feedback to the other contributors once the funding round has been completed.
2. **Share voter feedback questionnaire** - Invite voters to give their feedback about the funding process.
3. **Share contributor feedback questionnaire** - Once peer review feedback and voter feedback is completed the contributors should then be invited to give their feedback about the funding process.
4. **Analyse and present funding outcome results** - Release the results from the questionnaires to the community. All of the funding and questionnaire data should be publicly accessible. Analyse the data that is available to identify any trends that are worth mentioning. Create a final report that covers the trends and statistics that emerged from that funding round, what improvements could be made in a future funding round and finally how effective the funding process was overall compared to other rounds or grants processes.
# Forms
List of form templates that could be used for a contributor funding experiment
{% content-ref url="/pages/Kdh6kH7582NLdvdzHUxx" %}
[Contributor proposal form](/contributor-funding-experiment/experiment-setup/templates/forms/contributor-proposal-form)
{% endcontent-ref %}
{% content-ref url="/pages/3lgvpUTXmtBI2OxBb7Re" %}
[Contribution log form](/contributor-funding-experiment/experiment-setup/templates/forms/contribution-log-form)
{% endcontent-ref %}
{% content-ref url="/pages/arlLx9CU839BpASplNWl" %}
[Contribution attestation form](/contributor-funding-experiment/experiment-setup/templates/forms/contribution-attestation-form)
{% endcontent-ref %}
# Contributor proposal form
**Full Name** - Required. Added as the proposal title.
**Profile picture** - 240px square image of candidate. Example:
## **Contact details**
Contributors can list out any contact details so that people can contact them. Other relevant contact details in the same format as below can also be added.
**Email** - Required.
**Telegram -** Optional.
**Discord** - Optional.
**X** - Optional.
## **Professional profiles & links**
Contributors can share their professional profiles to showcase the previous roles they have worked on. Other professional profiles could also be added below the suggestions below if they help with showcasing the contributors professional history.
**LinkedIn** - Optional.
**GitHub** - Optional.
**Personal Website** - Optional.
**Portfolio -** Optional.
## **Professional history**
If the contributor has provided a professional profile that documents their professional history they can respond with "Full details on LinkedIn profile".
If the contributor does not have a professional profile that documents their professional history then they can chronologically list out their recent roles, up to a maximum of 5, in the following format:
* Role title (Start date - end date, e.g. Jan 2000 - Feb 2001), Organisation name - Role responsibilities and any achievements.
* Project link or name - Indented items can be added to provide more detail about any projects within that role that are worth mentioning that the contributor has contributed towards and how they were involved.
## **Recent contributions**
Contributors can list out any relevant or recent contributions they have made to a Web3 ecosystem. Contributors should highlight the contributions that help to most effectively showcase their skills, expertise and performance.
Contributors that have not made any recent or relevant contributions to a Web3 ecosystem can respond with "New to the ecosystem."
If the contributor has made some recent contributions that they want to share they can chronologically list the most recent or relevant ones, up to a maximum of 5, in the following format:
* Contribution name with a link if possible (Start date - End date, e.g. Jan 2001 - Feb 2002) - Explanation about contribution
* Contribution link or task - Description about a more specific contribution task
## **Ecosystem involvement**
Contributors can provide more information about how they are getting involved in the ecosystem that they are requesting funding from. Ecosystem involvement means things such as events, meet ups, discussions and any other form of participation in the ecosystem.
If the contributor has not got involved in the ecosystem recently they can respond with "New to the ecosystem." or "No recent involvement."
If the proposal has been involved in some different events they can chronologically list out, up to a maximum of 5, the most relevant or recent events in the following format:
* Event name with a link if possible (Event date, e.g. Jul 2002 for an event that happened in July) - Explanation about involvement in the event
* Link showing evidence of participation - Description of link
## **Preferred areas of contribution**
Contributors can highlight what their preferred areas of contribution are. Some contributors might broadly want to work in a certain area, others may already know what open source project they want to work on specifically and others may be flexible to work on any suggested community idea.
If the contributor doesn't currently have any strong preferences about what they work on in the ecosystem they can respond with "Looking to contribute towards community suggested ideas". Community suggested ideas would also include any suggestions that come from the founding entities and other contributors.
Contributors that do have any preferences about what they are working on can list out the initiatives or focus areas that they are most interested in, up to a maximum of 5, in the following format:
* Name of project or focus area with a link if possible - Description of the tasks involved in working on that project or an outline of why the contributor is interested in that focus area and why these tasks or focus area is suitable for the contributor based on their own skills and expertise.
# Contribution log form
**Pull request** - Once a pull request has been submitted the contribution log can be updated to include a link to it. This will make it easier for people to view any contribution attestations that get left on the pull request.
**Contribution duration -** State the number of working days that you contributed during this month. If you contributed during the whole month you can simply state "Full month".
## **Overview**
Add a brief overview overing what you worked on this month. Use bullet points to separate out the different contribution areas. Optional.
## **Contribution outputs**
Contribution outputs should provide evidence of a generated contribution output. Contribution outputs should be publicly accessible and available online for others to verify and review. For any of the following contribution outputs the format for adding each item is:
* Contribution output title \[Add evidence link as part of the title] - Optional description about the contribution.
If there are many entries in a single contribution area they can be grouped together under different titles to better categorise them and make it easier to read.
**Code**
List any code repository pull requests. This can include pull requests for anything code related such as features, tests, deployment pipelines or bug fixes. Pull requests are preferred over single commits as pull requests can combine multiple commits into a single code change that can often be more easily titled and described.
**Documents**
List any documents that have been created or updated. Documents could be focused on areas such as software architecture, research reviews, analysis, security, product management, proposals, presentations or any other relevant area.
**Designs**
List any designs that have been created or improved. Designs could include mockups, high fidelity designs, icons, graphics and any other relevant design contribution.
**Videos**
List any videos you made and any recorded videos that provide evidence of recent events, discussions or meetings with other community members or contributors. Add description information about when the video was from and what it was about.
**Systems & operation**
List out any new systems or parameter changes. This could include things like the operational efforts to launch or maintain a website, backend or other application.
**Project management**
List out any projects where you have been managing the updates and actively helping with the contribution efforts. This focuses on broader coordination efforts rather than your own specific contribution tasks.
**Feedback & reviews**
List out any reviews or feedback you have given to other people's code, designs, documents or other contributions. Link the overall pull request, document or design file that you have commented on rather than linking every specific piece of feedback within those pages.
**Other**
List out any other contribution outputs that are not covered in the areas above.
## **Contribution efforts**
Contributions that can be more easily proven using online evidence links should be added to the contribution outputs section. Some contributions do not lead to an output and some contributions are not as easily recorded online. It is preferred that contributions are recorded when possible so that they can be verified and reviewed by others. When there is no sufficient online evidence of someone's contribution effort a contributor can instead add those contribution efforts in this section. These contribution efforts would ideally then receive attestations from other contributors and community members that can vouch for the contributor that they did in fact make those contributions.
**Mentoring**
List out any interactions you had with other contributors or community members where you were providing mentorship. The format for these entries are as follows:
* Name of person receiving mentorship - Brief description about how you helped them
**Discussions**
List out any discussions you had with other contributors or the wider community. Discussions could have been about anything relevant to the ecosystem and initiatives that the contributor is working on such as planning, collaboration or project management. The format for these entries are as follows:
* Name of the discussion, date it happened - Overview covering what was discussed and how you contributed.
**Events**
List out any events that have happened recently that you contributed towards and what you helped with. Events could include community meet ups, team building sessions, presentations, focus groups, hackathons and workshops. The format for these entries are as follows:
* Name of the event, date it happened - Outline how you contributed to the event.
**Research**
List any research efforts that were made to review certain information sources that could be useful to the ecosystem. If this research can be translated into a literature and information review document this will be preferred as it can provide more evidence of the contribution effort and be useful to other contributors. The format for these entries are as follows:
* Title of research - Description of what was researched and why.
**Other**
List out any other contribution efforts you have made that aren't covered in the areas above.
# Contribution attestation form
**Full name** - Attesters full name
**Contributions being attested**
List of the contribution efforts from someone's contribution log that you are making attestations for. Use the same titles or links they used in their contribution log.
**Involvement**
Describe how you observed or were involved in any of the contribution efforts mentioned above.
**Relevance**
How have these contribution efforts impacted you or the ecosystem?
# Questionnaires
List of questionnaire templates that could be used for a contributor funding experiment
{% content-ref url="/pages/vWsys9bglSTpBug64n2R" %}
[Contributor proposal submission feedback](/contributor-funding-experiment/experiment-setup/templates/questionnaires/contributor-proposal-submission-feedback)
{% endcontent-ref %}
{% content-ref url="/pages/b2bbwXbbvOmItVVBkAoK" %}
[Contributor selection decision feedback](/contributor-funding-experiment/experiment-setup/templates/questionnaires/contributor-selection-decision-feedback)
{% endcontent-ref %}
{% content-ref url="/pages/EgEbF2lYbfXJVZDPrcha" %}
[Contributor peer review & feedback](/contributor-funding-experiment/experiment-setup/templates/questionnaires/contributor-peer-review-and-feedback)
{% endcontent-ref %}
{% content-ref url="/pages/dG1vxc4Is9W23VSXI9oD" %}
[Voter experiment feedback](/contributor-funding-experiment/experiment-setup/templates/questionnaires/voter-experiment-feedback)
{% endcontent-ref %}
{% content-ref url="/pages/GTIXvS4VdQ8oF1pOISEr" %}
[Contributor experiment feedback](/contributor-funding-experiment/experiment-setup/templates/questionnaires/contributor-experiment-feedback)
{% endcontent-ref %}
# Contributor proposal submission feedback
Questionnaire for contributors to complete after they have submitted their contributor proposal to be considered as a candidate.
**1. Roughly how long, in minutes, did it take for you to create your contributor proposal? (Required)**
**2. What other information, if any, do you believe should be included in a contributor proposal? (Optional)**
**3. What feedback, if any, do you have about the contributor proposal submission process? (Optional)**
# Contributor selection decision feedback
Questionnaire for voters to complete after they have finished selecting their preferred contributors to receive funding.
**1. Roughly how long, in minutes, did it take for you to read and vote on the contributor proposals? (Required)**
**2. What other information, if any, do you believe should be included in the contributor proposals? (Optional)**
**3. What feedback, if any, do you have about the contributor selection decision process? (Optional)**
# Contributor peer review & feedback
Questionnaire for contributors to complete after they have completed their term of funded contribution. Contributors would be asked to give other contributors a review and some feedback. All questions would be optional as contributors might not have enough information to make a well informed response.
**1. Did the contributor generate a sufficient amount of impact during their funded contribution period? (Optional)**
1. Missed expectations
2. Somewhat missed expectations
3. Met expectations
4. Exceeded expectations
5. Strongly exceeded expectations
**2. Overall how impactful were their contributions for the ecosystem? Highlight any contributions that were innovative or novel and how they helped to move the ecosystem forward. (Optional)**
**3. Did the contributor's performance meet expectations? (Optional)**
1. Missed expectations
2. Somewhat missed expectations
3. Met expectations
4. Exceeded expectations
5. Strongly exceeded expectations
**4. What contributions or areas was the contributor particularly performant at executing? How could they improve their performance in the future? (Optional)**
**5. Was the contributor collaborative with other contributors and projects? (Optional)**
1. Missed expectations
2. Somewhat missed expectations
3. Met expectations
4. Exceeded expectations
5. Strongly exceeded expectations
**6. Were there any notable contribution efforts or initiatives that demonstrated the contributors collaborative efforts? (Optional)**
**7. How effective were their communication skills with other contributors and community members? (Optional)**
1. Missed expectations
2. Somewhat missed expectations
3. Met expectations
4. Exceeded expectations
5. Strongly exceeded expectations
**8. Were there any notable occasions that demonstrated their communication skills? (Optional)**
**9. Did the contributor demonstrate any strong leadership during a project, through their own execution efforts or from applying their own expertise? How important was this leadership for guiding the execution success of a given initiative? (Optional)**
**10. Were there any notable mentoring and support efforts that the contributor provided to other people? (Optional)**
**11. Did the contributor help with fostering a positive and inclusive environment for contributors and the wider community? Did the contributor demonstrate any community involvement that made a positive impact that is worth mentioning? (Optional)**
# Voter experiment feedback
Questionnaire for voters to complete after the funding experiment is completed.
**1. Overall did the contributors work on impactful ideas that could benefit the ecosystem? How effective was their prioritisation? (Required)**
**2. Overall how impactful was the contributor funding process and the contribution outcomes it helped to generate? (Required)**
1. Missed expectations
2. Somewhat missed expectations
3. Met expectations
4. Somewhat exceeded expectations
5. Exceeded expectations
**3. What were the main problems or opportunities that you noticed about this contributor funding process? How do you think these problems or opportunities could be addressed? (Required)**
**4. How did this contributor funding process compare with other grants processes that you’re aware of or taken part in? Do you have any preferences? (Optional)**
**5. Do you believe that the ecosystem should experiment with another round of contributor funding? (Required)**
1. Yes
2. No
**6. What reasoning do you have for the previous answer? (Required)**
**7. What feedback, if any, do you have about this funding process and how it could be improved? What improvements should be prioritised if this funding process was to be run again? (Optional)**
# Contributor experiment feedback
Questionnaire for contributors to complete after the funding experiment is completed.
**1. Roughly how long on average, in minutes, did you spend on creating each contribution log? (Required)**
**2. Were there any contribution efforts that were not recorded in your contribution logs? If so, please describe these contributions. (Required)**
**3. Which contribution efforts were the most difficult to record in your contribution logs? (Required)**
**4. What feedback, if any, do you have about the contribution log process? What are the most important improvements you would focus on? (Optional)**
**5. How difficult was it to get attestations from others about your contribution efforts? (Required)**
1. Very difficult
2. Somewhat difficult
3. Expected amount of effort
4. Somewhat easy
5. Very easy
**6. What feedback, if any, do you have about the process for requesting attestations from others for your contribution logs? (Optional)**
**7. Were the peer reviews and feedback you received from others fair and reasonable? If not, please describe what responses were not fair and reasonable. (Required)**
**8. Have you previously been funded in any ecosystem? (Required)**
1. Yes
2. No
**9. If so, how did this contributor funding process compare with these other funding experiences? Which funding process did you prefer out of the ones you have participated in? (Optional)**
**10. What feedback, if any, do you have about this funding process overall and how it could be improved? (Optional)**
**11. What are your next steps in the ecosystem? Would you prefer to continue being a funded contributor or would you like to work in another team? Or in another ecosystem? (Required)**
# Google Sheets
# Approach & parameter decisions
A list of decisions to be made about the approaches and parameter values that will be used during the funding process
## Approaches
A number of decisions need to be made about which approaches should be used for the funding process.
**Tools & services account ownership**
Accounts are needed for many of the suggested tools and services that will be used to operate the funding process. GitHub, GitBook and Canny could be used over multiple funding rounds if the experiment was successful. These services could be more of a long term solution until a custom solution can be developed. Google Sheets and Google Forms are temporarily used within each funding round and can be more easily replaced in future rounds as the data that comes out of these tools can be stored on GitHub for future reference. Some tools and services ownership approaches include:
* **Founding entity owned** - The ecosystems founding entities are well suited to take ownership of any tool or service accounts that are needed to operate the funding process. The founding entities will then be able to easily transition to different funding operators and use different people for different parts of the funding process.
* **Funding operator owned** - If the founding entities aren't going to be the funding operator themselves the fund operator could also be responsible for creating the accounts for the required tools and services. This could be a simpler way to get started however at the end of the funding round these accounts might need to be transferred to the founding entity or another person or entity if the fund operator changes.
**Contributor selection voters**
Founding entities will decide who the voters will be for deciding which contributors are going to be selected. If there is any doubt around this decision, it will likely make sense for members of the founding entity to make the contributor selection decision initially as this can be a simpler and quicker approach to get started with. This could make sense whilst the funding process is still in its more experimental and learning focused phase. The voter approaches include:
* **Founding entity voters** - Members from the founding entity will vote on which contributors get selected.
* **Custom selected voters** - Members from the founding entity and/or the community are selected by the founding entity to participate in the voting decision. The founding entities could consider only inviting community members to become voters that have made certain contributions to the ecosystem or that have demonstrated a certain level of involvement in the ecosystem. Voter participation criteria could help with improving the probability that voters who participate have certain expertise or that they are highly involved in the ecosystem. A reason this approach might make sense is it could be simple and quick for the founding entities to select some voters from the community for this experiment.
* **Community voters** - All community members can participate in the voting decision.
**Contribution board task creators**
A priority suggestion board will enable the community to give their thoughts and suggestions about what open source initiatives could be the most impactful for contributors to prioritise. The next step for the funding process is deciding how those priorities get translated to tasks that contributors can work on. The two main options include:
* **Founding entity created** - The founding entity will decide which tasks the contributors should work on based on the community suggestions they believe are the most important. This approach is similar to idea grants processes where the founding entities are deciding which ideas are being selected and funded. This approach achieves a very similar outcome as idea grants processes where the founding entities will decide which people get funded and what they will be working on. This approach can make more sense if the contributors are less experienced in the ecosystem or when the founding entities want to be more cautious and be more involved in how the funding is being used for any initial experiment.
* **Contributor created** - Contributors are given the autonomy and responsibility to decide how they allocate their time. This approach is desirable over the long term however this responsibility can be more challenging for contributors who haven’t got a lot of experience in the ecosystem. Experienced contributors that have a better grasp of the tech stack and the different problems and opportunities in the ecosystem could be more suitable for this more flexible contribution approach.
## Parameters
Decisions need to be made about what values should be used for each parameter in the funding process.
**Funding process parameters**
* **Contributor funding term length** - How many months will the contributors be funded for. An initial term length of 3-6 months could be suitable for an initial experiment. 6 months would be the default suggestion.
* **Maximum funding available per contributor** - How much funding are contributors able to request for their proposals? This value could be decided after the contributor proposals are submitted if the founding entities want to assess the initial interest from the community to participate. $10,000 per month would be the default suggestion for an initial experiment.
* **Total funding available** - How much total funding will be available for contributors to request from? This value does not need to be decided immediately. Contributor proposals could be submitted before this parameter is set so that the number and quality of proposals can be reviewed. $180,000 would be the default suggestion if at least 18 good proposals are submitted and the founding entities are comfortable with the selection of 3 contributors for a 6 month contribution period.
**Timelines & dates**
* **Initial priority suggestion submission** - A start and end date is needed for submitting initial priority suggestions. The founding entities will consider these before finalising the funding process parameters. Community suggestions can still be submitted after the end date. The end date just means the funding process would move to the next step.
* **Contributor proposal submission start and end date** - A start and end date for contributor candidates to submit their proposals. Contributors will also be requested to submit their proposal submission feedback in a questionnaire within a fixed time period after the submission end date.
* **Contributor proposal feedback** - A start and end date is needed for community members to give feedback to the submitted contributor proposals. After this end date has passed the contributor proposals will be approved and included in the voting decision.
* **Voting period** - A start and end date for when voters will be able to cast their contributor selection vote. Voters will also be requested to submit their voting feedback in a questionnaire within a fixed time period after the voting end date.
* **Voting results aggregation and release** - Setting a start and end date for aggregating and releasing the voting results to the public.
* **Onboarding period and contribution** - A start and end date for enabling contributors to get onboarded in the ecosystem and to prepare for their funded period of contribution.
* **Contributor peer review questionnaire deadline** - A start and end date for allowing contributors and community members to peer review other contributors and give their feedback.
* **Completed funding process questionnaire deadline** - A start and end date for both contributors and voters to submit their feedback in a questionnaire about the funding process.
# Time & cost estimates
Time and cost estimates for each actor that would be involved in the funding process
Each of the stakeholders involved in the funding process have a list of tasks that they will complete to fully participate in the funding process. The time it takes to complete each of those tasks can be estimated and aggregated to generate a total estimated time required. The total time estimates can then be multiplied by an hourly rate for each role. Each role's hourly rate will need to roughly take into account the skill level and responsibility of the role. This will result in generating a total estimated cost to participate in the funding process for each stakeholder.
To create the participation time estimates a number of default parameters will be applied:
* **Contributor funding term length** - 6 months
* **Maximum funding available per contributor** - $60,000 (6 months of $10,000)
* **Total funding available** - $180,000 (A minimum of 3 contributors will get approved)
To create total participation cost estimates the following hourly rates will be applied to each of the different stakeholders:
* **Community member** - $15 per hour. This rate is higher than the majority of minimum wages across the world. The purpose of adding this rate is to help ensure that the value of people's time is respected.
* **Contributor** - $57.50 per hour. This is rounded down from a $120,000 annual equivalent salary assuming a 40 hour work week. This rate is higher than the majority of normal software developer roles across the world. It should be noted however that talented blockchain and smart contract developers can sometimes be paid much more than this hourly rate.
* **Voter** - $15 per hour. Same rationale as community members.
* **Funding operator** - $38 per hour. This is rounded down from a $80,000 annual equivalent salary assuming a 40 hour work week. The role is important however the tasks and responsibilities do not require a high skill level. The hourly rate should be comparable to a number of entry to mid level management or analyst roles depending on the country.
The values used within each stakeholder's time estimates are intended to reflect an average time. Some people will spend far longer than the estimated times given below, and others will spend far less time. Our goal for this estimation is to be somewhat generous in the average time estimations to better understand the potential cost if this process was going to be scaled.
Ecosystems can update any of the values being suggested to better reflect their own circumstances, usage and funding process. The values provided above are merely initial suggestions to start thinking about how time consuming and costly this funding process could be for the different stakeholders involved.
## **Community member**
**Priority suggestions**
1. **Review priority suggestions** - 200 minutes (2 minutes per suggestion, 100 suggestions)
2. **Submit priority suggestions** - 10 minutes (10 minutes per suggestion, 1 suggestion submitted)
3. **Respond to existing priority suggestions** - 15 minutes (3 minutes per suggestion, 5 suggestions responded to)
Total - 225 minutes
**Contributor proposal feedback**
1. **Review contributor proposals** - 80 minutes (4 minutes per proposal, 20 proposal submitted)
2. **Provide contributor proposal feedback** - 10 minutes (5 minutes per proposal, 2 proposals feedback given to)
Total - 90 minutes
**Contribution board feedback**
1. **Review contribution board tasks** - 180 minutes (30 minutes per month, 6 months period)
2. **Shared contribution task feedback** - 90 minutes (15 minutes per piece of feedback, 1 piece of feedback per month, 6 month period)
Total - 270 minutes
**Total estimated participation time**
9 hours 45 minutes (225 + 90 + 270 = 585 minutes)
**Total estimated cost to participate**
$146.25 ((585 minutes/60) x $15)
## Contributor
**Contributor proposal submissions**
1. **Copy contributor proposal template** - 10 minutes
2. **Fill in contributor proposal** - 60 minutes
3. **Create pull request** - 10 minutes
4. **Review proposal feedback** - 20 minutes
5. **Complete proposal submission feedback questionnaire** - 10 minutes
Total - 110 minutes
**Contributor onboarding**
1. **Review priority suggestions** - 200 minutes (2 minutes per suggestion, 100 suggestions)
2. **Share preferences** - 15 minutes (5 minutes per suggestion, 3 suggestions responded to)
3. **Join internal contributor chat** - 5 minutes
4. J**oin contribution log chat** - 5 minutes
5. **Join open contributor chat** - 5 minutes
6. **Set initial contribution tasks** - 180 minutes
Total - 410 minutes
**Monthly contributions**
1. **Complete contribution period** - 0 minutes (Not counted towards the estimates as contributors will be paid their agreed salary for their contributions. These estimations are only interested in the time required and cost involved with participating in the funding process itself, not the actual execution efforts)
2. **Share future contribution intentions** - 240 minutes (10 minutes per task, 4 tasks per month, 6 month contribution period)
3. **Create contribution log** - 360 minutes (60 minutes per contribution log, 1 contribution log per month, 6 month contribution period)
4. **Request contribution attestations** - 60 minutes (2 minutes per attestation request, 5 requests to contributors or community members per month, 6 month contribution period)
5. **Share contribution log -** 30 minutes (5 minutes per contribution log shared, 6 month contribution period)
6. **Receive contribution payment** - 0 minutes (Contributor waits for payment to be received however is not responsible for any contribution efforts)
Total - 690 minutes
**Completed funding process**
1. **Share contributor peer review questionnaire** - 10 minutes (2 minutes per shared request, 5 people request shared to)
2. **Complete contributor experiment questionnaire** - 20 minutes
Total - 30 minutes
**Total estimated participation time**
20 hours 40 minutes (110 + 410 + 690 + 30 = 1,240 minutes)
**Total estimated cost to participate**
$1,188.33 ((1,240 minutes/60) \* $57.50)
## Voter
**Voting process**
1. **Register to vote** - 5 minutes
2. **Fill in the voting form** - 160 minutes (5 minutes to review each candidate, 3 minutes to vote on each candidate, 20 contributor proposals to review)
3. **Submit voting form** - 5 minutes
4. **Wait for voting results** - 0 minutes (Voting results are aggregated by the funding operator)
5. **Complete contribution selection feedback questionnaire** - 15 minutes
Total - 185 minutes
**Completed funding process**
1. **Complete voter experiment feedback questionnaire** - 20 minutes
Total - 20 minutes
**Total estimated participation time**
205 minutes (185 + 20 = 205 minutes)
**Total estimated cost to participate**
$51.25 ((205 minutes/60) \* $15)
## Funding operator
**Priority suggestion board setup**
1. **Setup funding process chat channel** - 10 minutes
2. **Setup priority suggestion board** - 60 minutes
3. **Invite community participation** - 1200 minutes
4. **Review suggestions** - 240 minutes
Total - 1,510 minutes
**Contributor proposal setup**
1. **Setup GitHub and GitBook** - 120 minutes
2. **Invite community proposals -** 1200 minutes
3. **Invite community proposal feedback** - 300 minutes
4. **Verify and approve proposals** - 600 minutes (30 minutes per proposal and proposer verification, 20 proposals submitted)
5. **Setup and share contributor proposal submission feedback questionnaire** - 70 minutes (30 minutes creating questionnaire, 2 minutes per share with proposer, 20 proposals submitted)
6. **Review contributor proposals** - 120 minutes
Total - 2,410 minutes
**Finalise funding process**
1. **Finalise decisions & parameters** - 180 minutes
2. **Setup questionnaires** - 90 minutes
3. **Setup chat channels** - 30 minutes
4. **Finalise funding process information -** 120 minutes
5. **Share funding process** - 300 minutes
Total - 720 minutes
**Voting**
1. **Setup voting submission form** - 20 minutes
2. **Setup voting form** - 60 minutes (3 minutes per contributor, 20 proposals submitted)
3. **Invite voter participation** - 120 minutes
4. **Process voting results** - 180 minutes (3 minutes per voting file, 30 voters participating, 90 minutes creating summary page)
5. **Share contributor selection decision feedback questionnaire** - 120 minutes
Total - 500 minutes
**Contributor onboarding**
1. **Invite contributors to join chat channels -** 120 minutes
2. **Support setting initial contribution tasks** - 360 (120 minutes per contributor, 3 selected contributors)
Total - 480 minutes
**Monthly contributions**
1. **Respond to community questions** - 1,080 minutes (180 minutes, 6 month contribution period)
2. **Support prioritisation decisions** - 1,080 minutes (180 minutes per month, 6 month contribution period)
3. **Support planning and collaboration efforts** - 2,160 minutes (120 minutes per contributor per month, 3 selected contributors, 6 month contribution period)
4. **Review and approve contribution logs** - 1,080 minutes (60 minutes per contribution log, 3 selected contributors, 6 month contribution period)
5. **Release contributor payment -** 180 minutes (10 minutes per contributor, 3 selected contributors, 6 month contribution period)
Total - 5,580 minutes
**Funding process completion**
1. **Share contributor peer review questionnaire** - 180 minutes
2. **Share voter feedback questionnaire** - 300 minutes
3. **Share contributor feedback questionnaire** - 300 minutes
4. **Analyse and present funding outcome results** - 2,400 minutes
Total - 3,180 minutes
**Total estimated participation time**
229 hours 40 minutes (910 + 2410 + 720 + 500 + 480 + 5580 + 3180 = 13,780 minutes)
**Total estimated cost to participate**
$8,727.33 ((13,780 minutes/60) \* 38)