-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
roadmap: move WebTransport to Done section #460
Conversation
In general, my intuition is: "It's done when there's no more work left to do for it (except maintenance/bug fixes) and users can use it." Right now this only works in go-libp2p. Tracking issue for js-libp2p is here: libp2p/js-libp2p-webtransport#1. I always thought that this Roadmap was the roadmap of the libp2p project as a whole. The progress relating to the progress of the project, not necessarily just the specs. Am I wrong? If this roadmap is just a specs-only thing then this is done, but otherwise I don't think this is done since it doesn't match my intuition. |
Imo we can establish a basic definition of Done for items in this roadmap using what's outlined in the spec lifecycle doc. The Candidate Recommendation stage describes exactly I would want to be completed before moving an item to done:
If we consider this roadmap an overarching product roadmap then I would push for those 4 points. There's room for flexibility and we can add additional points specific to certain roadmap items (like interoperability for this one.) So I'd say we block this on #404, libp2p/docs#198, and optionally libp2p/js-libp2p-webtransport#1 |
My head isnt' fully in this but a couple of quick thoughts:
Thanks! |
I agree here, we need track this information too and measure progress across implementations but imo not inside this repo. This is the specs repo and imo should not be coupled with project managing downstream implementations. Which leads me to my second point that I think is relevant to these two points/questions:
This document is "bigger" than specs and is a long term product roadmap. I propose we organize work on the roadmap and do project management of product roadmap items outside of this repo at a higher, "product" level. So, I think this doc should live in its own repository (libp2p/roadmap***) and not in this specs repo. That repo would be the appropriate place to join the product roadmap with implementation roadmaps without coupling the specs repo with project management work. I know this is a beyond the scope of this PR but after reading the above comments, I wanted to bring this up. ***I proposed calling this new repo libp2p/roadmap but it could house not just the roadmap but also a set of improvement proposals to the libp2p project (akin to FIPs, IPIPs, etc.) |
I'd be hesitant to add another repo to our collection without answering if we really need it. There are a couple of downsides to an extra repo:
We could do all the suggested things within the specs repo, no? I personally like the single "source of truth" repo for the libp2p project. We can add a header for this roadmap that clarifies this is the roadmap of the project, not just the specs. |
Thanks for bringing up the discussion @p-shahi. Maybe before we get into the idea of creating a libp2p/roadmap repo, we should first get alignment of the problems with the current ROADMAP.md file we have in this repo as it exists today. Problems I see:
Are there more/different problems to add? Looking at that problem set, I can understand to turn items like "
I can personally get behind the idea of the items on the current ROADMAP.md into an issue and I think you can even do that in this repo to start and move them if it makes sense. But best to align that we have the problem understood and defined. It probably makes sense too to move this discussion about the ROADMAP.md out of this particular PR :) |
d10f78f
to
dbe9aeb
Compare
I've updated the PR. We should now be in a position to call the project "done". As a point of reference, we recently closed libp2p/go-libp2p#1827. @p-shahi @MarcoPolo Would you mind reviewing again? |
Hooray 🎉 |
Co-authored-by: Prithvi Shahi <[email protected]>
I'm not quite sure what our done criteria are (in this case, and in general).
In general, I'd consider an item "done" from a specs standpoint once the specs is stable, and an interoperable implementation has been rolled out. Usually, a single of our (big) implementations implementing a spec would fulfill that threshold.
For WebTransport, one could argue that interoperability is limited as long as we only have go-libp2p support, since WebTransport is a browser protocol. Maybe this means that we should wait for the js-libp2p release in this case.