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.