JMES Incubator is an open-source, Decentralized, Autonomous Organisation (DAO) that redistributes the official JMES World token issued from the JMES Governance system to users to produce open-source output that supports our Strategy in contributing towards the JMES Vision.
The Incubator uses a micro-incentive bounty system to fund and manage development and maintenance against various projects proposed by the JMES community and the JMES network of DAOs.
Incubator management is decentralized across Director users who are incentivized by tasks to define, oversee, and moderate all aspects of the Incubator ways of working. Directors are responsible for posting funding proposals to the network, holding and moving funds, managing the Incubator roadmap, defining strategy, and accepting Concepts to be funded.
Fund allocation and project management is decentralized across Admin users incentivized with a percentage of the JMES they award on Bounties.
Bounties are fulfilled by Users tasked with specifying, designing, building, testing and owning the end-to-end delivery of products that support the JMES Vision.
The Incubator is classified as an open-source JMES-funded organization, meaning all elements of the Incubator are conducted in the public domain at all times. This includes: how work is proposed; selected; specified; developed; tested; approved, which users are completing and managing work and what rewards are allocated and received.
All work (output) produced by the Incubator is open-source and MIT-licensed.
All handling and allocation of Incubator funds is publicly verified down to the user-task level in real-time via the JMES Blockchain.
Our Mission is to find, support and fund the most promising developers and entrepreneurs to build and grow the most innovative and user-friendly applications that maximize the use cases and utility of JMES.
Our Vision is to help grow JMES to become the number one cryptocurrency for Art and to support the JMES vision of having all Art on the JMES blockchain within 10 years.
Our Strategy is defined by our Funding Criteria coupled with a Roadmap that shows the priorities for Admins when allocating resources across Bounties. The Strategy ensures resources are focused effectively in support of our Mission and Vision.
Directors may accept Concepts for funding that meet the following criteria:
- Kickstarting, continuing, or supplementing the development of JMES software that grows JMES coin use cases, ease-of-use, and ultimate value.
- Funding the development and provision of tools and resources that aid developers and users working on the JMES blockchain.
- Funding development that improves onboarding for JMES users.
- Funding development that improves and sustains the Incubator itself.
- Funding JMES blockchain development.
- Funding JMES infrastructure service subscription, maintenance and moderation.
- Funding JMES core team contributions.
- Funding promotion of JMES features and products to developers and end-users.
- Funding the support of other JMES DAOs where doing so will expedite or unblock resources or products that our Mission depends on.
- Kickstarting initiatives that support and retain developers key to JMES projects.
- Kickstarting DAOs that support the JMES Mission and Vision but fall outside the scope of the Incubator's Strategy.
The Incubator will not fund bounties that don't meet any of these criteria.
Kickstarting means funding Bounties that initiate projects that include a plan to hand them off to 3rd parties to fund and oversee their longer-term development or maintenance.
Core Team contributions mean the Incubator’s core team's service funding for fixed-term contributions.
A Roadmap is included in each of the Incubator’s funding proposals and is used to prioritize projects and allocate resources across bounties.
To ensure the Incubator's processes and information remain fully open-source, the following criteria is set for all open-source classifications that the Incubator implements:
- All funding receipts and expenditure are tracked.
- All work systems and their data are public.
- All work preparation and its pricing are public.
- All work output is public.
- All work and rewards are verifiable.
- All rules governing the Incubator are public.
User credentials, i.e. logins and passwords, are exceptions and not included in the Incubator’s open-source classifications criteria.
There are several classification levels for Incubator Users:
- User - anyone who accesses the Incubator or its underlying data.
- Members - a User who has joined Incubator by creating an account on the Incubator Trello.
- Contributor - a Member who contributes towards a Bounty by completing and being rewarded for a Task.
- Admin – a Member with rights to create, manage and earn commission on Task rewards.
- Directors - Members who accept Concepts, define, oversee and moderate the Incubator’s ways of working, manage the Incubator roadmap, hold and distribute funds, and raise funding proposals on behalf of the Incubator.
Users may fall under one or more classification levels, i.e. Admins may also be Contributors and/or Directors.
All Members are listed on our Trello board, and Directors and Admins are indicated in the Description of the Introduction guide Trello card.
These Rules define the terms between JMES Incubator and Treasury and bind us to how funding will be used.
These rules allow anyone to audit how well the Incubator’s meeting its commitment terms in real-time. This includes the ability to verify the use of all funding on the JMES blockchain at user/task level.
The authoritative source of these Rules can be found in a single document hosted on the JMES World GitHub. Updates to these Rules are enacted as merged commits to the master branch and are taken into effect immediately.
The Incubator is an open-source application and not a legal entity and as such, doesn’t own any assets, including any rights to output, nor does the Incubator apply any restrictions on contributor's usage of their own Task output, apart from the requirement that all output must be open-sourced and MIT-licenced.
The only funding the Incubator receives is in the form of JMES coins issued directly from the JMES blockchain, which it redistributes to users who provide verifiable open-source output for predefined tasks approved by Admins, who agree to operate under the Rules defined in this document.
The Incubator does not handle, hold, or pay fiat currency. All rewards are issued in JMES coins as incentives for creating open-source output. All this is at the sole discretion of the Incubator Admins. There is no agreement or action to purchase or procure any assets, intellectual property or labor.
A Bounty in the Incubator means a collection of work that contributors can complete for rewards, such as developing or promoting JMES or building or maintaining the Incubator itself.
Bounties each contain a series of Tasks managed by the Bounty's Admin, who earns a commission % on all rewards that the Bounty generates.
All Bounties start as Concepts proposed to the Incubator by an Incubator Member. Concepts are proposals for work that provide detail about the value proposition, work requirements, and how the project would fit into the Incubators roadmap.
Directors can accept any Concept that aligns with the JMES Incubator Vision, Mission and Strategy.
Admins own bounties for accepted Concepts and have sole rights to manage and earn commission on their end-to-end delivery.
Each Bounty will be assigned one of the following Statuses:
- An ‘Active’ bounty is in progress. Tasks can be created, edited or completed.
- A ‘Maintenance’ bounty is complete and remains open to allow further processing of maintenance tasks.
- A ‘Backlog’ bounty is on-hold. No Tasks can be created, edited or completed.
- A ‘Complete’ bounty has passed its acceptance criteria and is archived. No changes can be made.
- A ‘Redundant’ bounty has been revoked and is no longer being taken forward as a project.
Directors have sole discretion to assign and change the status of a Bounty.
Three types of tasks determine how task completion will be met:
- A Standard Task is a once claimable task assigned to a single Member for a set deliverable.
- A Job Task is a reclaimable task by any Member for a set deliverable.
- A Service Task is a reclaimable task assigned to a single Member for a recurring service.
If the task is not a Standard task, the task description will be prefixed with the Task Type.
A Task is the basic unit of work in the Incubator and represents a unit of open-source output that a user can produce for a specified reward.
All work in the Incubator, and consequently any use of funds, is performed via the completion of a Task by a user, or the management of that Task by an Admin, within a specific Bounty.
Tasks are defined by Admins and can be completed by any user after reserving the task with the Admin, or in the case of Job tasks, completed without reservation.
Each Task defines quantifiable Output (a document, GitHub commit, service agreement, etc.) for a task to be approved.
Five categories of tasks are available within the Incubator:
- A Stakeholder Task provides product ownership input that contributes towards the final Bounty output.
- A Specification Task details functional and/or technical requirements that provide instructions for how further tasks should be met.
- A Design Task specifies the look and feel requirements for subsequent Production tasks.
- A Production Task meets the requirements defined in the Specification, Design, or task description.
- A QA Task verifies the quality and validity of a task.
Each Task Category is represented as a named Checklist on the Bounty’s Trello Card.
Stakeholder Tasks provide vision, direction and product ownership over any element of a product’s delivery.
By default, the Concept Creator is added as a Bounty stakeholder and a new Concept reward implicitly processed once the Bounty status has been set to Active.
The output will usually be a document or comment against the bounty detailing the Stakeholder’s input and wider interest in the project.
Specification Tasks define how further Tasks should be completed and/or QA'd. Alternatively, a Specification Task could be for the output of a research exercise to recommend a solution that requires further analysis - including verifying the validity of the Concept itself.
The output will usually be a document created via the Incubator’s Specification template – found under the Tools and Resources Trello card.
Design Tasks define the look, feel, branding, and marketing requirements for Production tasks.
The output will usually be wireframes, Figma designs or style and branding guidelines.
Production Tasks are the actual output of a Bounty that delivers the value proposition.
Output is usually Pull Request (PR) to the JMES World GitHub or a working product.
Quality Assurance tasks verify the quality of a task meets the specification and/or design.
Output could be a peer review spot check, comments in a document or the output of executing a full suite of predefined tests.
The output will usually be a document created via the Incubator’s QA Report template – found under the Tools and Resources Trello card.
A claim is the process of a user signaling they’ve completed a Task and wish to receive the Task's reward.
Users can claim tasks via the Claims Process from the Admin when they believe the task is complete.
Once a Task Claim is approved by an Admin, the Task Reward will be awarded to the user's JMES address within 7 days.
Each type of Task the Incubator offers has limits on the min/max reward an Admin may price as defined below. Directors can agree on task limit exceptions on a case-by-case basis. If an Admin needs to exceed the task limit, they will submit a request to a Director and add a comment to the Bounty’s Trello Card specifying the reason and subsequent decision.
The Admin % is an added commission reward that an Admin earns for Approving a Claim on a Task they own, plus a commission bonus based on the Admin's activity level.
Incubator is a pure-JMES fund, meaning all rewards are awarded in JMES.
| Task Type | Approval Criteria | Amount | Admin % |
|---|---|---|---|
| Concept Task | Concept accepted, Bounty created and set to Active | (j100USD) | 10% - 15% |
| Specification Task | QA or Admin check complete | (j10-j1000USD) | 10% - 15% |
| Design Task | QA or Admin check complete | (j10-j1000USD) | 10% - 15% |
| Production Task (Standard) | QA or Admin check complete | (j10-j1000USD) | 10% - 15% |
| Production Task (Service) | QA or Admin check complete | (j10-j10000USD) | 10% - 15% |
| Production Task (Job) | QA or Admin check complete | (j10-j500USD) | 10% - 15% |
| QA Task | Admin check complete | (j10-j500USD) | 10% - 15% |
Contributing to the Incubator involves completing Tasks on Bounties to earn Rewards.
A reward can also be earned by proposing Concepts. for new Bounties - awarded once accepted by Directors and assigned a status of Active.
Anyone can create a Concept by signing up to the Incubator and submitting a New Concept via the instructions defined against the New Concept Trello card.
A Director can accept a Concept that meets the Concept Acceptance Criteria defined in these rules.
To chat with Directors about a Concept or its acceptance, join the JMES Team Discord and ask on the #jmes-incubator channel.
Job Tasks on Bounties are open to being claimed by anyone without needing to reserve the task.
To claim a reward on a Job task, use the Claims process.
Any tasks other than Jobs can be reserved. This means that you can agree with the Task's Admin to have exclusive rights to claim the Task until the due date.
To reserve a task, contact the Bounty Admin to discuss your suitability for the task and to negotiate the reward.
Once you’ve completed the work for a Task, you can claim the reward on the Task by adding a comment to the Bounty’s Trello card with the following information:
- Tag the Bounty Admin and claim the task [@samkirby22 claiming Production Task 1]
- Link to the source for the task's output (specific PR, commit for GitHub code, Gdoc etc.)
- Link to any deploy links relevant to the output (e.g. a URL for a website)
- Specify a valid JMES address to receive the reward, or set to NULL to decline the reward.
Once your Claim has been created, an admin will process it within 5 days – approve, decline, or mark it as pending a QA review.
If a claim isn't made by the due date, the Admin can extend the date or has the option to cancel the reservation.
In some cases, Users or Admins may wish to decline rewards. Nullifying Claims is strongly discouraged as incentives ensure the Incubator maintains a high level of creativity, productivity, and output quality. Claims themselves are how we track and account for work completed.
Users who wish to decline rewards will make a Claim to signify and enable tracking of a Task's completion but set the claim's JMES address to 'NULL' along with a reason the reward was declined.
Directors are a third-tier of users in the Incubator incentivized to manage and ensure the Incubator continues to meet the Mission, Vision, Strategy, and Roadmap the Incubator is funded on.
Directors represent a decentralized layer of users who manage the Incubator's ways and workings, manage the Road Map, accept / activate projects, hold and move funds, and post proposals to the network for funding.
Directors can simultaneously act as Contributors by completing Tasks set by Admins. They cannot price or reserve Tasks for themselves.
Directors have the right to appoint and remove Admins, other Directors, and to maintain the Rules defined in this document, which explain all aspects of how the Incubator will operate.
Bounties are created by Directors after accepting a user-submitted Concept.
A Bounty is only created from a Concept approval, and all Bounties must refer back to a single Concept.
A Director can Accept a new Concept but must first validate it meets our Concept Acceptance Criteria.
Directors do not need permission from or consensus between other Directors to accept a Concept.
Directors can submit new Concepts themselves, but need another Director to Accept them.
Once a Concept is Accepted and assigned as an active Bounty, an implicit Claim for the Concept Task reward is considered to be approved automatically.
In Trello, Directors formally Accept a Concept by creating a new Bounty and linking it in a reply against the user's comment on the New Concept card.
Directors must judge that the Concepts they wish to Accept meet all of the following criteria:
- Provide a clear Value Proposition that can return value to JMES that aligns with our Vision and Strategy.
- Provide enough detail on requirements to enable a Bounty to achieve the stated goals.
- Be technically feasible within the JMES ecosystem.
- Be unique within the existing set of Concepts & Bounties already added to the Incubator, i.e. not a duplicate or very similar scope to an existing active Bounty.
- Be achievable in terms of costs compared to the Incubator's current funding levels.
Concepts that do not have this criteria will not be accepted.
Bounties are created exclusively by Directors who accept a community-submitted Concept.
Directors ensure the following information is correctly configured on new Bounties they create:
- The Concept the Bounty was created from is linked in the Concept Doc field.
- The Description text reflects the Value Proposition of the related Concept.
- The Concept creator is listed as a Stakeholder.
Once a Bounty is created, the Director assigns it an Admin, sets it to Active or adds a Status of Backlog for assigning at a later date.
Admins are a second-tier of users in the Incubator who are incentivized to manage Bounties by earning a commission on all Tasks completed within the Bounty.
Admins represent a layer of users who control a share of the Incubator's funds used to create and manage bounties that incentivize Contributors to produce output for the Incubator.
Admins can simultaneously act as Contributors by completing Tasks set by other Admins, but they cannot price or reserve Tasks for themselves.
In Trello, Bounty ownership is designated by a Director adding the Admin user into the Admin field of the Trello card.
The Admin assigned to a Bounty is given the rights as the Owner of that Bounty, also known as the Primary Admin of the Bounty.
The Bounty Admin has exclusive rights to define Tasks and process resulting Claims. Directors have exclusive rights to edit the Bounty's fields and change the Bounty's Status.
The Bounty Owner may transfer ownership to another Admin at any time.
The Bounty Owner can optionally appoint a Secondary Admin to the Bounty, enabling a maximum of two Admins to manage a bounty at one time.
Secondary Admins can create Tasks for the Primary Admin within the Bounty, process Claims on those tasks, and receive their Admin reward. This enables multiple Admins to manage and complete Tasks on a single Bounty.
The Bounty Admin can transfer the Secondary Admin to a different Admin at any time, or remove the Admin altogether. The removed Admin will retain control of any Tasks they owned on the Bounty.
Secondary Admins can leave a Bounty or transfer the position at any time.
In Trello, Bounty Admins can appoint Secondaries on a Card by entering their name in the Secondary Admin field and assigning them as a Card Member.
Admins can create Tasks on any Bounty they're the current Owner of.
When creating a Task, the Admin sets the Description, which must provide enough information to allow a Contributor to complete the work. This detail will be either in the task description itself or in a linked Specification.
The due-date set on a task is the date whereby if a Claim is not made for the Task, the Admin has the option to cancel the task or reservation at their discretion.
When defining a Task in Trello, the Admin will choose the correct Checklist for the task category, and specify the following information:
- A Task number, which is the sequential number of the Task in the relevant Checklist.
- A Description summarizing the general requirements by a short definition and a link to a Specification to provide further detail if needed.
- An amount of JMES for the Reward. This can be negotiated between the Admin and prospective users.
- The name of the Admin who created the Task (if not the Primary Admin).
When reserving a Task for a user, the Bounty Admin will specify the due date and assign the Trello user as the member on the Task.
The Bounty Admin will enter the following information into the Task description in the following format:
[AdminUsername] - [taskNumber]) [taskDescription] [amount]JMES)
Example
@samkirby22 - 1) Define this task description - 100JMES
When either the Primary or Secondary Admin defines a Task, they become the Owner of that Task.
A Task owner has exclusive rights to:
- Edit or complete the Task.
- Process Claims on those Tasks and receive the Admin reward.
- Transfer Ownership of the Task to another Admin.
Optionally, the Admin can set Task ownership to 'Open' by omitting their name from the task description, allowing the other Admin on the bounty to process the claim and receive the commission reward.
If an Admin leaves a Bounty, the leaving Admin retains ownership of their Tasks until they’re completed, or they decide to transfer the ownership to another Admin.
If a Task has an unprocessed Claim for more than 5 days with no response to the user from the Admin, the other Admin on the Bounty or a Director Admin can take ownership of the Task to process the Claim and receive the commission reward.
On Trello, Admin ownership is designated by the Admin user's name in the Task description.
Any Task without an Admin username in the description is considered 'open', meaning the other Admin on the card can process it and receive the reward.
Pricing Tasks in the Incubator take a different and more flexible approach to traditional sourcing methods. Incubator pricing factors in externalities such as priority, time constraints, skills availability and productivity incentives; whilst factoring out notions that don’t help us achieve the value we want to deliver.
If Tasks are urgent or highly specialized and resources are unavailable, or Tasks have existed for a long time without uptake, higher rewards can be set to achieve uptake. Alternatively additional tasks can be set for promoting Tasks and/or placing the necessary resources. This can result in rewards for delivering output exceeding traditional "market rates".
Low-priority tasks with multiple resources already on-boarded and available without time constraints can often provide output well below "market rates".
Tasks will be priced via a process to discover the minimum reward level needed to incentivize a Contributor to deliver something and decide whether externalities such as needing to find and onboard the necessary resources or meet a particular deadline need to be factored in based on the Bounty's priority.
Fiat prices will be considered when a Task is created, but Tasks will not be reduced in price if the Fiat value changes.
Except for Job Bounty types, Admins must reserve Tasks to a specific user for the Task to be considered Active.
Admins can arrange reservations and negotiate the Task's terms with the user within the Bounty comments or via private communication. Once the Task is reserved for the user, the terms are considered agreed and are public information.
On Trello, Tasks are represented on category checklists on the Bounty's Card, and are reserved by setting the Member setting to the user who reserved the Task and a date in the Due Date field.
When a user completes a Task, they create a Claim that the Task Owner Admin needs to process to decide if the Claim can be Approved, if QA is needed, or if there are issues that need to be resolved.
Approved Claims on Tasks go into the Awarded Claims List, from which the reward will be sent to the claimant within 7 days.
Initial decisions on whether output meets the requirements specified in the Task definition are at the discretion of the Admin who owns the Task.
If a Contributor wants to dispute a Claim decision, they can ask for a second opinion from a Director or the Bounty’s secondary admin.
In Trello, Admins can Approve a Claim by ticking the Task's Completed checkbox, adding a green tick against the claim comment and adding a subsequent comment against the Bounty as follows:
@[Trello ID] Claim Approved for [checklistName] [task ID] - [amount]JMES)
For example:
@developer 1 Claim Approved for Production Task 1 - 100JMES
Admins then enter the details into the JMES Incubator rewards database, filling in all columns and double checking the user’s payment address and reward amount to enable the claim to be awarded.
Admins are incentivized via a baseline reward as a % commission on all claims they award on Bounty Tasks that they own, using the rates defined in the Price List, plus additional commission bonuses for the most active Admins.
Admins can earn additional rewards by completing Bounty Tasks themselves, provided they’re defined and approved by another Primary or Secondary Admin on the Bounty. Admins can't set and price their own work, but they can set and manage work for other Admins if needed.
Admin rewards for commission on tasks don't require formal claims. They are issued automatically to a Bounty Admin when the associated Tasks are awarded via the Awarded Claims List.
Admins can also opt to decline rewards by creating a Null Claim on their commission within a Task Claim.
To set a Null Claim on their Commission Reward, an Admin will enter their JMES address as 'NULL' in the Claim in the Awarded Claims List.
Each Admin's commission is variable based on the number of Tasks they Approved within the previous 30 days (including "today"). The commissions Admins can earn are tiered as follows:
| # of Claims Approved | Commission |
|---|---|
| 0 - 14 | 10% |
| 15 - 29 | 15% |
| 30 + | 20% |
Each Commission Bonus is based on the Tier that the Admin’s previous 30 days contributions fall into. The "next" tier of commission is effective immediately once an Admin crosses the threshold, and is effective for all claims as long as the Admin stays within the Tier.
Directors are responsible for the Governance of the Incubator, which is implemented via appointing or removing Admins, other Directors, updating these Rules, holding and moving funds, and submitting Proposals for funds.
A quorum is required for all changes not unanimously agreed, meaning that > 50% of Directors agree for the change to pass. Changes are considered passed and in effect once the voting threshold has been met. Directors are responsible for notifying the community of all changes passed within 24 hours and submitting a change to these Rules within 7 days.
The following Governance responsibilities will be assigned to Directors via Standard or Service Tasks:
- Holding and moving funds.
- Submitting proposals for funding to the treasury.
- Managing the Incubator Infrastructure.
The following responsibilities will be assigned to Directors or contributors via Standard or Service Tasks:
- Managing the Incubator Road Map.
- Managing the Incubator Strategy.
Directors are granted some ‘super-user’ rights:
- Appoint or transfer Primary or Secondary Admin positions on a Bounty.
- Change the status of a Bounty or some of the Tasks.
- Appoint or remove Admins from the Incubator.
- Create Tasks on bounties when Primary/Secondary aren't available.
- Any other action to enforce adherence to these rules.
In all cases, a Director quorum must be reached and a comment added (e.g. on Trello or GitHub depending on the action) detailing the action and explaining the reasons as to why an action was taken.
Incubator is funded from a series of Proposals submitted to the JMES Treasury on a quarterly basis. All spending of those funds is commissioned and tracked via Tasks owned by Admins within the Bounty System and settled via transactions on the JMES blockchain that anyone can verify.
Depending on the Incubator Road Map, the amount requested might vary to target the broad scale and buffer that Directors feel the Incubator aims to spend.
When projects arise that require specific additional funding, individual proposals will be raised detailing the value proposition and estimated costs of those projects individually.
All funds will be received to the published Incubator multi-signature wallet address and will be immediately available to Admins to allocate to Tasks.
The funds requested from the JMES Treasury are purely to increase the Incubator wallet and increase the overall budget available for Admins to spend.
The Incubator is a pure-JMES fund, meaning that rewards are denominated only in JMES. Therefore any fluctuations in the fiat price of JMES will only reflect the pricing of new Tasks by Admins, and prior agreements made in JMES are not necessarily renegotiated or adjusted.
As an Open-source DAO, anyone can perform a full public audit of the Incubator at any time to check that all work is being conducted as per these Rules and verify the rewards issued to individual Incubator users for that work via the JMES blockchain.
Below we provide guidelines on how to audit the Incubator from a financial and work perspective so that people can devise their own audit strategies as they deem fit.
Every JMES of funding spent by the Incubator is accounted for via a Task Claim approved by an Admin with an associated transaction on the JMES blockchain. Total funds can be verified on the JMES Blockchain tally to total the task claims awarded in the Awarded Claims List. The verification will ensure funds aren't being spent from the wallet arbitrarily by validating that the total funds spent via the Blockchain equal the total JMES sent minus the total JMES received from the Incubator Wallet.
Each Task lists the transaction ID, which can be parsed individually to verify the total amount.
All work is conducted in line with the Rules in this document and the public domain. Anyone can audit how well the work is being conducted and how it's adhering to these rules at any time.
As guidelines, the following aspects of work are key to ensuring the Rules are being implemented effectively:
- Directors are moderating these rules fairly.
- Admins are pricing work fairly.
- Concepts being approved are in line with the Strategy.
- Quality of output is sufficient for rewards.
- Task deadlines and due dates are being managed effectively.
To satisfy our full transparency requirements, below are links to resources needed to access, fork, or audit every aspect of the JMES Incubator.
Resource: JMES Incubator Trello
Discussion: JMES World Discord