That is a very reasonable point. I will bring it up internally and also have mentioned it in the more relevant thread @samuelburri has on July 2022 Roadmap thread: Update on the IC Roadmap: July 2022 Summary - #3 by jzxchiang
To clarify your intent, I know the R&D team posts frequent updates on the BTC integration (usually every other week or so) on the progress here: Direct Integration with Bitcoin, but it seems this does not address your intent.
- Can I assume you are looking for something more real time than weekly updates?
- Is weekly updates ok, but the main problem is that it is buried in a dev thread?
- both?
- To some degree yes and no. A common pattern in software is that there is a point where adding more engineers to a project usually slows things down. The more impacftul thing is less more engineers, but more time & focus per engineer. An example may be how 2 months ago, DFINITY made it clear that BTC and SNS projects tae priority so that means all other requests or asks NOT related to these two were de-prioritized among the engineers. As cross-functional projects, these prjects have a core of engineers working on it full time and a another ring of engineers who support them (for example, if the BTC integration engineers need help from Crypto or Consensus team or NNS Dapp team, their requests now take highest priority). I would say that more focus/priority has sped up progress more than adding more engineers.
Does that make sense?
What would this constraint be?
Dumb question @skilesare (to make sure I understand your point)⌠it sounds like in your observation, DFINITY is the âbig, slow and high qualityâ player in the ecosystem that discourages the more nimble, agile startup-y players.
a. Did I understand your intent right?
b. Do you think startup players see no room for âagile and fastâ players in the ecosystem when DFINITY undertakes a project?
More simply:
- I have heard similar as folks* did here:
- I do not know
- I have escalated to Jan to see if I can get clarity on what he meant
I agree 100%. Clearly, we are all iterating and learning. I can understand why some folks may think âyou are learning or iterating too slowlyâ, so accelerating the learning is (hopefully) something we are also doing.
To dig in a bitâŚand Iâll answer the questions directly at the endâŚI think that there is a hidden âfeelingâ that DFINITY moves slowly because there is so much on the line(like NASA)âŚhave to dot every T and dot every I. If you guys release trash it hits the ICP token much harder than if icOpossums launches a trash contract(apologies it icOpossums if that is a real thing). We all kind of implicitly know this, so we know what you guys release is going to have the eyeballs + quality to do really well. Everyone else out here is (relatively) scraping it out on fumes with a few getting a bit of VC cash to go further. The community has to break things and release half measures to survive. When choosing amongst a sea of future universes, why would you pick the one with a T-Rex waiting in it? Even if it isnât hungry, no one is going to be paying attention to you because âlook at that T-Rex!â.
- Yes. I think you got it.*
- It isnât so much a âroomâ as it is what is the best use of my time. When we have 1,000,000 IC devs all competing for the same spaces this distinction will go away and people will choose to compete because they know they can run faster than DFINITY, but right now it is more profitable and less risky to run in a different direction altogether to the blue ocean.
*Iâll qualify slow, because I think that is unfair to the DFINITY team. You guys have pulled off quite a bit and Iâd qualify it as deliberate and through over âslow.â I also think that for some âbigâ things we 100% want this. In other areas, we want/need a thousand experiments.
For me, these break down along âknown knownsâ and âknown unknownsâ fault lines. BTC integration is a known, known. No need to do it 100 different ways, we all know what we want, and we want to do it right. Governance? No one knows how that is going to go. From the stories Iâve heard, even Dom admits that the one thing he doesnât know how it will turn out is the governance pieces. For those, I think we need 1,000 experiments and the power of the market/organic evolution to help us find the best solution.
Hi @harrison, I think i get most of what you say, but I have a few clarifying (dumb) questions:
-
How much would your comment change if the heart emoji were removed from the roadmap posted here? I currently suspect that your process suggestions on prioritization & communication would still be the same so the heart emojis seem like a red herring⌠but maybe I am misreading and you put more weight into them than I am understanding.
-
like the suggestions for improving⌠regardless of how coupled they are to the hearts. I took the hearts as you using it as symbolic or sign of what could be improved under the hood. Did I get that right?
I am not quite sure I see the connection so I may be missing something. I see two things here, so can you clarify?
- When I (Diego) write about on-chain governance, i refer to the fact that the network is updated via NNS proposals with Wasm which folks vote on. I am not referring to the motion proposals. Indeed, many networks have motion proposal type systems⌠what is technically unique about the IC is about the actual updating of the code.
- So to me the â25 motion proposalsâ were laying out the intent DFINITY had about the IC and wanted to see what people thought, since they involved upfront investment or hiring and working.
So my question is this:
-
Did you not appreciate the proposals on Long Term R&D? Did you see them as on-chain governance? Motion Proposals on Long Term R&D Plans (totally fine if your mind changed from when proposed December 2021 to now)
-
Is my definition of on-chain governance too narrow? (it may be!)
In my opinion even without the hearts priorities seem a bit all over the place and Dfinity should have done a better job at communicating why the roadmap looks like this, the hearts just makes it weirder cause they are supposed to represent communityâs interest, but some of the tasks have been rarely if ever talked about as far as I know. I agree with Harrisonâs take, we should have more infos on Dfinityâs internal decision making: Who requested those features? Have they been prioritized cause they are dependencies for something else? Why have they been prioritized over other stuff? etcâŚ
To expand on this⌠the classic version of this thought is âwhat if community wants a feature X that DFINITYâs crypto team thinks is too insecure or risky? to implementâ would that be an example of what you mean?
(I can imagine others, but wanted to give a concrete example to further clarification)
To clarify: Do you mean beyond the ecosystem grants? Ecosystem grants come from ICP treasury, but do you mean something different? or the same but âmore of itâ?
Thank you, this makes lots of sense.
I asked lots of questions so I wanted to circle back that its very clear to me folks want more visibility (as a minimum) into the prioritization of engineering work.
I also wanted to say that I believe the following can both hold (so people can understand my meta-thinking):
-
DFINITY has continually provided more visibility externally as well improved its internal processes. I believe it is leagues beyond where it was at Genesis.
-
DFINITY is nowhere close where it wants to be on either of those, so it is very reasonable for people to say âNot there yetâ or âneed more of thisâ or âkeep working on it.â
I certainly do not take it personally when someone like @harrison or @skilesare @lastmjs or @Zane say âwe need moreâ, because I know these folks have invested greatly in time and resources into the ecosystem. (not to discourage other folks from commenting, but I wanted to be clear that I can agree when people say âwe need moreâ).
If anyone thinks either #1 or #2 are completely off in another planet, please let me know. Always ready to change my mind.
You guys have made huge strides and it is mostly due to your efforts. Keep it up. #WAGMI.
In my personal experience, I have always received an answer when Iâve asked a question. Sometimes I didnât like the answer or the date is further away than I want. Sometimes I backdate the date a couple of months , but I always at least get an answer. As a programmer, I understand how hard this stuff is and I can also understand the frustration some have that donât see the difficulty underneath all of this stuff.
I also donât fault DFINITY for being the 500 lbs gorilla in the room. Navigating this stuff is hard and it is why we are going to do it when very few others will try. Keep turning the crank. Make a better crank. Turn that one faster.
Your question prompted me to look back at the conversation. The use of the word âconstraintâ was a mistake on my part. I should have said there was a technical reason.
I see thanks for taking the time to find the tweet, I donât understand why Dfinity decided to overengineer the SNS so much and integrate it into the NNS, I heard many conflicting reasons by Dfinity devs, at first it was meant to give more visibility and liquidity to projects, then it was about avoiding user exposure to blatant scams and rugpulls and now its due to a technical reason.
I donât think we should speculate too much based on echoes of wording what the rationale is.
Jans tweet just says that the actual feature of proposing to the NNS could be resolved by a system canister or such. He did not explain too much why this was there.
Itâs entirely possible, just wish Dfinity had just built a DAO framework and released the source code without overcomplicating stuff by getting the NNS involved.
To make sure I follow, does the Simple DAO open source example on the developer docs not satisfy this intent? What would you like added to address your intent?
- not robust enough?
- too simplistic?
- not documented or easy enough?
Anything will help!