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?
@sohkai – this is a lot of good feedback, and I’m trying to process it and see how I can work through some adjustments. I realize my table is actually wrong, as it adds up to 107% instead of 100% as well I will work on revising these numbers in the next few hours and have better breakdowns on development capacity vs. non-dev.
@LouisGrx, @lkngtn, @light, @stefanobernardi, @luis can you please provide any feedback on proposal structure changes that @sohkai mentions and anything else. i’m trying to get a few other inputs before I start making drastic changes to the AGP with only 26 hours to go.
I will check and get back ASAP with feedback. Having a hard time trying to review all proposals
@stellarmagnet I really agree with that point, I01 feels incredibly important and we haven’t really started seeing Open Enterprise in the wild, and it will not only take development effort to iterate it to satisfy users, but also communication and advocacy work so those who need it can benefit from it.
Another important point for me is I03 – ideally Autark would take the lead on the Finance app altogether, as I believe separating ownership will result in less transaction costs. So basically I think that Autark improving and maintaining the Finance app could be the way forward, instead of extending it and leaving Aragon One with the maintenance work.
On I09-I13, I see them as built-ins for all Flock teams, but I think leaving them under a “Misc” section wouldn’t hurt neither.
I05 and I08 seem super important as well.
Correct. Proposals should be finalized - as in no further changes made - by 16:00 UTC tomorrow.
At this point, all changes are still receivable as we’re not passed the submission deadline for AGPs and the AA has not yet approved Autarks proposal in the Flock repo. This being said, I wouldn’t recommend making any major changes to the structure of the proposal in the last hours before submission. This sounds risky as the new proposal could raise new concerns and questions from the community.
On a higher level note, the granularity of the feedback provided in this post leads me to think that we may have to adjust the Flock application format to leave a bit more room/flexibility for later adjustments and make that explicit. As Flock teams cooperate on multiple fronts daily, Initiatives will probably end up implemented slightly differently than in the original proposal.
There is a tricky balance to be found between how the proposal is interpreted by Flock team members (i.e. experts) and ANT holders who may be outsiders. I am wondering if we want to explore a system where proposals are discussed internally to the Flock program at a granular level and then proposed to the community for review in a format that is readable and understandable by all.
I think what we are delivering for I01 from AGP-19 is not too far off from having near-term utility for both Open Enterprise and other apps as well. Our June update has more details on the progress of I01, and also describes that we have indeed touched expanded forwarder options. I agree that it’s not fully complete! Based on an unexpected push to launch Open Enterprise on mainnet (which wasn’t scoped in AGP-19), we think external intents is a good enough step toward multi-contract interactions, yet definitely not comprehensive.
The resource allocations are projected allocations, and are subject to change. Taking @LouisGrx’s feedback into consideration, and time, it’s too late to modify the AGP to carve out a more distinct initiative – but that is not to say we are abandoning the effort! Monolithic apps are still very important to Autark.
We wrote our AGP in a way that resource allocations for stack enhancements will draw from the initiative that is dependent on that enhancement. So continuing to iterate on Cross App UX will likely occur in the I03, I05, and I06 initiatives. Our strategy is to prioritize the enhancements in a way that caters toward greater adoption of Aragon.
This is all really good to know and learn! Due to time constraints, the best we can do right now is continue the conversation with more team members from both sides and come to consensus on the roadmap and how we want to approach this. Then we can submit a PR to adjust our proposal after there has been sufficient discussion.
I have adjusted this initiative to 14%, with software engineers being around 8% of it. Just a reminder that these are projections though
This initiative will start from our 3 person Strategy team, and doesn’t require much of our engineers in the initial stages. Due to us creating a DAO, ideally we can find other engineers from the community that will help and contribute to the technical work. My projection is that about 3 months in is when our engineers would be dedicating their time, after the strategy team has facilitated a few community curation processes, vetting ideas and presenting plans.
This makes a lot of sense regarding the Association making requests and how teams should be open to that! While we won’t be able to remove this initiative due to how late in the process we are, we hope that the sentence that says “we …are open to considering extending our support on a case by case” satisfies the use case you’re talking about, as far as implicit responsibilities.
Okay, let me see what I can do here…
As specified in our proposal, we have 3 team members that are what you would call “non-technical” – I’m calling us the Strategy team. We will eventually have a min of 8 (potentially 9) members that are software engineers. Let’s just say 8 for now.
- Software engineers: 73%
- Strategy (incl. product/design): 27%
2/3 members of the Strategy team do contribute to product development duties such as sprint planning, product specifications, and design – yet they aren’t 100% committed to Product initiatives.
It’s really hard to then do math of “What percentage of team capacity is writing code for initiatives I01- I08 vs. not writing code?”.
For that reason, I did come up with an alternate approach that is now included in our proposal here. I also revised some numbers to fix my 107% math error, and made adjustments based on some of this feedback in this thread. I also separated I01-08 into a “Product” bucket and I09-13 into a “Community” bucket.
I previously bucketed the product & design for I01-I08 into I13, but that wasn’t completely accurate. So I made a revision to that capacity and increased I01-08 to more closely reflect the entire team’s capacity dedicated toward the product initiatives. But these are super hand-wavy calculations here…
This system isn’t completely perfect, but I hope it can provide more clarity.
|Product Initiatives||Team Capacity (%)||Product Capacity (%)|
|01 - Maintaining Open Enterprise||8||12.5|
|02 - Expanding Projects||8||12.5|
|03 - Expanding Finance||10||15.6|
|04 - Expanding Social||6||9.4|
|05 - Enabling Organization Insights||8||12.5|
|06 - Enabling New Governance Mechanisms||8||12.5|
|07 - Making Aragon More Inclusive||6||9.4|
|08 - Facilitating Smart Contract Based IPFS Pinning||10||15.6|
|Community Initiatives||Team Capacity (%)||Community Capacity (%)|
|09 - Strengthening Network Sustainability||14||38.9|
|10 - Driving Ecosystem Development||12||33.3|
|11 - Supporting AGP Execution||2||5.6|
|12 - Facilitating Developer Support||4||11.1|
|13 - Reinforcing User Research Efforts||4||11.1|
I agree with the need for flexibility.
how does this follow? I don’t understand the benefit of moving any of these conversations out of the public domain or how it allows for flexibility. Surely this can be done without decreasing transparency
Blog accesses - Y - We want to provide updates on Open Enterprise releases in the official Aragon blog.
Do you plan to publish all release updates on the Aragon blog? How will you be segmenting content between the Autark blog and the Aragon blog, if at all?
Social media accesses - Y - We want to speed up sharing Autark updates on the @AragonProject twitter.
Has sharing Autark updates been slow thus far? Could there be another option than direct access, such as having a team member from Autark coordinate with the social media manager (me, currently) to share an update through the account at a particular time?
Repo accesses - Y - Owner access to all aragon repositories. We’ve already started working on Aragon SDK tools, going forward this work will increase and we can’t expect Aragon One to provide full reviews to the feature adds we need. We’ve proven ourselves and believe this access is in everyone’s best interest in terms of team efficiency and developer experience.
I’m surprised this hasn’t gotten more attention, maybe it is uncontroversial to others. But this seems like something to discuss for sure. What does “owner access” mean? Why “all repositories” instead of a subset that you are most active in / taking ownership of? Same for the NPM access request:
NPM publish rights for all aragon packages. - Y - While we most likely will not push major changes, when small bugs are introduced to the tools it would be easier for everyone if we could push quick bug and hotfixes to the aragonSDK packages.
Admin/moderator access on aragon.chat, forum.aragon.org, and /r/AragonProject - Y - As we take on an increased role with user and developer relations we expect to need the ability to move within all aragon chat channels un-restricted. We want Autark members to have badges in the forum and to be able to manage that process. We would like at least one Autark member to be added as a reddit moderator to be able to facilitate AMAs.
I don’t think admin access is needed to fulfill support roles but we can discuss which channels / forums you will need moderator access to.
The path that we’d like to explore is to continue to post all Autark updates on the Autark Blog, and only write pieces under the Aragon Blog for when there are major product updates that affect the network in its entirety, topics such as new Open Enterprise releases, or major app updates or launches.
In general, we are happy to adopt any standards that will be established. As Aragon Black had blog access approved in AGP-34, and Aragon One has blog access, it seems only fair for Autark to also be included. I think working on defining content strategy standards for how to make use of the Aragon Blog can be something we can all discuss in a forum post?
No, you have been great at retweeting our updates actually! But that’s a good idea, as far as coordinating more if we are looking for specific timing, or for tweets that should be written from @AragonProject, vs. retweeting @autarklabs. We could go as far as setting up a cross-team social media editorial calendar if that’s what’s easier for everyone. We’re really open to suggestions here to improve everyone’s workflow.
We were never planning to use this privilege to get Autark members to all repos right away. We definitely plan to go through discussions with each repo owner first and make a case whenever we actually needed it. We wanted to limit the amount of AGPs we need to submit in the next year to request access on a repo-by-repo basis.
Aragon Black had “Repo access on the entire @aragon organization” approved in AGP-34, we are happy to update our requirement to be more in line with how they have worded it.
Or if there are better standards or norms that can be adopted for this access, where we are treated similarly to Aragon Black would be great.
Aragon Black had admin/moderator access approved for aragon.chat, forum.aragon.org in AGP-34.
We are happy to adopt any Flock level expectations and standards for how access to communication channels like these are handled.
General high level questions, I don’t know if 10 hours is enough to hash out:
- What level of administrative decentralization should we be striving for, as a network?
- How many years of contributing to Aragon should a Flock team have under their belts to be considered a trusted party to not abuse privileges? Whether it comes to blog, social media, repos, or communication channels.
For the future, it would probably be helpful to have more detailed questionnaires per access item, that all Flock applicants are expected to provide answers to, where we all know the conditions that need to be met to be upgraded to the highest level of access.
Or some of this access can be granted outside of the AGP process after meeting more internal conditions, e.g. “ownership access is granted after submitting
#x PRs into the repo, with non-critical code review comments” – which already may be happening.
If that’s the norm we prefer to adopt, then we should in general omit or not allow repo ownership to be granted via an AGP, or for a team to link the PRs as evidence in the AGP to get network approval.
I will just comment that you raise a number of very important topics that need to be discussed, including access rights with centralized services.
We’ve thought a bit about it but not enough to have meaningful guidance at the moment.
Hopefully we can work with Flock teams and have something for the next ANV.
Brett meant I01 in AGP-19, which is Cross App UX We definitely agree that iteration on Open Enterprise important! As far as our new AGP goes, we consider Open Enterprise initiatives being I01 - I03, so you can definitely see there’s quite a bit of emphasis in delivering features that we hope will increasingly satisfy users!
I think we should discuss this in more detail with @sohkai and @Quazia for how we want to handle this. Autark will do what is best! Finance is a really critical and sensitive application with respect to contracts. As far as how we want to share the ownership, a first step can be we take on ownership of the Frontend, as soon as we begin development on I03 – if everyone thinks that is best.
Since the contract changes are super super important, an internal audit from Aragon One on the changes we make in I03 would be nice, before we hand off to security.
I think longer-term maintenance of the contracts is probably something that doesn’t have that high coordination costs, and I assume we will want to limit the upgrades after I03 goes through a security audit. So contract changes should be more collectively planned, right?
Regardless, I feel like we can sort this out outside the AGP, right?
Based on all the feedback, we separated the initiatives in our “projected capacity” section, so hopefully that adds more clarity to everyone!
Glad you think I05 and I08 are important – we are super excited to deliver both of these!
1. I revised the intro text:
These are our initial requests for Aragon accounts, channels, tools, assets, domains and infrastructure that we need in order to operate and to make progress on decentralizing administration of centralized services.
If a situation comes up where we feel we need more control, we will propose it in another AGP.
We plan to be respectful of the privileges granted to us and will adopt Flock norms set forth by current owners, managers, maintainers, and future Aragon Network Votes.
2. I revised repo access so it matches up how Aragon Black worded it in AGP-34:
Repo access on the entire @aragon organization.
I just submitted the pull request with the formal AGP format:
Thanks! I think this leaves enough flexibility.
My questions here are not so much about trusting your team or not so much as following the principle of least authority – as developers of a security sensitive application, I am cognizant about not wanting to introduce too many central points of failure into our communications and development infrastructure. This is un-intuitive but adding more admins to these services does not actually decentralize authority, it adds more central points of failure. The cost/ risk of this has to be weighed against the benefit, and if there’s a way to get ~same benefit without introducing extra risk then that is preferable to me.
We can discuss specifics about what level of access is needed for Autark in detail later!
Th the qouestion: “How many years of contributing to Aragon should a Flock team have under their belts to be considered a trusted party to not abuse privileges?”
With a holacracy like structure everyone would have roles. so there would be a communicationWG in there a PublishWG which is elected by all the flock teams and the flock team is then sending all their blog post to this PublishWG. Does Aragon not have an overall structure like this