RFC: Proposal to make community contributions maintainable with a pouchdb-community org

[carloslfu]

PouchDB is an awesome opensource initiative and have multiple community contributions in the form of plugins but I have seen some useful plugins that are poorly maintained. I propose to have an organization in which all these plugins (or other stuff) are maintained, an example of that is what CycleJS does with cyclejs-community organization. Also this organization should have a guideline for maintenance and an acceptance criteria. The main goal is to have high quality and well maintained community projects. I hope your opinions on this topic and I offer my effort to make the PouchDB community projects better. This issue is related in at some level with the @nolanlawson PouchDB governance topic.

[nolanlawson]

Thanks for the feedback! 😃 This has been top-of-mind for us, and we're definitely interested in figuring out how to better do OSS sustainability.

Moving the plugins to an org is a good idea; so is the CycleJS idea essentially that all the plugin/addons/documentation authors got together and joined the same org, and all the plugins are housed under the org? Do they do npm tags or anything else?

[carloslfu]

Hello @nolanlawson, I am glad to hear that! 😄 . Yes this is the CycleJS idea, I have not seen npm tags in their community repositories. What do you think is the next step for starting the organization?

[garrensmith]

One question on this, how would we decide if a plugin goes into this organization? If someone writes a weekend project and does do anymore work on it, but it is added to this organisation. Are we responsible for maintaining it?

[nolanlawson]

I created a GitHub repo but haven't added any projects yet: https://github.com/pouchdb-community

Garren's right; upon further reflection I'm not sure of the value of this approach. It's somewhere between "rando repo under someone's name" and "official repo on github.com/pouchdb". But in either case it communicates a level of support that currently doesn't even exist for certain pouchdb repo projects (e.g. pouchdb/upsert had some huge bugs that just sat for months). Not sure what the point is… but maybe CycleJS has some blog posts about this or something? 😕

[carloslfu]

The next paragraph are from CycleJS community:

As a member, you are welcome to create repositories in this community and to transfer your existing repos. The only criteria is that they're related to Cycle.js and that collaboration is welcomed.

[nolanlawson]

@carloslfu Thanks for sharing that document. I have a bit of a better idea now of why cyclejs-community was created, but I admit I'm still a bit fuzzy on what the actual impact is for contributors. I.e. did it actually made it easier for folks to get involved, did they see a positive impact, etc.

I think a key point is that, in order for pouchdb-community to actually be something of value for the community, it'd have to be more than just my plugins. So I'm going to ping @broerse @rsutphin @pubkey @cdaringe @calvinmetcalf for their input since they've helped maintain some high-quality PouchDB plugins/addons (ember-pouch, pouchy, rxdb, crypto-pouch in particular).

What do y'all think? Should we join forces and move our repos to https://github.com/pouchdb-community ?

[broerse]

@carloslfu I am not sure creating a pouchdb-community is necessarily a good thing. I think there is much value in feeling responsible for open source products published under your own name or handle. I see much value in using the PouchDB or something we settle on as keyword for all npm packages and create something like https://www.emberaddons.com/ (Source: https://github.com/ahawkins/emberaddons) for PouchDB.

If we create *-community like this ember-pouch should be listed in the ember-data community, ember-community, the couchdb-community and the pouchdb-community. I don't think this is possible yet so I am in favor keeping the modules with @nolanlawson

[cdaringe]

other than increased visibility, the proposal probably doesn't add a ton of value, IMHO, both as a contributor & as a user. if entry into the community umbrella is coupled w/ BKMs/contracts/etc, then there could be value to be had, but probably only to those libs that are addons/mixins. pouchy wraps PouchDB, and hence wouldn't fit the mold. it's possible im not seeing the big picture from a cursory glance

[mikeal]

Is there a reason this would be a new org rather than a team inside the existing org?

[nolanlawson]

@broerse: I see much value in using the PouchDB or something we settle on as keyword for all npm packages

I regret not including pouchdb-plugin as a keyword in the pouchdb plugin seed project, and/or encouraging people to use that keyword. 😞 But we could start pull-requesting in order to get it in to more projects.

@mikeal: Is there a reason this would be a new org rather than a team inside the existing org?

I guess the idea is that PouchDB maintainers themselves wouldn't have as much responsibility for the pouchdb-community projects. But then that would call into question why it even exists, if it can't provide guarantees...

[mikeal]

I guess the idea is that PouchDB maintainers themselves wouldn't have as much responsibility for the pouchdb-community projects. But then that would call into question why it even exists, if it can't provide guarantees...

So, this is just from my experience with the nodejs and request orgs, but if you can do something within the main org you definitely should. It gives a greater sense of recognition to the people who get pulled into the org and brings the core project and its ecosystem closer together.

From an access control perspective you can manage pretty much everything with teams but with one big exception: the org owners will have access to all repos, so if there are private repos used by the core project the ecosystem folks won't end up being org owners and if the ecosystem folks need their own separate private repos they'll need their own org.

There's a lot of communication advantages to having it all in one org as well. You can have teams from different plugins that get pulled into core issues that will effect them and vice versa. You can't do this across orgs (@ replies to teams only works within the same org).

The only hazard I see is that you may want to avoid the project "blessing" plugins because it could discourage competitors in the ecosystem. The easiest way to show that isn't the case is to pull in two competitors ;)

[carloslfu]

Another org doing this is electron-userland, the readme shows interesting points to take into account.

[indolering]

I guess the idea is that PouchDB maintainers themselves wouldn't have as much responsibility for the pouchdb-community projects. But then that would call into question why it even exists, if it can't provide guarantees...

I would think that this just introduces a barrier to recruiting plugin maintainers as contributors to the core project.

[nolanlawson]

I've gone ahead and decided to do this, mostly out of necessity: https://github.com/pouchdb-community/

The necessity is that I'm slowly becoming burned out on maintaining PouchDB and so many PouchDB plugins, as well as various other open-source projects, work, hobbies, family, life, etc., and so I had to jettison something.

More specifically, I was finding myself in situations where I was the bottleneck on some PouchDB plugin (e.g. "can you merge this?" / "can you publish this") and by putting them in a GitHub org with several maintainers I'm hoping the bus factor goes up a bit. Hopefully the community will find it useful too!

[nolanlawson]

I also just moved relational-pouch and ember-pouch over to pouchdb-community, because @broerse emailed me to say it's okay. 😃

I'm also open to just making this a team under github.com/pouchdb, but I feel this is a bit simpler and may also lead to less confusion about which plugins are "3rd party" vs "1st party" PouchDB plugins. (Although to be fair, the distinction is becoming less and less pronounced as we moved PouchDB to a monorepo.)