Update to readme.me and Flock docs #17
Conversation
| ## 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.
| *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.* | |
| *This section should detail the high level strategy and rationale behind the proposal in simple terms. It can be accompanied by a few short references to past team achievements.* |
|
|
||
| *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.
| *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!* | |
| *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. Technicality is not the only thing that matters!* |
| @@ -39,7 +39,7 @@ After the definitive approval of funding as per the AGP-1 process, funds for ope | |||
|
|
|||
| ## Decision rationale | |||
|
|
|||
| Decisions are made by the Aragon Association and representatives of the independent teams that are already part of the Aragon project. Everybody will participate in the review process. All decisions must be consistent with the [goals and values](https://github.com/aragon/AGPs/blob/master/AGPs/AGP-0.md) of the Aragon project and represent the interests of the Aragon community. | |||
| Decisions are made by the Aragon Association in a process which includes gathering opinions from members of the independent teams that are already full-time contributors to the Aragon project. Everybody will participate in the review process. All decisions must be consistent with the [goals and values](https://github.com/aragon/AGPs/blob/master/AGPs/AGP-0.md) of the Aragon project and represent the interests of the Aragon community. | |||
There was a problem hiding this comment.
| Decisions are made by the Aragon Association in a process which includes gathering opinions from members of the independent teams that are already full-time contributors to the Aragon project. Everybody will participate in the review process. All decisions must be consistent with the [goals and values](https://github.com/aragon/AGPs/blob/master/AGPs/AGP-0.md) of the Aragon project and represent the interests of the Aragon community. | |
| Decisions are made by the Aragon Association in a process that includes gathering opinions from members of the independent teams that are already full-time contributors to the Aragon project. Everybody will participate in the review process. All decisions must be consistent with the [goals and values](https://github.com/aragon/AGPs/blob/master/AGPs/AGP-0.md) of the Aragon project and represent the interests of the Aragon community. |
|
|
||
| ## 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.
| *List of aragon accounts, channels, tools, assets, domains and infrastructure that you need in order to operate* | |
| *List of Aragon accounts, channels, tools, assets, domains, and infrastructure that you need in order to operate* |
| @@ -29,7 +29,7 @@ The Aragon Association and representatives of the current Aragon teams will revi | |||
|
|
|||
There was a problem hiding this comment.
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.
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.
These are good points. I think we should further investigate what's proposed here to smoothen the process.
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.
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.
@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:
We strongly encourage Flock applicants to present their proposal at least 30 days before AGPs for the next vote are due...
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.
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.
This PR contains changes mainly to the docs section of the Flock repo. The templates.md files have been deleted, and the proposal.md has been enriched with a team section and several other elements.
The readme has been updated to highlight that team should apply at least a month before AGPs are due. The minimum grant amount required to apply has been changed from $1M to $300K.
Reviews both on format and content are very welcome.