Community conduct and standards

[sidhuko]

Having tried to use a few serverless plugins lately, to be respectful I won't name them as I appreciate the effort of contributors, it would be good to see some community standards before they are accepted on the official list. Often you'll see tickets or threads on the forum pointing to a plugin to use for a particular plugin which at worst does not work at all, varies from serverless standards (names over refs) or does not support LTS versions of node.js. As these are recommended on this list it produces mistrust on the quality of the serverless ecosystem.

Some of my grievances are:

• inconsistent semver
• lack of changelog and contributing documentation
• lack of CI testing (or tests altogether)
• unstated support for node and npm versions.

I support the proposal made last year to create a community plugin organisation (�serverless-plugins) to adopt widely used plugins so you don't have a single point of failure on one contributor to accept patches, or worse, release breaking changes unexpectedly. These packages can be managed to a higher standard by common contributors although the bare minimum could be to instructing (teaching perhaps) plugin developers, hoping to be on the list, to use a model for minimal acceptable standards (Travis CI builds for LTS versions of node, testing, linting, code quality tools, changelogs).

[blairanderson]

I totally agree

Which is why I started tracking & ranking all the serverless plugins

[sidhuko]

Have you thought adding your work as a PR then using github pages? I think one of the key things is to not only take advantage of a community but help lead it to better times. This framework is losing the fight to others tools such as terraform in my experience - although this has limitations which I'll admit serverless addresses. Even considering producing a terraless framework to help a migration path for users from serverless to terrafrom.

[blairanderson]

Every plugin that is accepted into this repo gets tracked at the above site. Also, There's no reason to bring in fear mongering about projects "losing the fight" to other projects. Achieves nothing

…

On Feb 2, 2018, at 3:59 AM, James Sidhu ***@***.***> wrote: Have you thought adding your work as a PR then using github pages? I think one of the key things is to not only take advantage of a community but help lead it to better times. This framework is losing the fight to others tools such as terraform in my experience - although this has limitations which I'll admit serverless addresses. Even considering producing a terraless framework to help a migration path for users from serverless to terrafrom. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sidhuko]

Every plugin that is accepted into this repo gets tracked at the above site.

That's irrelevant to my ticket and shameful plugging - I didn't ask for a third-party site which doesn't address key concerns in the issue such as the community propagating use of supported plugins that just don't work. This ticket is not an attack on anyone but a reflective contribution to see what changes can be made to the community as a positive.

Also, There's no reason to bring in fear mongering about projects "losing the fight" to other projects. Achieves nothing

Funny because I point to fundamental differences between the two projects and where I'm happy to continue using serverless but two high profile clients are looking into alternatives for new and existing products. My suggestion was terraform addresses certain pitfalls so a plugin/framework turning serverless configuration into extracted terraform may benefit those struggling directly with AWS caveats in CloudFormation but prefer the declarative syntax and plugin system of serverless. Please feel free to question that opinion rather than express your own personal commitments to your consultancy services.