Skip to content
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

Create @ipfs/specs-stewards team #291

Open
2 tasks
lidel opened this issue Jun 20, 2022 · 4 comments
Open
2 tasks

Create @ipfs/specs-stewards team #291

lidel opened this issue Jun 20, 2022 · 4 comments
Assignees
Labels
need/triage Needs initial labeling and prioritization

Comments

@lidel
Copy link
Member

lidel commented Jun 20, 2022

@ipfs/specs-stewards team was created as part of #289

We need to decide who should belong to the team, sharing responsibility of triaging and reviewing improvement proposals (#289).

My initial idea is to add past/recent lead implementation maintainers from existing stewards teams, namely:

Starting with a smaller group should be enough to get us started.
Over time, we will add trusted leads from other organizations maintaining IPFS implementations.

TODO

@lidel lidel added the need/triage Needs initial labeling and prioritization label Jun 20, 2022
@lidel lidel self-assigned this Jun 20, 2022
lidel added a commit that referenced this issue Jun 20, 2022
Context: #291

Co-authored-by: Steve Loeppky <stvn@loeppky.com>
@mxinden
Copy link

mxinden commented Jun 21, 2022

Not a strong opinion. Feel free to ignore.

Appreciate being considered here as a libp2p steward. Though I don't think I should have any special permissions. That is not to say that I am not happy to be involved, but for that involvement, why would I need permissions beyond what any other ipfs user has?

@lidel lidel changed the title Create @ipfs/ipfs-specs-stewards team Create @ipfs/specs-stewards team Jun 23, 2022
@lidel
Copy link
Member Author

lidel commented Jun 23, 2022

I have a specific rationale for this, but it is also not a strong opinion, feedback welcome!

One of the challenges around ipfs/specs is "legacy go-ipfs monoculture".
Another is "tight coupling and leaky abstractions due to same people wearing multiple hats".

A solution is including maintainers of PL's ipld libp2p implementations (js/go/rust) in the specs group.

This would keep the group diverse in more than one dimension:

  1. avoids language-specific shortcuts
  2. represents libraries/interfaces (ipld, libp2p, gateway, reframe) and their consumers (ipfs implementations)
  3. guards abstraction layers in our stack: avoid leaky abstractions in IPFS specs, ensure data model (ipld) and networking layer (libp2p) should remain decoupled and useful on their own

It also acts as a soft forcing function to follow ecosystem evolution, keeping key stakeholders in sync long-term.

lidel added a commit that referenced this issue Jul 8, 2022
Context: #291

Co-authored-by: Steve Loeppky <stvn@loeppky.com>
@lidel
Copy link
Member Author

lidel commented Nov 21, 2022

@b5 @dignifiedquire would like to have someone representing Iroh, to be in the loop around specs and IPIPs.
This is mostly a formality, in day-to-day this person will get group-ping for PR reviews (https://github.com/notifications?query=reason%3Ateam-mention) and that is all.

@b5
Copy link
Contributor

b5 commented Nov 21, 2022

Thanks @lidel, I'd be happy to represent Iroh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

3 participants