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?
- 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?
- 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.