remove some packages from the package table

[Stebalien]

• go-libp2p-coral-dht is currently being written and shouldn't go in this list until it's reasonable usable (unless I'm missing the point of this list).
• go-libp2p-ping is an unmaintained extraction of go-libp2p/p2p/ping
• go-libp2p-pubsub is slated to be removed (swapped for go-floodsub).
• go-libpp2-dummy-conn was implemented to test go-libp2p-pnet. (1) go-libp2p-pnet can now be tested with normal io.ReadWriteClosers so it doesn't need this package and (2) I didn't bother updating this package when I did the libp2p transport refactor.

[Stebalien]

@raulk unfortunately, our documentation is a bit sparse. That means we need to be extra careful when merging unless we're sure something is ready. Basically, merge if:

1. You have sufficient knowledge to sign-off on the PR and know that it isn't blocked on something (this can be non-obvious).
2. You submitted the PR and someone you know has sufficient knowledge/context has approved it. Ideally, we'd always say "merge when ready" but we don't always do that.

When in doubt, just ask: can we merge this already!

Note 1: When someone approves a PR, that means "LGTM", not necessarily "this is ready to merge".
Note 2: This applies even if someone "with sufficient knowledge" submitted the PR.
Note 3: Never merge code in an airport.

---

@diasdavid please review changes before signing off on them. People trust your judgment.

[daviddias]

go-libp2p-coral-dht

If it is not a prototype that is usable yet, yeah, no need to "distract" our users.

go-libp2p-ping is an unmaintained extraction of go-libp2p/p2p/ping

Wouldn't it be better to take this opportunity to fully extract? Perhaps this is something that @raulk can ship while he navigates and absorbs all the code in the libp2p stack.

go-libp2p-pubsub is slated to be removed (swapped for go-floodsub).

Ref: libp2p/go-libp2p-pubsub#89.

Can we have this tracked in a issue that explain next steps? I feel that there is a lot of ideas and plans that fall into oblivion which might not seem harmful by the core developers that the entire knowledge of the stack, but it is this kind of tiny blockers that can steel hours a way from new contributors and make them give up.

go-libpp2-dummy-conn was implemented to test go-libp2p-pnet.

If go-libp2p-dummy-conn is not used, then archive and deprecate the repo.

[raulk]

Apologies for tripping up with the merge policies so soon, @Stebalien! I had assumed an approval meant a LGTM as far as merging is concerned, but you're right that I should've checked with you first. Will secure the additional/relevant sign offs where necessary going forward.

go-libp2p-coral-dht is currently being written and shouldn't go in this list until it's reasonable usable (unless I'm missing the point of this list).

I do feel there's value in capturing WIP modules. It enables the community to discover inflight work and get involved if they want to. Otherwise, the Coral DHT impl would stay buried somewhere in a 140 item list inside the libp2p org until it was ready, and we could be forgoing opportunities to engage potential collaborators that may want to help.

Naturally this would entail marking which packages are WIP. Personally I find the fruit nomenclature in this PR pretty visual and digestible.

Besides, a maintenance status/lifecycle badge on the README.md of each module could help convey the status quo, e.g. "actively maintained", "deprecated", "experiment”.

Or just a keyword on the project title may suffice (like we do sometimes with [DEPRECATED])

go-libp2p-ping is an unmaintained extraction of go-libp2p/p2p/ping

Wouldn't it be better to take this opportunity to fully extract? Perhaps this is something that @raulk can ship while he navigates and absorbs all the code in the libp2p stack.

I'm happy to take another stab at this ;-) Any clue what blockers were found in the first attempt? Feel free to shoot them here, and I’ll open an issue on the repo with a proposal for a plan.

go-libp2p-pubsub is slated to be removed (swapped for go-floodsub).

Ref: libp2p/go-libp2p-pubsub#89.
Can we have this tracked in a issue that explain next steps? I feel that there is a lot of ideas and plans that fall into oblivion which might not seem harmful by the core developers that the entire knowledge of the stack, but it is this kind of tiny blockers that can steel hours a way from new contributors and make them give up.

It would be handy for such modules to display a "Planned refactoring" section/badge on the README.md, linking to the relevant issue. libp2p is a highly granular multi-repo, and it’s not always easy to find the issues that significantly affect the roadmap of components.

P.S. The merge policy LGTM, but new arrivals to the team may find it hard to know who somebody with sufficient knowledge is in each case. Erring on the side of prudence and calling "can we merge this" frequently is OK for now, but I suspect we might need a system as the team scales (e.g. making sure all modules list maintainers on the frontpage). Nothing for immediate action here, just wanted to point that out.

In a related note, could we post these rules as a notice somewhere for new members to see? Would a "For maintainers" subsection under Contribute in the go-libp2p README be a reasonable place?

[Stebalien]

@diasdavid

Can we have this tracked in a issue that explain next steps? I feel that there is a lot of ideas and plans that fall into oblivion which might not seem harmful by the core developers that the entire knowledge of the stack, but it is this kind of tiny blockers that can steel hours a way from new contributors and make them give up.

You're absolutely right about this. libp2p/go-libp2p-pubsub#4

If go-libp2p-dummy-conn is not used, then archive and deprecate the repo.

Done.

Wouldn't it be better to take this opportunity to fully extract?

Sounds like a useful project.

---

@raulk

Don't worry about it, I just wanted to slow things down a bit. Really, this is our fault; we've been scaling without scaling our processes. Eventually, we should move to a "lead maintainer protocol" which should help both clarify and streamline this.

I do feel there's value in capturing WIP modules. It enables the community to discover inflight work and get involved if they want to. Otherwise, the Coral DHT impl would stay buried somewhere in a 140 item list inside the libp2p org until it was ready, and we could be forgoing opportunities to engage potential collaborators that may want to help.

For something a bit further along, I'd agree. However, when a project is this young, "help" usually just slows things down.

Besides, a maintenance status/lifecycle badge on the README.md of each module could help convey the status quo, e.g. "actively maintained", "deprecated", "experiment”.

That would be awesome. See: ipfs-inactive/docs#54

I'm happy to take another stab at this ;-) Any clue what blockers were found in the first attempt? Feel free to shoot them here, and I’ll open an issue on the repo with a proposal for a plan.

(ref ping)

It just wasn't finished, really. I'm not sure why. You can go ahead and try re-extracting it (I'd do it again from scratch).

It would be handy for such modules to display a "Planned refactoring" section/badge on the README.md, linking to the relevant issue. libp2p is a highly granular multi-repo, and it’s not always easy to find the issues that significantly affect the roadmap of components.

Ideally, we'd do proper quarterly planning and then post a roadmap. I've also floated the idea of closing all issue trackers except the top-level go-libp2p one but we haven't really discussed that much.

P.S. The merge policy LGTM, but new arrivals to the team may find it hard to know who somebody with sufficient knowledge is in each case. Erring on the side of prudence and calling "can we merge this" frequently is OK for now, but I suspect we might need a system as the team scales (e.g. making sure all modules list maintainers on the frontpage). Nothing for immediate action here, just wanted to point that out.

I agree (see my answer above wrt the lead maintainers protocol). This situation was unusually confusing because @diasdavid is the project lead but has been mostly watching go-libp2p from a distance until now.

Usually, for new contributors, I'd recommend erring on the side of caution and waiting for someone else to either merge the PR or say "merge when ready". Basically, if you do know, merge it; if you don't know, just wait and someone who does to come along and do so.

In a related note, could we post these rules as a notice somewhere for new members to see?

We probably should. In the past this hasn't really come up because pretty much everyone we've given write access to has been an existing community member.

[raulk]

👍 to all.

For something a bit further along, I'd agree. However, when a project is this young, "help" usually just slows things down.

Yeah, when projects are too young and not formally specified, there's a chance that collaboration can introduce noise.

It just wasn't finished, really. I'm not sure why. You can go ahead and try re-extracting it (I'd do it again from scratch).

Will take a look this week!

---

Pushing a tiny typo correction in go-libp2p-kbucket.

[raulk]

LGTM, good discussion.

[raulk]

@Stebalien

I've also floated the idea of closing all issue trackers except the top-level go-libp2p one but we haven't really discussed that much.

I would +1 this. Personally, I find it sensible from several perspectives:

• As a user, I want the libp2p org to make it easy for me to file an issue, without having to incur in the cognitive load of finding the best tracker first.
  • Before filing an issue, I want to search if it's already been reported. Doing so across 30+ repos is hard.
• As a Go developer and contributor, I want to see everything that needs doing in a single place, so I can pick up new work easily. I want to be able to filter by domains (e.g. transports, pubsub, etc.) without having to second guess what repo that might be. I don't want to have to depend on an external tool for this (cf. Waffle below).

Waffle does provide useful insight, but I suspect it's more useful to align related projects through a single board, e.g. frontend, backend, middleware, mobile apps, etc. Us having so many trackers may just be an artefact of the module/repo set up IMHO.

If I only want to see Go libp2p issues and PRs, I have to manually select all go-* repos. I have a bookmark for that, but I'll need to manually manage the filters as repos come, go, are renamed, or are deprecated :-(

Note: If eventually we do decide to migrate to a single issue tracker, our commits and PRs will need to cross reference the go-libp2p project explicitly.