Aragon Network Vote #1 Megathread

agp
#13

I’d have to think about possible alternatives or a new way to signal what stage in the process we are in. It does say right at the beginning of the post:

The Aragon Association review period has officially concluded ! Here are the results of the AA review:

[results]

Now is the final community review period before the vote starts at 00:00 UTC on January 24th , lasting for 48 hours. All approved proposals will make it onto the ballot for a final vote by ANT holders.

So it should be unambiguous that these are the results from the AA review, not the ANT vote, and the ANT vote will start at the mentioned time and date.

#14

Amazing feedback! We will work on it so we can have a banner on the website soon. Thanks!

1 Like
#15

yes, my bad,
the capital [APPROVED] and [REJECTED]
coupled with my shaky familiarity of the AGP process,
and with the wording “concluded”
and with the fact that I handn’t read about the vote delay,
made me jump to the conclusion that it meant the vote was over and those proposals were approved or rejected :slight_smile:

2 Likes
#16

ok thanks for explaining, I’ll put some thought into how to make the communications easier to follow for people who skim when reading. in the mean time I recommend reading through AGP-1, which details each step in the process (noting that some aspects of it are currently under vote, so it may be slightly changed in a week).

1 Like
#17

AGP Positions

As a member of the Aragon Cooperative I’ve already signaled my voting intention for all of the Q1 AGPs (see above). I wanted to use this post to give a bit of context about my decisions and share with the community.

AGP-5 Aragon One Flock Proposal

Position: Yes

Justification: While I’m a bit apprehensive about the amount of funding and would have preferred the proposal be broken into two parts, one with modest team expansion, and one with additional funding to double the team size over the next year so that the community could make a more granular decision in the AGP process. As it stands there is just one proposal to approve or reject. The A1 team has worked really diligently to get us to the point we are at now, and you can literally create an on-chain organization for a few bucks in transaction fees on mainnet today. The proposed scope of work for the next year includes delivering the Aragon Network and Court which will make on-chain organizations much more compelling and extend the scope of ANT utility beyond just voting on AGPs. Based on the track record of the Aragon One team so far, I expect that expanding the team will result in similar quality of work and an ability to deliver even more, even more rapidly.

AGP-10: Community Funding DAO

Position: Yes

Justification: Even though I feel like this will be a failed experiment due to lack of a clear process for how people would request funding, how approvals would happen, how long votes would last, whether work must be completed before submitting a funding request or after, and many other smaller logistical details have not been detailed or discussed at all during the proposal process, the ammount of funding is small enough that I think as a community such a failure will still provide a lot of valuable insight into the coordination challenges associated with funding a bounty program. Hopefully those insights will lead to a more thoughtful proposal and discussion around community funding initiatives in the next AGP cycle.

AGP-11: Aragon Association Budget

Position: Yes

Justification: As much as it should not in the future, the Association plays a critical role in the Aragon projects operations today and I like the fact that the Association put forth an AGP to transparently define and get their budget approved, even though their privileged position in the current AGP process does not make it strictly necessary.

AGP-12: Aragon Holiday

Position: No

Justification: this feels silly and like a waste of time, while there really is no downside, I think rejecting this sets a tone as to the types of AGPs that should reasonably be put forth in the future.

AGP-14: Improved Voting Logistics

Position: Yes

Justification: These improvements seem like reasonable and minor tweaks to the AGP process that were driven by lessons learned after the initial AGP-1 ratification vote and leading up to the Q1 vote. Nothing seemed particularly objectionable, and I hope we continue to improve and refine our community governance processes.

AGP-16: Extend AGP Vote Duration

Position: No

Justification: This was a common request after the initial AGP-1 ratification, that the vote duration was too short. Personally I think 48 hours should be sufficient time for anyone to cast votes. The period is not intended to be for discussion or making up your mind–that should be happening continuously. I would much rather see us work to improve the quality of discussion/discourse/awareness prior to the vote period starting, then to extend the process in the hopes that more people will see the vote is happening and vote.

AGP-17: Nest 2019 Budget

Position: Yes

Justification: The nest program has been quite beneficial, and while the scope and focus of the program has changed a bit due to market conditions, it still feels like an important program to continue, as it has been responsible for incubating some of Aragon’s most significant community contributors. Eventually I would like to see it replaced with a more direct (and decentralized) community funding initiative, but I think we should start experimenting on a small-scale with those efforts through things like the Aragon Cooperative, and Community Funding DAO before discontinuing the Nest program.

AGP-18: AN Security Partner Authio

Position: No

Justification: I think the Authio guys have submitted a good, well thought out proposal, but I think the timing is bad. We just completed multiple expensive audits so the initial overall audit, while important for Authio to do to prepare for smaller ongoing audits is a bit poorly timed for the project. I would like to see this proposal rejected and resubmitted in Q2, as I think that may be a more appropriate time and would allow for more thorough community evaluation, and perhaps competing proposals from other auditing teams to be submitted as well. That being said I really appreciate the thoughtfulness and engagement that the Authio team has shown engaging with the community around their AGP.

AGP-19: Autark Flock Funding

Position: Yes

Justification: Autark is an extension of the TPS nest team, which although has been somewhat delayed, I think adds a specific set of functionality that is necessary for operating an organization on a day to day basis, where as the existing set of apps produced by A1 provide a strong foundation for securely managing an organization at a high level, being able to use the the planning suite to efficiently come to consensus on assigning work, evaluating completed work, and paying/rewarding contributors will be important for early adoption. If this proposal is not approved for flock, I would also be happy to see the TPS nest grant extended to support this teams continued development of the application suite.

8 Likes
Security Support until AGP Vote #2
#18

Here’s my breakdown on my vote for AGP-19.

AutarkCo/flock

AGP-19 - https://github.com/aragon/AGPs/blob/master/AGPs/AGP-19.md

Vote by: @jjperezaguinaga (Membership+Address, Signature)
Decision: Aye.

Notes

Questions

  • How are you going to lock the 350,000 ANT per each worker? What requirements are going to be in place to ensure that the cliff/vesting period is respected?

  • Do you have already something in mind for updating the current progress of the project? Weekly reviews, monthly showcases?

Further Notes

  • I’m particularly interested in poking at your Rich User Profiles topic. Identity is a big problem across the entire ethereum ecosystem, which I’m very keen to work on.

  • I’m unaware of what’s the current state of Colony, but last time I talked to them in DevCon4, they were auditing their project through bug bounties. They do have, nevertheless, a very interesting concept for reputation. They are very active in Gitter in case you want to check on them.

  • I’ve successfully imported your recipient Gnosis Multi-sig wallet, but I was unable to find which owner was related to each member of the Autark association. I’ve suggest on forking Aragon’s transparency portal or add public link tied to your Keybase (e.g. https://keybase.pub/jjperezaguinaga/) so anyone can see which address relate to whom.

  • This one was an easy one, and the vote was mostly for support, but I figured it would make sense to do a detailed breakdown nevertheless. Good stuff!

3 Likes
#19

Although there is no official proposal here, it is relevant information for voters to take into consideration.

4 Likes
#20

@jjperezaguinaga thank you for the questions and feedback… see my responses below! :slight_smile:

Relocating will not be a requirement and is not expected, as it would have been a more hybrid approach (one local team + other remote workers). Although recently I was reading that having a local team + a remote team hybrid situation may be difficult, vs. going all in on one strategy. But I have personally worked remotely for almost 5 years now. We can definitely determine the full logistics of how this would work by a follow on grant we will apply to in the summer, assuming AGP-19 is approved.

I’m relying on the Aragon Association for technical guidance on the locking process, as I assume they may be in control of that ANT coming our way. From what I understand of how the vesting works typically after the cliff period, is that the ANT will be vested on a monthly basis after that first year.

If a team member leaves before one year, they will not get their ANT. If a team member leaves after the 1 year period, say 6 months in, they will get the proportional ANT for 1 year + 6 months. At least this is how I assume vesting works for other teams, but I could be wrong. I propose that there should be consistency with how ANT vests, and am looking forward to hearing more guidance from the Association on this matter.

I’ve read earlier drafts of the colony white paper, and find what they are doing very interesting – and I’ve definitely learned from some of their concepts.

But I think how reputation is calculated should be flexible for the DAO to define, and as should the governance of how disputes work and who gets to vote on the disputes.

My opinion is that colony may be over engineered, because it adds a lot of administration within the DAO (with categorizing tasks and other things) and is somewhat opinionated with it’s governance model. I prefer building parts of a reputation system slowly and enhancing it over time.

So it makes more logical sense to me to have a system built within Aragon. Right now our initial goal around reputation is basically minting tokens. But if you can write formulas for these mint & burn processes, connect them to various actions and events – you can do some pretty cool things. I don’t actually believe in burning reputation (unless it’s a foul player), but I would prefer the history of someone’s reputation remaining intact, yet there can be custom ways a vote can be tabulated, that a vote can be weighted based on REPUTATION EARNED in a specified period (e.g. within the last 3-6 months). This way you don’t have to “decay” someone’s rep, but can ensure that the most active participants of an organization are driving its governance. Can you imagine your github commits decaying? That doesn’t make sense to me.

Let’s chat and collaborate! Also please chime in on our current brainstorm we have going on here on the forum. We are looking for the current “community consensus solution” that we will take into account during our initial discovery phase.

Re: multsig, the owner addresses are listed on the AGP – what link are you using to look up the owners? How does one inspect via the etherscan? Right now the multisig is the same one we have been using for our Nest grant, and it is linked in my keybase files.

We plan on doing monthly updates/showcases, and spending reports. For now I think it’s easier for people to just check our multisig balance every month against our spending report vs. having some fancy wallet interface. I just don’t like adding development feature creep in this short time frame, but happy to go forward with that operational procedure if someone else wants to volunteer their development time or if people think it’s a requirement to have that wallet interface during this 6 month period. I think a blog post that links the transactions and describes them based on the categories in our proposal makes the most sense as far as an MVP of financial transparency goes.

Thank you for the support, and for taking the time with your feedback and analysis. I really appreciate it. Looking forward to collaborating more in the cooperative as well :slight_smile:

#21

Updated the first post announcing that the vote has started and added a note about voting with raw transactions using MyCrypto if anyone has trouble using the Aragon client.

1 Like
made this a banner . It will appear at the top of every page until it is dismissed by the user. #22
#23

@lyricalpolymath thought you might like to see this :slight_smile:

2 Likes
#24

:wave: @stellarmagnet, thank you for taking the time of going through my rambling :relaxed: please allow me to comment a bit further on your answers.

Yeah, exactly my point. I believe probably might be better to allocate a budget for a quarterly retreat than trying on the hybrid approach, as I’ve had mixed experiences as well with hybrid setups. If the entire team has remote experience, then, by all means, carry on!

The most common setup is to release 1 year and afterwards monthly, but I was thinking more in which mechanism the team will “confirm” the person has left or continues being part of the organization. How will the org confirm someone is part of it, or vote that a person needs to leave? How can we enforce this?

From the token lock perspective, my team has been working on this topic for some time and came up with Trust (Contracts, App), which reflects a “legal” Trust where you can set money apart for a person given a specific period of time. If there’s enough interest, we can see how we can set this within Aragon cc @jorge. Otherwise, I’m sure there are smart contracts somewhere that can be signed through a Multi-sig to release this when needed.

I agree, it has been quite hard for me to get started with their stack, and I know their contracts have 10k+ LOC which made audits impossible. I also agree that it makes more sense to have a system built within Aragon, and the approach of token minting is just about fine.

Commented! If there is any place where we can discuss identity apart from the Aragon Coop group, I would be extremely happy :hugs:

Oh, you can go to the Online Gnosis Wallet and just add your multi-sig wallet by pasting the address. No need to build a fancy UI! It will read the owners and showcase all the transactions. I think the only thing missing is the owners of that wallet having a link to their keybases.

My company has the same setup and it would be nice to have a way to brand it the same way Aragon did with the multi-sig setup. I wonder how easy would be to do this for any project! But to avoid feature creep as you mention, I think the online one from Gnosis works fine for whoever wants to take a look.

Good stuff, and crossing fingers for a happy AGP outcome!

1 Like
#25

We will definitely have to put some though on how vesting contracts over vesting contracts can be done in a good way. Something @luis and I were discussing a year ago when we started thinking about Flock was to have each organization create their own token that is backed by the ANT that is progressively vesting (we use this contract for A1 vestings, after the cliff a proportional amount of tokens gets unlocked every block until they are all vested). So the flock organization token could have its own vesting schedule for employees, and that would allow to eventually convert for a proportional part of the ANT that backs the token.

1 Like
#26

New updates on AGP-18:

3 Likes
removed this banner . It will no longer appear at the top of every page. #27
#28

Suggestion: Instead of calling the vote cycles “AGP Vote #”, what if it was Aragon Network Vote #1?

E.g.: ANV-2 occurs in April!

Then it wont get confusing if one is referring to an AGP # or an AGP Vote #?

Does this need an AGP? :slight_smile:

4 Likes
#29

We could do a proclamation in the next round, but I agree on the naming convention so I am just gonna start calling it like that :slight_smile:

3 Likes
#30

cc @stellarmagnet

The nomenclature around the AGP process is still a WIP, I would be ok with referring to it as the Aragon Network Vote #x instead of the AGP Vote #x. We wouldn’t have to do a proclamation AGP (which seems a bit overkill for this, at least right now) but we could make it a convention used by the AGP Editors and communications teams by adding it to our style guide.

2 Likes
#31

Good to hear :slight_smile:

#32

Just want to highlight these amazing retro-future utopia GIFs created by Alexis Aiono to support AGP-19:

4 Likes