Skip to content
This repository has been archived by the owner on Apr 29, 2020. It is now read-only.

RFC 0003: create a separate libp2p org #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions rfcs/0003-spin-off-libp2p-org.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
- Feature Name: ispin-off-libp2p-org

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: ispin?

- Start Date: 2018-02-09
- RFC PR: (leave this empty)
- IPFS Issue: (leave this empty)

# Summary
[summary]: #summary

Create a separate organization to govern libp2p, with its own Roadmaps, RFCs and working groups. While the development teams working on IPFS and libp2p will continue to overlap strongly for a long time, this separation will allow libp2p to evolve along a trajectory that acknowledges all of its users without forcing those users to work through the IPFS org even if they aren't using IPFS.

# Motivation
[motivation]: #motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

Though the code base of libp2p initially evolved within IPFS, libp2p has its own distinct set of users, use cases, and adoption timelines. Decoupling the two protocols while maintaining tight coordination of the development roadmaps is a healthy move for both projects. It allows libp2p to accumulate its own set of adopters and contributors -- most of whom desperately need libp2p but do not need IPFS.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

TODO

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

TODO

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this?

# Rationale and alternatives
[alternatives]: #alternatives

- Why is this design the best in the space of possible designs?
- What other designs have been considered and what is the rationale for not choosing them?
- What is the impact of not doing this?

# Unresolved questions
[unresolved]: #unresolved-questions

Resolve before merging:
- Should RFCs be tracked separately, or should both orgs share a single RFCs repository?