This repository has been archived by the owner on Mar 2, 2020. It is now read-only.
Update to readme.me and Flock docs #17
+158
−55
There are no files selected for viewing
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,153 @@ | ||||||
| #### Introductory note | ||||||
| This guide can be used by Flock program applicants in order to draft their ideal **Flock Tragck AGP**. The structure and content of the proposal can be adapted as much as necessary by the applicant team. Above all, applications should be **clear and concise**. | ||||||
|
|
||||||
| Don't forget to share the proposal as early as possible with the [community](https://forum.aragon.org/). | ||||||
|
|
||||||
| # Aragon Flock proposal: Team name | ||||||
|
|
||||||
| ## 1. Summary | ||||||
|
|
||||||
| ### Strategy | ||||||
| *This section should detail the high level strategy and rational behind the proposal in simple terms. It can be accompanied by a few short references to past team achievements.* | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| *In case the applicant team is an ongoing Flock team it can add the previously achieved roadmap and its most recent community reports.* | ||||||
|
|
||||||
| ### Why us? | ||||||
| *In this part the applicant team should qualitatively explain why it is qualified to deliver the strategy outlined in the previous section.* | ||||||
|
|
||||||
| ### Working in the Aragon Community | ||||||
|
|
||||||
| *In this section, teams should succintly explain why their time is better spent contributing to Aragon.* | ||||||
|
|
||||||
| *Members of the Aragon community are united around the [Aragon Manifesto](https://blog.aragon.org/the-aragon-manifesto-4a21212eac03/) and values of openness, freedom and goodwill. While there are no requirements to refer to the above explicitly, teams are encouraged to speak from their heart. Technicals are not the only thing!* | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## 2. Deliverables | ||||||
|
|
||||||
| ### Projected capacity table | ||||||
| *This table aims at giving a visual summary of the applicant team's effort allocation over the different categories of deliverables.* | ||||||
|
|
||||||
| #### Example 1 | ||||||
| > | Category | Dev tools | Aragon apps | User experience | XYZ | | ||||||
| > |------------------------|-----------|-------------|------------------|-----| | ||||||
| > | Nb of deliverables | 2 | 1 | 3 | 1 | | ||||||
| > | Team effort allocated | 30% | 20% | 40% | 10% | | ||||||
|
|
||||||
| #### Example 2 | ||||||
| | Initiative | Projected Capacity (%) | | ||||||
| | ---------------------------- | ----: | | ||||||
| | 01 - Working on initiative 01 | 34 | | ||||||
| | 02 - Working on initiative 02 | 28 | | ||||||
| | 03 - Working on initiative 03 | 16 | | ||||||
| | 04 - Working on initiative 04 | 14 | | ||||||
| | 05 - Working on initiative 05 | 8 | | ||||||
|
|
||||||
|
|
||||||
| Note: there is no strict format required for the table. | ||||||
|
|
||||||
| ### Initiatives | ||||||
|
|
||||||
| *In this section, the applicant team should detail in concrete terms the different initiatives it is planning to work on. They should be listed by order of priority.* | ||||||
|
|
||||||
| For each initiative, the applicant team should cover the following items: | ||||||
| - **Value proposition** - *How it will provide value to the end user (i.e. developer or Aragon DAO user)* | ||||||
| - **Deliverables** - *What precisely will be implemented in to fulfill this initiative* | ||||||
| - **Background** - *A link to a Github issue, Flock roadmap item, Nest proposal, user feedback, or any other material backing the initiative's relevancy* | ||||||
| - **Long-term vision for initiative** - *This last item is optional and can provide more insights on future developments built on top of the initiative* | ||||||
|
|
||||||
| #### Example | ||||||
|
|
||||||
| *Here is an example of initiative inspired from a past Flock application.* | ||||||
|
|
||||||
| > ### I01 - Fundraising | ||||||
| > #### Value proposition | ||||||
| > The goal of this topic is to provide a library and a standalone dApp any Aragon DAO can use to raise funds through a Continuous Funding scheme. | ||||||
| > | ||||||
| > #### Deliverables | ||||||
| > | ||||||
| > **Fundraising library:** Develop a modular fundraising library providing low-level building-blocks: curves, taxation mechanisms, withdrawal mechanisms, etc. | ||||||
| > | ||||||
| > **Fundraising app:** Develop an opinionated but ready-to-use fundraising app - based on the previous library - implementing the [Apiary][link] scheme designed by [@lkngtn][link]. | ||||||
| > | ||||||
| > #### Background | ||||||
| > | ||||||
| > A PoC of such a fundraising app is already available [here][link] and demoed [here][link]. | ||||||
|
|
||||||
|
|
||||||
| ## 3. Grant Size | ||||||
|
|
||||||
| *Your estimated operating cost for successfully building the Aragon Project and the estimated ANT package that would be needed to incentivize the team's long term commitment.* | ||||||
|
|
||||||
| *Please also provide the payment schedule that would be requested.* | ||||||
|
|
||||||
| #### Example | ||||||
|
|
||||||
| *Here is an example of initiative inspired from a past Flock application.* | ||||||
|
|
||||||
|
|
||||||
| > ### Estimated operating costs for Q2 and Q3 2019 | ||||||
| > | ||||||
| > | Type | Description | Amount | | ||||||
| > | ----------- | :------------------------------------: | -----: | | ||||||
| > | Payroll | | \$Xk | | ||||||
| > | Contractors | DevOps \| Design \| Legal \| etc. | \$Xk | | ||||||
| > | Services | GitHub \| Google Suite \| Chat \| etc. | \$Xk | | ||||||
| > | Travel | Offsites \| Conferences \| etc. | \$Xk | | ||||||
| > | Equipment | Laptop \| etc. | \$Xk | | ||||||
| > | **Total** | | \$Xk | | ||||||
|
|
||||||
|
|
||||||
| > ### ANT package | ||||||
| > | ||||||
| > We would like to request **25k ANT per team member per year** for incentivization purpose, i.e. **125k ANT** for this six months long proposal. We are committed to the Aragon Network in the long-term and therefore accept a 4-years vesting schedule. | ||||||
|
|
||||||
| Note: Flock team ANT package policy is subject to change over time. Please ask the Aragon Association for more information. | ||||||
|
|
||||||
| ## 4. Team | ||||||
|
|
||||||
| *Below is the basic structure the applicant team should follow when creating a Flock proposal. It includes a brief description the current team members and their relevancy for the role, with links to relevant materials (github, twitter, projects, etc.) and provides info on future openings if the applicant team plans to hire more people during their Flock mandate.* | ||||||
|
|
||||||
| #### AraEagles Example Team | ||||||
|
|
||||||
| > - #### John Doe — Project Lead | ||||||
| > | ||||||
| > John has 20 years of experience coding Solidity. He bought Bitcoin in 1995, therefore inventing the blockchain. He admits to be the real Craig Wright. | ||||||
| > | ||||||
| > **Socials**: [GitHub](#) [Twitter](#) | ||||||
| > | ||||||
| > - #### Satoshi Nakamoto — Frontend Dev | ||||||
| > | ||||||
| > Satoshi loves React and React Native. He met John 5 years ago in a hackathon | ||||||
| > | ||||||
| > **Socials**: [GitHub](#) [Twitter](#) | ||||||
| > | ||||||
| > - #### Maria Garcia — Security Researcher | ||||||
| > | ||||||
| > Maria has been working on different projects in the Ethereum both creating and auditing smart contracts. She would like to work full time on pure research. | ||||||
| > | ||||||
| > **Socials**: [GitHub](#) [Twitter](#) | ||||||
|
|
||||||
| ## 5. Requirements | ||||||
|
|
||||||
| *List of aragon accounts, channels, tools, assets, domains and infrastructure that you need in order to operate* | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| | Access to | Yes/No | If Yes, precise what and why | | ||||||
| |----------------------------------------------------------------------------------|--------|------------------------------| | ||||||
| | Blog accesses | | | | ||||||
| | Social media accesses | | | | ||||||
| | Website accesses | | | | ||||||
| | Repo accesses | | | | ||||||
| | Unrestricted use of the Aragon trademark | | | | ||||||
| | Publish access to aragonpm.eth | | | | ||||||
| | Access to Aragon servers and cloud infrastructure | | | | ||||||
| | Access to Aragon DNS and ENS domains | | | | ||||||
| | Admin/moderator access on aragon.chat, forum.aragon.org, and /r/AragonProject | | | | ||||||
|
|
||||||
| ## 6. Organization structure | ||||||
|
|
||||||
| *Under what type of organization, if any, is the team organized.* | ||||||
|
|
||||||
| ## 7. Due diligence materials | ||||||
|
|
||||||
| *In a structured way, the applicant team is invited to provide links to materials that can support its Flock application. **This should include a risk assessment document**, where the Flock team details the main challenges and risks tied to its proposal.* | ||||||
|
|
||||||
| *These can also be links to projects, references, or any material judged relevant.* | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll have to think about how we can securely link the Flock proposal and supporting documents to the AGP. My preference would be that all of these documents live on GitHub, so we can reference docs by a link to the commit height as of the time of proposal approval by the AA and from there derive a SHA-256 hash to create a secure, auditable link to the doc.
Another question is whether the teams should create the AGP or the AA on the teams' behalf. It's kind of an awkward dance for them to submit the PR here, get merged by the AA here, then go to the AGP repo and create the AGP PR. As an AGP Editor I would personally prefer that Flock Finance proposals be submitted by the AA, so I do not have to second-guess whether they should be considered or not. (Currently I have to go to the Flock repo and check if the Flock proposal was approved by the AA, to avoid some awkwardness if I merge a Flock AGP that was not approved by the AA and then the AA has to reject the proposal during the AA review stage.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are good points. I think we should further investigate what's proposed here to smoothen the process.
Regarding the Flock application process in general. Should we increase flexibility regarding following the process and add something like "not respecting any element in the process could be sufficient for the Aragon Association to reject a given application". An example is if a team submits a proposal 25 days before AGPs are due, which may reveal to be enough time for discussions to happen, we may not want the process to break this application. On the other hand, if a team submits a proposal 15 days before AGPs are due and it looks like discussions with the community are not over and the proposal is far from being ready, we may want to let the AA raise a red flag pointing at the 30 days rule. This is just a thought I'm having here, there is probably a case stating this could harm the legitimacy of the process and give to much power to the AA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we can continue the discussion there in the AGPs repo as I think that is the right place, and we could solve both of the questions I raised if we more tightly integrate Flock with the AGP process.
@LouisGrx I will leave it up to you how flexible you keep the Flock application guidelines. I personally prefer the hard deadlines because it ensures equal treatment of all applicants, and also ensures that those proposals that are considered have adequate time for review. I don't like the experience where an applicant submits a proposal, there's a bunch of back and forth, and then the proposal is rejected anyways because there wasn't enough time to discuss.
But if you do decide to leave it flexible, rather than flagging the 30-day rule in such a case (which isn't really a rule since it is flexible) you could just rely on the fact that the proposal is simply not ready to be voted on.
So, you could say:
And when the time comes, it's up to your judgement to decide if a proposal should make it onto the final ballot or not. The standard for approval is then not whether the application was turned in on time, but whether it is a good application at the time AGPs are due. If it is not, and the reason is because the applicant submitted their proposal too late, well that is their own fault and they should have abided by the strong encouragement to submit earlier. But again I don't really like this UX from an applicant or a reviewer's perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, I feel that hard deadlines are clearer and less tricky to deal with. One good thing would be to make a bit more noise around the Flock application deadline and precise the dates for each voting cycle.