Heyo, I noted a couple of things I found sensible, and added the conclusions of the second session, which I believe to be easier to implement.
At this point, a community sourced hybrid between a library, a directory of projects and notes from EF official statements, might be useful.
As noticed in the discussion, not all people are aware of the different solutions. Christoph and Jarrad signaled this, as Christoph thought Sharding was only researched by EF, and Prysmatic is doing quite well.
Notes:
Ethereum Roadmap:
General thoughts about roadmap
Who is responsible?
What are the inputs? Who does the inputs?
Scuttlebutt guy:
Tech trees introduction
When is something gonna be delivered? Who is thinking about it? Where can I find information about it.
Ethereum teams + client teams need to work together on roadmaps
Researchers are core stakeholders
Researchers are incentivised to take as much as they need and the clients want to ship code
Meeting 2:
Greg Colvin:
Roadmap’s not there, and all you can find is in youtube videos from meet ups around the world, nothing officialized. This is very time consuming and impossible to follow.
Christoph Jentz:
The process before, was good. They released MVPs so you could make your own estimates and work with it. Sharding does not have one.
Jarrad suggests the Prysmatic Labs work on Sharding, which Christoph didn’t know about.
Takeaways from MP:
- There is a need for the community to list resources, and not only build a roadmap.
- Alternatives to scaling such as sidechains and other groups doing research + implementation need to be listed under a common community resource library.
- We need to work on our own roadmap/library/directory/tree, whatever it is, regardless of the Foundation’s comms on the matter, in order to help dApp Developers.
- We need a PM/or a couple to go around listing all these community alternatives to scaling, EF’s statements on meet ups and whatnot, in order to build our own roadmap. We can use Trello for a first draft for instance.