Amazing proposal!! 
Looking forward to have a podcast on the community 
A minor feedback about the initiative 08 - Facilitating Smart Contract Based IPFS Pinning.
- Deployment Documentation : Publish in-depth instructions and documentation for deploying this architecture and integrating it with Aragon DAOs and/or organizations.
I think that finding a way to generalize this process would be really useful. Maybe having a deployment_changelog file for every content make sense 
@Aaron thank you for taking time to review our proposal and also diving into the research topics! One thing to note is that these are research topics and I wonāt have concrete answers right away, as they need more research 
ā so itās a bit brainstorm-y!
One idea is building a system that caters towards companies that would like to pay a subscription fee and donāt need all of the decentralized features right away. Instead of files being hosted on IPFS, they are hosted on centralized servers. Login flows will be more similar to exchanges where you can login with a username/email address and authenticated via an authenticator app.
I havenāt talked about this idea that much with our developers and honestly donāt know how much work this would involve, as itās kind of like skinning aragon and wrapping it around another beast
It would still use blockchain and ACL, but it even may be a private blockchain with the organization running their own nodes.
This really goes into āenterprise blockchainā territory. If we do go down this path, Iād prefer that the customers we cater toward and target have aligned values, like nonprofits that want to increase their efficiency and coordination with other nonprofits and have budget to pay for tools.
Even if there isnāt a profit model behind this, I think there are some of these ideas that can help with onboarding in general (not needing any cryptocurrency to start interacting with Aragon).
Cent.co has made it so you can start participating in the platform without having a wallet, where you can sign up with an email address, and you only need a wallet when you want to withdraw crypto you have earned.
Thank you for this feedback! It is definitely on our list to have the Open Enterprise documents as soon as possible, and we will have it out for our Mainnet release. This research question had more to do with general questions that come up in aragon.chat in #dev-help
Yes, the ideas you mention would be closely aligned. I still donāt think chat has been fully solved. And I personally lean toward trying to integrate with Status or utilizing their technology as opposed to centralized tools or building something new from the ground up. The reason we are thinking about this has to do with reducing friction for people participating in an organization (or even starting one up).
Right now many in the Aragon community are using Keybase, which is awesome for encryption, their features allow cross-team collaboration better than discord, rocket chat and slack in ways due to the way they manage teams (which is closer to riot), the UI is pretty clean and itās fast too (compared to riot).
But there are no favoriting capabilities (like riot) or ways to have custom privacy for channels within a team (like slack allows) or easy ways to archive channels. It also doesnāt have Slack-like capabilities with webhooks, threading.
We know those features are important, so which platform should be built up to support blockchain-hooks for Aragon, webhooks, and enhance the general UX so it satisfies a team of 2020s needs?
Basically the (close to) perfect chat platform still doesnāt exist, even though we know technology supports what that looks like. There is also no clear indication if anyone is going to ever make it work. It sucks because everyone spends the most time on chat whether itās with teams or private messages.
Chat is definitely a big undertaking. We donāt think we will have time for developing any complex chat tools in this cycle, but are interested in doing user research to see what communities are ultimately looking for in the next 4 years. I personally would love to eventually deliver an awesome, decentralized chat solution or collaborate with an organization to bring that to life. I feel like after using Discord, Keybase, Riot, Slack, RocketChat we all must have a pretty good idea of what this looks like.
We wouldnāt be able to contribute to bringing delegate voting to life until September, but want to help with the cause! I wonder if Aragon One will need any of our frontend or design help by then? cc @luis
Thank you for all of the feedback and support Aaron!
Podcasts all around, to spread the Aragon gospel!
This idea came up organically from our newest addition @jayalaves, and he didnāt know Aragon One had a podcast.
I think I saw a Tweet recently that was like āWho even are you if you donāt have a podcast in 2019?ā 
More help is always welcome! We are still in the ideation phase, but I think design reviews (as Paty and you are doing lately) would always be helpful
I really appreciate that this proposal has come (relatively) early, and that it has a lot of detail! The rebranding of TPS to OE is a huge highlight and a great move 
!
However, Iām a bit conflicted with the general direction this draft proposal has gone in.
I really like I01 to I05 and I08; they are aligned with what Autark has been working on and feel like natural progressions. We have a few similar items in A1ās roadmap in the coming months related to I03 and I05, either published (that may not have been obvious) or are top-of-mind, and Iām interested to see how our underlying motivations might be similar and different.
I also like I06 a lot: the more experimentation the better, and although A1 has a number of governance approaches weād like to research and implement, thereās no way weāll be able to give them all justice (and itās very likely weāll have different sets of key users compelling us to create different mechanisms).
I07 is a great initiative to bring up, but it may not make immediate sense to include yet as most of the technical details are downhill and simply need some dedicated time to implement across the board. The biggest work involves the Aragon client (for now), and is something A1 would likely be able to do much more efficiently (for now). I also donāt think introducing a DAO to help translate text is a necessary step yet, but hosting the information in a decentralized way (e.g. metadata DAO) is important. Research into right-to-left layouts may also be premature for now.
I sum I01 to I08 to:
Again, these fit well and seem like natural progressions from the current Flock period. I wouldāve liked to see the current I01 make an re-entrance, as there is still a lot of work to be done in this regard.
The other initiatives, I09 to I13, seem unnecessary to define for a Flock team.
For example, I10, I12, and I13 sound like tasks a Flock team should be making efforts towards anyway. Theyāre important to the general success of a Flock team itself, irrespective of their ties to the Aragon project. To me, these are things that should just be done, rather than proposed or included in a roadmap (unless the entire point of the proposal is to do a series of AMAs).
I09 sounds like a great experiment, but may either be too early or, again, could just be done and reported during normal operations.
I11 is also great to bring up, but its language is incredibly constrained. If there is something that would greatly improve the AGP process such that a team would re-arrange its own internal priorities (as A1 does on a semi-rare basis based on feedback), it sounds like a Pretty Big Deal and acceptable that a Flock team decided to shift efforts to support rather than requiring an explicit up-front budget.
Personally, Iām primarily interested in seeing what direction a Flock team wants to head in based on its product deliverables. I think I09 to I13 distract from that, as things that would happen anyway in Flock teams. Another point of interest is that I09 to I13 make up almost 50% of the projected capacity, but honestly A1 likely operates at a similar make up of output.
Incredible feedback Brett! All of us really appreciate you taking the time to read through our long document and to evaluate the initiatives we want to work on for the next year. We know youāre really busy - please let us know if youād rather discuss any of this over an AMA that we are targeting for the end of the week.
I wouldāve liked to see the current I01 make an re-entrance, as there is still a lot of work to be done in this regard.
We totally agree that there is a lot of work to be done here, and itās something we donāt plan on abandoning! Do you think itās important to call this out as its own initiative again?
We figured working on other initiatives would cause this work to happen anyways, but if you feel there are specific deliverables youād like to see us working on and identifying in our proposal, weāre open to adjusting.
I07 is a great initiative to bring up, but it may not make immediate sense to include yet as most of the technical details are downhill and simply need some dedicated time to implement across the board. The biggest work involves the Aragon client (for now), and is something A1 would likely be able to do much more efficiently (for now).
Weāre really excited to work on internationalizing Aragon because itās something Aragon promotes and users have asked for. When do you think the client enhancements would make it to Aragon Oneās roadmap? Is there any way we can help without getting in the way?
I also donāt think introducing a DAO to help translate text is a necessary step yet, but hosting the information in a decentralized way (e.g. metadata DAO) is important. Research into right-to-left layouts may also be premature for now.
Could you shed more light on a metadata DAO and its differences from a ātranslationā DAO? I checked out the URL for the metadata DAO, but would love some more info.
I feel that at least having some infrastructure in place is a good first step towards enabling Aragon translations. From my experience working on global products at Oracle, internationalization is both an ongoing and long-term process, so in my opinion - the sooner we start, the better!
The other initiatives, I09 to I13, seem unnecessary to define for a Flock team.
For example, I10, I12, and I13 sound like tasks a Flock team should be making efforts towards anyway. Theyāre important to the general success of a Flock team itself, irrespective of their ties to the Aragon project.
Itās great to hear you think I10, I12, and I13 are tasks Flock teams should be working on. Do you think we should take them out of the proposal? Originally we included them to illustrate how we plan to use real data to make decisions and adjust our roadmap. We are curious to hear other peopleās thoughts on this as well.
We were inspired by how the Aragon One Flock proposal included focus points like āMaintain developer documentationā, āAragon Communityā, and a few others.
Alternatively, maybe there is a better way to outline our initiatives since they definitely differ from I01-I08.
I09 sounds like a great experiment, but may either be too early or, again, could just be done and reported during normal operations.
Good points. However, weād like to know for sure if itās too early to pull something like this off - and if so, why? Do you have ideas about why itās too early?
We prefer to keep this explicitly stated (as an initiative or maybe something else?) because we foresee this taking a substantial amount of time, and think itās important in informing us of current system restrictions and potential business models to sustain us in the future. In an ideal outcome, we could use these learnings and strategies to self sustain Autark, build features for Aragon without using the treasury, and add value to the network.
I11 is also great to bring up, but its language is incredibly constrained. If there is something that would greatly improve the AGP process such that a team would re-arrange its own internal priorities (as A1 does on a semi-rare basis based on feedback), it sounds like a Pretty Big Deal and acceptable that a Flock team decided to shift efforts to support rather than requiring an explicit up-front budget.
We completely agree. From our perspective (and why the proposal might feel more āfluidā), we want to find a balance between having a clearly defined roadmap and being able to adjust to the incoming (and sometimes unexpected) needs of the community. There are certainly many other tasks we could work on instead of I11, but how do you think the community would respond if we suddenly adjusted the roadmap to build something different? Would that give a bad impression or would we lose peopleās trust (especially as a newer Flock team)? How can we find the right balance?
Additionally, there arenāt any clearly defined steps to how a Flock team can alter a roadmap to respond to community requests. If there is a norm to adopt on how to handle roadmap adjustments, then maybe itās something we can talk more about in a separate forum post?
I also totally understand what you mean about it sounding constrained. We were giving minimums and also the freedom to evaluate on a ācase by case basisā if more than that is needed. We think the minimum is pretty low cost. Is there a better way you think we can frame this section if we kept it? Do you think itās dedicating too many hours?
Personally, Iām primarily interested in seeing what direction a Flock team wants to head in based on its product deliverables. I think I09 to I13 distract from that, as things that would happen anyway in Flock teams.
Do you think the way I09-I13 is written is a distraction in how the proposal is written? Do you feel like we havenāt outlined a sufficient roadmap in I01 - I08?
Another point of interest is that I09 to I13 make up almost 50% of the projected capacity, but honestly A1 likely operates at a similar make up of output.
Haha true this is where our percentage process breaks down. The work budgeted for these initiatives also includes the full-time capacity of three non-technical team members. It is close to 50% of the projected capacity of the team, but not of the developers. Do you think this is confusing and we should just remove this breakdown from our proposal? We were having second thoughts on if it may lead to confusion.
i agree, they are things teams should be doing but i like the fact Autark have stated what they will be doing in this regard, especially
10 - Driving Ecosystem Development
Research, identify, and onboard worker-owned and mission driven organizations.
its not clear that this has been a priority for any flock team, which is understandable as it may have been a bit premature up to this point,
Other than hack.aragon.org (which is an excellent resource) there is limited documentation for aragon apps and how to wire them together to support different use cases. Also #dev-help is great, there is always someone around to help with specific questions but AMA sessions would really compliment this.
I would like to see something like proof of impact added to the DAICO fundraising app. So linking the fundraising App with the Bounty App. https://blog.wetrust.io/cryptounlocked-oracle-upgrade-5c8b22e3375b
This could also create another usecase for the ANT token https://realit.io/
it would be nice to have an auction like voting system to figure out a market value for a certain bounty task so projects can compare their bounties to others to set a correct market value for their bounties.
It would be nice to have a modula chat app like lego where you can add and remove features (apps) to it so every community can create and adapt their chat like it fit best
It would be nice to have to option to create DAO alliances / DAO Working Groups / DAO Hub where DAOs can agree on certain values, rules and principles.
It would be nice to be able to create more then one token and also choose whether it is a token / coin / reward point / security / NFTs etc. So I can add for example a karma system like reddit into my DAO.
It would be nice to have a Milestone App within Aragon so I can follow the progress easy of a DAO and those Milestones are then linked to the Bounties so I can check the progress on github or other sites.
It would be nice to add services like 0x, uniswap , kyber or other dezentrailised exchanges directly into the finance app
It would be nice to link DAO Roles to an ethereum address / social profile
It would be nice to have the option of anonymous voting not only pseudo anonymous.
It would be nice to have Pro / Contra arguments which can be up and downvoted under polls.
It would be nice to have the option for old people and kids to klick on a button to make the interface much easier to handle more icons bigger font etc (easy interface).
https://storj.io/partners/ Introducing Economic Empowerment for the Open Source Community ( Finding business models that work for open source teams). Perhaps also working with swarm.city to build a decentralized carsharing app where swarm.city is offering the marketplace and aragon for the swarm/DAO management where some % of the revenue will flow into the DAO.
would be nice to have a app like https://www.instabug.com/ which is implemented into aragon so users can make easy contribution to get user feedback.
are you going to create an bounty campaing where i see all the task of the flok proposal and also the option to contribute to them and see who contributed already to them ?
I would love to see next to the podcast video documentations of the progress where you present your finished updates or perhaps also present future possible updates.
It would be perhaps nice to have the option in DAOs to select them as āonly voting DAOsā so that functions like deposit funds get deactivated automatically.
Would be nice to be able to search for DAOs:
would be nice if in the aragon governance the AGPs are marked as Finance/Association/Proclamation/Meta and weather it is in progress or has ended
Hello @Mouyou you have a lot of great ideas, and seems you keep editing your post to add more! We wrote our proposal in a way that focuses on higher level deliverables, meaning it gives us room to hone in on specific features during a discovery phase where we plan to perform user research to determine how we prioritize different features.
If you create a separate issue for each of your ideas in our repo here, then we can curate with more people in the community once we launch the DAO for that. I think some of these ideas will also be useful for other teams as well, as it touches a variety of products and applications.
To answer your specific questions:
are you going to create an bounty campaing where i see all the task of the flok proposal and also the option to contribute to them and see who contributed already to them ?
We will have bounties for people to help with different aspects of our Flock proposal, but we want to launch our Projects app to mainnet before this happens. It also takes significant product development work to ensure that we have a large enough backlog with the features fully specified and designed. The way that bounties work is that contributors donāt always complete the tickets on time inline with what a teamās sprint deadline is, so our strategy is to have a few lower priority tickets defined, and the number of these tickets we try to have in the pipeline will be based on how our open source community grows (e.g. how large the demand for bounties is, and how the quality of work is).
I would love to see next to the podcast video documentations of the progress where you present your finished updates or perhaps also present future possible updates.
Have you reviewed our monthly updates on our blog? Here is the link: https://blog.autark.xyz/
We share progress there, including videos. But doing this on a regular video podcast also sounds like a good idea as well! If we have low turnout in our AMA today, Iāll try to see if I have enough time to build the various repos locally for our newer work, but can also do a demo of Open Enterprise thatās on Rinkeby now too.
Thank you so much for sharing all of these ideas ā we will definitely add them to our research list as well!
Few announcements!
It will be tweaked and enhanced soon so itās more mobile-friendly.
I am having trouble with scheduling the livestream, so we will share the link here when we go live. If thereās low turnout we will do some video demos (thanks for the idea @Mouyou!) and talk about some of the different initiatives.
If you canāt make it, use the #AutarkAMA hashtag on Twitter, or submit questions through this form!
Our #AutarkAMA + live product demo session has just started on Jitsi. Feel free to join and share the stream! Weāre ready for your burning questions on Autarkās vision and new ANV proposal 
Will this be recorded?
Yes, itās currently being recorded and will be published right after.
Just following up on this, weāve just published the AMA on YouTube 
https://twitter.com/autarklabs/status/1148135059297361920
While listening to your AMA I was thinking about the request users commit and I post my idea on github request
I started contributing to Autark one month ago and Iām in love with it. I just wanted to point out very quickly two thoughts that I got after re-reading the proposal:
I think Autark has the potential to become a pioneer in bounty incentives research. Gitcoin, currently the biggest bounty platform, uses the OpenBounties contracts, which lack critical features like counterparty risk mitigation. In order to address this, Gitcoin uses centralized techniques like limiting the amount of bounties people can apply to. Autark, on the other hand, can develop decentralized ways to mitigate counterparty risk such as deposits, delay penalties and dispute resolution.
I came across the perfect people to do ecosystem development with: platform.coop. These people provide tools for worker-owned organizations. They donāt seem aware that blockchains exist, yet they talk a lot about decentralization.
Lots of interesting ideas and resources here, thank you for sharing! Weāll definitely look into the mechanics that you describe here and openly report on exploring the possibilities.
Hey all! I just updated the link in the original forum post to point to the Flock repoās pull request:
The one change I made is adding the ANT package, and we were holding off on creating the PR until getting guidance on that. We are requesting a 487,500 ANT package, with 1-year cliff and 4-year vesting.
This will bring our total ANT awarded via Flock to 837,500 ANT, which is 50% of Aragon Oneās allocation, and we based our calculations on this communication/guidance by the Aragon Association. Feel free to read the pull request linked above that includes more details on the request.
Thanks again for all of the feedback everyone. @sohkai - I didnāt hear any further response from you to our follow up questions, let us know if you have anything else to add or feel strongly about adjustments.
IO1ā¦ We totally agree that there is a lot of work to be done here, and itās something we donāt plan on abandoning! Do you think itās important to call this out as its own initiative again?
I would say so, to give it as much weight as the other items in the new AGP. As youāve mentioned, itās not well defined what happens to roadmap changes or deferrals, but since the proposal includes resource allocations (up to 100%), I presume anything missing from those will not be done.
I would say there is still a long way to go for the original IO1, and we havenāt touched āmonolithicā / custom frontend applications at all yet, nor expanded forwarder options (which would need to be done at least within the year if they want to land in aragonOS 5).
Good question, and this is not something I can answer. The main pain point with this is likely that weāll need to stop working on other things in the client and just focus on getting the infrastructure in place all at once. Once thatās set up, we can work in parallel to implement the actual translations.
The metadata DAO simply controls the updates to the metadata, so in this case, the actual translation text (and most likely, just the radspec translations since they donāt change often). We could use the Projects app to bounty translations, but at the end of the day it may just be more efficient using a i18n service, especially one that can hook into each code change.
I think itās OK to leave them in the proposal, but Iād re-organize it so theyāre not seen as top level initiatives (similar to how we moved most of those efforts to the end). We donāt have exact standards on flock proposals, but I see the initiatives as primarily product initiatives, not community initiatives. That may not be what the community thinks though, and the added transparency around non-product resources is a nice touch.
Too early as it may be distracting from more important priorities right now. The effort involved in this initiative may be better spent somewhere else in the immediate term.
One of my complaints with the flock format is that itās hard to tell if something like this would still feel ātoo earlyā one year from now, but given that its allocation is 16%, I assume itās not something you would only start in month 10.
This would be useful as we set up more reporting / update protocols for flock teams. Especially as Autark is the first one to go through the renewal process and gauge community sentiment for their previous flock grant.
I think the line of thinking I had was that this should be an implicit responsibility for flock teams; the Association may ask flock teams to work on executing items from ANVs (as it has for A1 and Mesh previously). If that leads to severe performance degradation of the team, adjustments or additional funding can be compensated.
One of my main concerns was whether Autark had non-technical team members available. Perhaps a more useful budget would be to break down the team first into technical and non-technical capacity, and then forecast the initiatives onto those capacities?
