FIO Worker Proposal funding change proposal
Decision has been made by the Steering Committee to abandon this approach and focus on improving the existing, function-based Worker Proposal system.
Overview
The following document describes a proposed change to how the Foundation operates and funds worker proposals. The change proposal does not imply that the existing process is broken, but rather attempts to make it better.
For the most part the Foundation has been operating as a centralized company. Even though it funds multiple independent worker proposals, the individual workers operate in a functional hierarchy, e.g. Business Development, Marketing, Development, Product, etc. The Steering Committee sets the priorities which are then executed by the individual functional areas. A Product Owner is picked to own the initiative and relies on the bandwidth of the other functional areas to execute their initiative. The “reporting structure” of Product Owners is not clear. It’s also not clear how other core team members' input should be considered by Product Owners. KPIs are not typically set or monitored for any of the initiatives. In many centralized organization, centrally-led Product organization acts as the execution group. However, the Product organization at FIO does not have such a role nor resources required to undertake it. The result is less-than-optimal execution of initiatives funded by the Foundation.
In addition, the existing structure is hard to scale as it requires proportional and coordinated growth of each functional area in order to avoid bottlenecks. It also makes every worker proposal which does not fit the functional area, seem like an outsider and hence makes it harder to organically attract workers.
Proposal
The Foundation Board hires Steering Committee members. This is funded with a stand-alone worker proposal for each member and is paid with locked FIO (or model similar to future FIO grants) to incentivize the Steering Committee to make decisions positively impacting future value of FIO token and hence inherently spur adoption of the FIO Protocol.
The Steering Committee reviews and approves worker proposals for complete initiatives with clear KPIs, rather than functions. In other words not “Development”, but “Launch, hosting and maintenance of Dashboard with clearly set KPIs (what is expected and what would be considered failure or raging success)”. The entity which wins that worker proposal is responsible for all elements required for success including Product Management, Design, Development, Hosting, Marketing, etc. It may, in turn hire additional resources to fulfill those needs and pay them directly. As a results the worker proposal includes enough funds to cover all required resources.
Some initiatives would intentionally be funded only for initial development with the idea of them becoming self-funding businesses. For others, the Steering Committee reviews each worker proposal against forecasted KPIs and decides if it wants to continue funding it.
As an example, here’s a self-contained project to develop Crypto Badges NFT website. It would include:
Product work
FIP definition
Website design and specification of MVP and future versions
Development and Dev-ops
Development, testing and launch of FIP functionality
Hosting of website
Marketing
Marketing of new Website
Pros
Foundation can more easily approve new initiatives, because it does not have to worry about operationalizing it, i.e. “great idea, but we don’t have resources to build it now”, and therefore should increase the amount of activity the Foundation can efficiently fund.
Entities winning worker proposals have a clear set of KPIs and funds to achieve them and do not have to rely on other “functional areas”. They are also truly CEOs of their worker proposal deciding how to best spend the funds to achieve the objective.
Organization-wide coordination should be reduced as each entity is in control of its own destiny.
The “core team” no longer has to be involved in every initiative.
This “VC-like” model should attract more entities willing to submit worker proposals.
Cons
Domain expertise is still critical and there are only so many resources that have it. It will take time for new resources to come up to speed.
Some work may end up being duplicated due to lack of central control structure.
Cost may end up being higher as entities undertaking worker proposals may have more risk and subcontracting overhead.
Transition
Existing entities would submit worker proposals for delivering of specific tasks/projects the Foundation wants to fund, rather than staff (FTE) worker proposals. Those entities would then be free to hire, and pay for, any resource they require to execute on the objective. It’s likely that initially the resources would be existing staff members as they have domain expertise, but over time new resources may be brought in. For example, if an entity is awarded the “FIO Dashboard” worker proposal, they may higher existing developer resources for building and development and existing marketing resources for promoting it.
Worker proposals are not exclusive. For example, there could be more than one entity which has an independently run “Promote FIO Protocol” worker proposal. This allows the Foundation to more easily test out new entities/teams.
Example
Here’s an example of how the work currently being funded by the Foundation could be organized under the new system. It’s a quick draft to facilitate conversation, rather than a specific proposal.
Worker proposal | Description | KPIs |
|---|---|---|
Promote FIO Protocol | Objective: To drive awareness, adoption, and utilization of FIO Protocol via a full-transparency marketing program designed for scalability, replication, and efficient communal re-use of proven best practices
|
|
Acquire FIO integrations |
|
|
Maintain FIO Chain health |
|
|
FIO Chain Development (FIPs) | Core chain and contract development
QA
Release management
Documentation and knowledge sharing
FIO Chain and Contract Security
EOSIO compatibility and community support
Developer outreach and community building
|
Core chain and contract development
QA
Release management
Documentation and Knowledge sharing
FIO Chain and contract security
EOSIO compatibility and community support
Developer outreach and community building
|
Integration - Technology and Tools | Integration documentation / Devhub
Integration development support
Integration IT support
Tools and libraries to support the integration experience
| TBD |
Devops and Secops |
| TBD |
FIO Dashboard |
|
|
Hey FIO Dashboard |
|
|
FIO Marketplace |
|
|
Registration Site |
|
|
Reporting Site |
|
|
Primary Block Explorer |
|
|
Foster FIO Community |
|
|
FIO Support in Ledger |
|
|
Wrapping of FIO Tokens and Domains |
|
|
Crypto Badges | https://fioprotocol.atlassian.net/wiki/spaces/DAO/pages/467173377 |
|
Steering Committee Member |
|
|