Thank you @lkngtn for all of the great questions and commentary. See my responses below!
Cross-Application User Experience
This seems to address a challenge associated with developing Aragon Apps. I would love to see some discussion related to the pros-cons, would these changes make developing Aragon Apps easier? would it make certain types of application or UX decisions possible that are not currently possible, possible?
For those unaware, Aragon apps are contained within the pink section in the image below, and there is a restriction of a one-to-one mapping between an Application and a contract. This means you are restricted to using a single solidity file for developing a single Aragon app. If you want to use two solidity files, this means that you have to create another app, and the way to access these functions will be by accessing this additional app via the left-navigation menu.
But thatās just not how software always works. It may be more logical for the additional functionality to be accessed within horizontal tabs that are located in the pink region, instead of vertical tabs in the wrapper region.
I think that from both a developerās standpoint and a designerās standpoint, providing the flexibility for an Aragon app to have multiple contracts is very important. One reason is that this is how applications are being developed today outside of the ecosystem.
Once you impose restrictions like this, it boxes the creativity of the designer which can also result in suboptimal UX patterns ā to be molded around software limitations instead of user expectations. Since these limitations do not exist outside of Aragon, I am guessing that new developers into the ecosystem can also feel restricted by how they have to write code.
I think the proposed TCR app is a use case where this limitation results in a user experience that I think will be more confusing than it needs to be. See my thoughts on the TCR pattern on this Github thread.
Contextual Discussions
This sounds really useful, discussion is really important in governance. However, it also feels like something that may be quite complex / costly to build on decentralized infrastructure and I wonder whether it makes sense at this stage to move that direction versus rely on centralized alternatives like github/forums that are loosely coupled. E.g. something put to a vote could provide a link to a discussion forum where the actual discussion could take place.
It would be interesting I think to explore the pros/cons and the marginal benefits of decentralizing and fully integrating this into the application at this stage.
@Schwartz10 (Jon) covered a lot of reasoning for why we find moving towards a path of decentralization for discussion makes sense. But to reiterate, what we intend to accomplish in this initial 26 week period will not be fully decentralized as there will be an intermediate caching layer. Additionally, Aragon is already hosting non-smart contracts on IPFS, so I think that user inputted elements (such as profile data, discussion) also being hosted on IPFS is a logical move, especially if we want to create the optimal end-user experience.
One example of the inefficiencies of the current system can also be observed for the AGP process that is underway right now.
In the Github thread where the Association board is providing their approvals/rejections of the current AGPs, @jorge states:
I support AGP 14 and AGP 16 as they currently stand, but given that they only contain a Github link to another pull request that could be modified by the author, maintainers or Github itself it is too risky to sign such AGP. I will refrain from signing until the AGP text contains the proposal description.
He has a totally valid point (see my misstep here as well!). But this can also be avoided if we start to move down an IPFS or related path as far as how voting proposals work. Hence I think this is actually one of the most important features needed for Aragon, especially if we want to:
a) Make the proposerās life easier (not requiring them to go somewhere else to upload to IPFS and then link it)
b) Remove the vector of a proposal being updated after submission - which helps to avoid unnecessary trips to the Aragon Court
A second example of why it is important to prioritize distributed storage for contextual discussions, is that the UX for submitting proposals for discussion is also very poor. Right now the pattern seems to be:
- Create an AGP which is a pull request
- Create a new discussion post in Aragon where that pull request is linked (See the first post in this thread for an example, which links to: https://github.com/aragon/AGPs/pull/19)
If you actually click on this pull request, it looks like the screenshot below.
A new Github user that is reviewing the proposal may be very confused on how to actually read the proposal.
Additionally, as a proposer who is creating a forum post to share the proposal for review, is there a better link I should post instead, so the user doesnāt have to dig around for the markdown file? Should I post a direct link to the file, like this instead? https://github.com/stellarmagnet/AGPs/blob/625e14306f3d27d19c25ce4299852837178c2f3f/AGPs/AGP-19.md
And should we instead have the discussion within Github?
There are actually too many possible paths that the proposer can take, that itās going to result in really inconsistent behavior. The only way to avoid this is to actually design a more self-contained system as far as proposals and discussion goes. This means we should start think about integrating discussion into Aragon, sooner rather than later.
We already are relying on Github to maintain the integrity of the proposals. With our near-term solution, it does involve relying on trusted community member or partner organization to host the centralized caching layer, yet the great part is that the storage is distributed and we plan to move it in a direction where the devops provider can change, and then eventually made obsolete once we implement the long-term solution.
This is much better than relying on Github as the referenced data does not live in a centrally controlled database.
This initiative of ours is also very much related to this previous Nest proposal which hasnāt been fulfilled yet. But we are personally passionate about building a modular solution that can work for many discussion use cases.
The third benefit is that discussions on distributed storage will enable the āfreedom to forkā as far as DAOs go. Right now forum.aragon.org can be thought of as a forum for a DAO - The Aragon Network. But if another DAO forms within this community, and wants to have an isolated forum, it would be difficult to copy/migrate the discussions due to the centralized nature of the database.
I think itās important to think of this possibility and allow communities the freedom to migrate, yet not lose their past discussions. If discussions are hosted on distributed storage, and identities are mapped to Aragon identities instead of the identities used to sign up to forums, this will be much more seamless, clean, and future proof.
Rich User Profiles
I think this is really cool, digging the future of work vibe. I think this aligns well with the planning suite stuff, though it does feel like user profiles makes more sense for user to manage externally from the Aragon client (ala 3box). Though it would be nice for address badges in the app to link to a users profile, or a summary of specific parts of the users profile.
Removing external applications an end-user needs to interface with to participate in an organization should be a priority if we want to onboard folks from all walks of life. I am a maximalist in the sense that I hope everything can one day be self-contained within Aragon because it would advance the pillars of privacy, internationalization, and accessibility. Self-containment means conveniently giving a user the ability to edit and update their identity within the Aragon app; not restricting the userās ability to migrate or manage this identity outside of Aragon. We will compare the use of 3box versus building a simple solution from scratch to achieve this goal. We plan to move on a solution thatās reliable with the lowest lift.
Expanding Governance Possibilities
I agree that the current templates are not all that useful, though I personally am a bit wary of going down the āadd more templates routeā as I think the power of Aragon as a platform is customizability/modularity ā I made a suggestion for all organizations to start at the same blank slate, and then have onboarding guide users through installing apps and configuring permissions to meet their specific usecase. I would much rather see the process of customizing organizations improve over increasing the number of static templates available.
Now that I think of it more, I think āone wizard to rule them allā will be the more logical roadmap. This will be especially important if we want people to create DAOs in two minutes 
So maybe this initiative can be to move toward a path of a single, master wizard? This would actually solve what you are proposing in that forum thread as well. I do really like the idea of starting with a blank slate organization.
Although still I think having a few pre-configured setups is OK. If we want pre-configured setups ā I assume that means we need to still maintain some kind of template system. Itās just the setup wizard can have a more seamless and unified experience regardless of template. Eventually it would be awesome for community members to create setups using drag & drop and something more visual, and then save/publish the configuration in a āgovernance marketplaceā.
It should be kind of like how wix makes it so easy to design a webpage without touching any code. So it is a good problem to think through: should we enhance the app center in general, or templates? Definitely something we can explore and jam on more. But if doing it the silver bullet app center way will take too long, I think spending something like two weeks to make some simple templates shouldnāt be thought of as that much of a distraction. It really matters what the timeline of the App Center is and how long we estimate the ideal solution would take to develop.
Data Storage and Standards
This feels like an important question for all web3 dapps, though I wonder if it makes sense for us to address at this time, I know there is a lot of external infrastructure work happening right now (e.g the graph, filecoin, swarm) and wonder if we can postpone our need for such things until those projects mature as I think trying to take this on ourselves could easily balloon in scope.
Would love to hear thoughts from people who are more in the know about the challenge and needs (e.g. actual devs :D).
See Jonās response, and also my take above in the discussions/profiles sections.
DAO Identity
I like this, it seems like a common ask from users to be able to customize the app to some degree. I think simple and high leverage things would be the ability to pin a specific app to the home page that loads by default, the ability to define a custom logo, and have an onboarding/wiki page app that allows the organization to present information to its users/community when they first launch the organization.
Iām less convinced that we need theme support, especially early on.
Rather than theme support, it feels like internationalization would be in a similar vein/scope and provide a lot more value.
The ideas you mention are definitely in tune with some of the thoughts I have about the About app mentioned in the proposal. We can definitely also look into the aspect of pinning apps in the Home tab, or making the Home much more flexible in general (think a customizable dashboard, with widgets).
I would actually love to do a poll in the next week from Aragon Cooperative members, adding our proposed Flock roadmap generally and our nice to haves, to see what the preferences are! Can we get the coop going before the vote? Iām just not sure if for the purpose of this 6 month period, we should action on the survey results, or if itās something we consider more for the next cycle assuming we get to that stage.
Rewards Application and Planning Suite
The Rewards Application and Planning Suite is I think one of the most important nest projects, but I think many may not be aware of the scope of the project and what has already been completed. It would be great to showcase that a bit more and highlight how it fits in with some of these other initiatives.
I see finishing the planning suite deliverables and improving support for reputation management as potential catalysts for adoption for Aragon.
I am glad to hear that you find the Planning Suite as important as we do! We are trying super hard to have our Rinkeby demo going in the next couple days, and we plan to make a video going through what we have built and what is remaining. We will post a blog and also update this thread with that link - stay tuned.
In the meantime, for those unfamiliar, an overview of each app is here: https://www.autark.xyz/aragon-apps
As mentioned in the Flock, our focus will be to enhance the Project apps further to support multi-token bounties (including reputation tokens) and also completing the Rewards app which we are rolling into our Flock roadmap.
In general, we also plan to upgrade the components and patterns used in our apps to use what has been developed by A1 in the past 6 months, and contribute to Lorikeet time permitting - with new components we are developing such as a robust table toolbar.
