Module Lead Maintainers - Sharing the Responsibility over the IPFS module base

[daviddias]

The IPFS project has grown significantly since 2 years ago and the task of maintaining its module base a very large and time consuming task for few individuals. Me and others have voiced concerns about the bottleneck which leads me to feel really strongly that we need a proper structure to share the responsibility, ownership of the multiple modules we currently maintain.

The current situation is:

• Two Tech Leads, @diasdavid and @whyrusleeping, who have full responsibility, right to merge and release over all modules/packages on the js-ipfs and go-ipfs projects, respectively.
• Few maintainers/contributors that cover parts of the module codebase (e.g @pgte for js-ipfs-unixfs, @vmx for all things IPLD, @victorbjelkholm for aegir and other dev tools, etc).
• There is no clear way to tell explicitly who is the maintainer of what, other than that the Tech Leads are.

What we would like to be at is:

• Recognize extraordinary contributions and empower contributors to take even more important role in the project
• Reduce PR review time and Time To Release
• Increase the overall quality of the project
• Help users know who to reach out for help
• Have a clear way to pass on the baton

A Lead Maintainer must:

• Have complete understanding of that piece of the stack (known the code by heart, read all the specs related to it)
• Have contributed to the module before
• Show a great level of rigor and polish in the code that they ship
• Help others in understanding the module
• Proactively improve documentation, tests and examples of the module
• Apply the established Contributing Guidelines to the project and help others do too

In a tl;dr;, what I'm proposing is:

• Have a Maintainers Guide to make sure we every lead is on the same page.
• Add a section to the top of each module that identifies the maintainer
• Give merge and release access to maintainers
• Update the packages table on each project (i.e https://github.com/ipfs/js-ipfs#packages and https://github.com/libp2p/js-libp2p#packages) to include a column for maintainer as well.

In addition to this, I also feel it would fit well to list the Working Group in which the module and/or project falls into. So far, we have pretty much labeled every project with , It would be good to have a badge for the working group as well.

How do other projects do it?

We should look into other projects do it as well. Hapi has a good structure and success for running a similar process for the last few years. @sericaia, @geek Hi o/! can I ask you to share with us some of your leanings here?

Other things to look at

• http://openopensource.org/

[sericaia]

In Hapi we have guidelines that help a lot for starters:
https://github.com/hapijs/contrib/blob/master/Guidelines.md

A code of conduct its also important (and you can also find it in the /contrib folder)

Everything else is similar to what you just mentioned ;)

[daviddias]

The protocol has been created and we are in the process of updating every repo.

Here is the current Status

Module	README.md	package.json	Github perms	npm publish perms	Lead Maintainer
Multiformats					@diasdavid
multiformats/js-multihash#51	✅	✅	✅	✅	@diasdavid
multiformats/js-multiaddr#66	✅	✅	✅	✅	@victorbjelkholm
multiformats/js-multibase#27	✅	✅	✅	✅	@olizilla
multiformats/js-multicodec#24	✅	✅	✅	✅	@hacdias
https://github.com/multiformats/js-multihashing	✅	✅	✅	✅	@hugomrdias
https://github.com/multiformats/js-multihashing-async	✅	✅	✅	✅	@hugomrdias
https://github.com/multiformats/js-mafmt	✅	✅	✅	✅	@vasco-santos
https://github.com/multiformats/js-multistream-select	✅	✅	✅		@jacobheun
IPLD					@vmx
ipld/js-ipld#127	✅	✅	✅	✅	@vmx
multiformats/js-cid#48	✅	✅	✅	✅	@vmx
ipld/js-ipld-bitcoin#16	✅	✅	✅	✅	@vmx
ipld/js-ipld-dag-cbor#63	✅	✅	✅	✅	@vmx
ipld/js-ipld-ethereum#14	✅	✅	✅	✅	@kumavis
ipld/js-ipld-git#12	✅	✅	✅	✅	@vmx
ipld/js-ipld-graph-builder#33	✅	✅	✅		@wanderer
ipld/js-ipld-dag-pb#70	✅	✅	✅	✅	@vmx
ipld/js-ipld-raw#11	✅	✅	✅	✅	@vmx
ipld/js-ipld-zcash#8	✅	✅	✅	✅	@vmx
libp2p					@diasdavid
libp2p/js-peer-id#78	✅	✅	✅	✅	@pgte
libp2p/js-peer-info#64	✅	✅	✅	✅	@pgte
libp2p/js-peer-book#37	✅	✅	✅	✅	@pgte
https://github.com/libp2p/js-libp2p-webrtc-star	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-websockets	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-tcp	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-utp	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-webrtc-direct	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-websocket-star	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-websocket-star-rendezvous	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-udt					??
https://github.com/libp2p/js-libp2p-udp					??
https://github.com/libp2p/js-libp2p-identify	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-floodsub	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-spdy	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-mplex	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-mdns	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-railing	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-ping	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-kad-dht	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-record					??
https://github.com/libp2p/js-libp2p-delegated-content-routing	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-delegated-peer-routing	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-iprs-record
https://github.com/libp2p/js-libp2p-kad-routing
https://github.com/libp2p/js-libp2p-distributed-record-store
https://github.com/libp2p/js-libp2p-kad-record-store
https://github.com/libp2p/js-libp2p-keychain	✅	✅	✅	✅	@vasco-santos
https://github.com/libp2p/js-libp2p-circuit	✅	✅	✅		@jacobheun
https://github.com/libp2p/js-libp2p-rendezvous					??
https://github.com/libp2p/js-libp2p-connection-manager	✅	✅	✅	✅	@vasco-santos
libp2p/js-libp2p-crypto-secp256k1#6	✅	✅	✅	✅	@dignifiedquire
libp2p/js-libp2p-crypto#119	✅	✅	✅	✅	@dignifiedquire
libp2p/js-libp2p-secio#102	✅	✅	✅	✅	@dignifiedquire
https://github.com/libp2p/js-libp2p-switch	✅	✅	✅	✅	@jacobheun
libp2p/js-libp2p#190	✅	✅	✅	✅	@diasdavid
IPFS
https://github.com/ipfs/interface-datastore					@pgte
https://github.com/ipfs/js-datastore-core					@pgte
https://github.com/ipfs/js-datastore-fs					@pgte
https://github.com/ipfs/js-datastore-s3	✅	✅	✅	✅	@jacobheun
https://github.com/ipfs/js-datastore-level					@pgte
https://github.com/ipfs/interface-pull-blob-store					@pgte
https://github.com/ipfs/js-fs-pull-blob-store					@pgte
https://github.com/ipfs/js-idb-pull-blob-store					@pgte
https://github.com/ipfs/js-level-pull-blob-store					@pgte
https://github.com/ipfs/js-ipfs-unixfs-engine	✅	✅	✅	✅	@achingbrain
https://github.com/ipfs/js-ipfs-unixfs	✅	✅	✅	✅	@achingbrain
https://github.com/ipfs/js-ipfs-mfs	✅	✅	✅	✅	@achingbrain
https://github.com/ipfs/js-ipfs-repo	✅	✅	✅	✅	@jacobheun
https://github.com/ipfs/js-ipfs-block-service	✅	✅	✅	✅	@vmx
https://github.com/ipfs/js-ipfs-block	✅	✅	✅	✅	@vmx
https://github.com/ipfs/js-ipfs-bitswap	✅	✅	✅	✅	@vmx
ipfs/aegir#220	✅	✅	✅	✅	@victorbjelkholm
https://github.com/ipfs/js-ipfsd-ctl	✅	✅	✅	✅	@hugomrdias
ipfs-inactive/interface-js-ipfs-core#264	✅	✅	✅	✅	@alanshaw
ipfs-inactive/js-ipfs-http-client#758	✅	✅	✅	✅	@alanshaw
ipfs/js-ipfs#1339	✅	✅	✅	✅	@alanshaw

[vmx]

In case you follow the Standard Readme, these scripts might help for adding the Lead Maintainer: https://gist.github.com/vmx/6ff564e93cf7c0a77866a4bcda19fdf5

[vmx]

@diasdavid Should the Tech Lead also have permissions to publish a module on npm? It's not explicitly mentioned in the guidelines.

[daviddias]

@vmx yes, good catch. Mind adding that in through a PR?

@victorbjelkholm just got what I fear when we shut out maintainers and tech leads from being able to push to master

 ⠋ Push to GitHub
   Generate GitHub Release
   Publish documentation
   Publish to npm
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "continuous-integration/jenkins/pr-merge" is expected. At least 1 approving review is required by reviewers with write access.
To github.com:ipfs/js-ipfs-repo.git
 * [new tag]         v0.20.1 -> v0.20.1
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to '[email protected]:ipfs/js-ipfs-repo.git'

Cannot create property 'context' on string 'remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: Required status check "continuous-integration/jenkins/pr-merge" is expected. At least 1 approving review is required by reviewers with write access.
To github.com:ipfs/js-ipfs-repo.git
 * [new tag]         v0.20.1 -> v0.20.1
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to '[email protected]:ipfs/js-ipfs-repo.git'

We need to give master push perms to folks with publish access.

[victorb]

Hm, that's sad, as we cannot guarantee that master is always green then... Is there a way around this? What is it trying to push here, it's the changelog right?

[daviddias]

@victorbjelkholm changelog, version bump and tag.

We could hypothetically have aegir create a branch for the release that has to be merged after the publish

[daviddias]

A request to all the Lead Maintainers (@alanshaw, @vmx, @achingbrain, @vmx, @jacobheun, @pgte, @diasdavid, @kumavis, @dignifiedquire, @wanderer, @olizilla and @hacdias): Can you please go ahead and create a PR to update the modules you are maintaining to include the Lead Maintainer Section and the leadMaintainer property on the package.json (see other PRs for example)?

Automating this step would be ideal but given that not all READMEs are formatted the same, it requires manual work and it is taking a significant amount of time from a single person currently (me).

[wanderer]

@diasdavid done! on the npm publish perms, does anyone else need perms for ipld-graph-builder?

[daviddias]

@wanderer me (daviddias on npm) and @vmx (vmx on npm also), please. Thank you!

[vmx]

@diasdavid The publish rights for the Tech/Module Lead are mentioned in the "In practice" section, I've missed that before.

[vasco-santos]

@diasdavid I created the PR for the js-ipfsd-ctl repo.

[daviddias]

This happened, every module has a new Lead Maintainer now. Thank you everyone! ❤️