Define the goal of gulp-community

[demurgos]

The meta repository should clearly state the role of the organization in its README.md.

What are the reasons to move packages to gulp-community?

[demurgos]

Here is a first proposition.

One-liner description:

Gulp Community is a collaborative effort to maintain the Gulp ecosystem.

Here are some of the points that I'd like to discuss to know if they are part of the scope of the organization

I think the org has two goals:

• Ensure that there's always someone active with write access to the plugin
• Promote high-quality/blessed plugins

Regarding the first point, it defines a bare minimum.
The projects can be in maintainance-only mode (only deal with Gulp and Node changes), mature (no major changes, just fix bugs and keep up with changes in related projects (babel, scss, less, pug, handlebars, eslint, etc.)) or still evolving.
This is mainly about deciding how packages in Gulp-Community should accept feature requests? I'd prefer to avoid Gulp-Community to only have "finished" project, but to also host active projects.

Regarding the second point, I expect that we'll have requirements and guidelines for projects hosted here (do we agree here?). If so, should we explicitly try to act as a "curator" for plugins? This may help users to decide which plugin to choose but may raise the expectations. It may cause a higher ponctual cost at migration but I don't think it changes much in the long run. For example, there's a lot of plugins to minify CSS: we could pick one and recommend it. A related point is: should we try to avoid having duplicate projects solving the same use-case?

[phated]

@demurgos I'm a little worried about having "blessed" plugins - as I don't want the "grunt-contrib syndrome" to happen. That being said, people will probably turn this org into that so I think clear messaging around that is important.

However, I do believe that the plugins here should adhere to the "plugin guidelines" as specified by gulp proper - and they may even move here instead of existing in the main organization (thoughts?). We've long had the idea to have a CI/test-suite that would flag incorrect/violating modules and maybe that's a good thing to exist here too.

In general, duplicate/forked+republished/etc plugins have been blacklisted in an attempt to promote collaboration (and again, to curb many grunt issues) - you'll often find them to be either a slight variation on an API or else they are a huge amalgamation that break the guidelines (do one thing!). I'm open to discussing this more to see if it still makes sense.

[demurgos]

Could you expand on the "grunt-contrib-problem"? I used Grunt a bit but it was a long time ago, I am not very aware of the problem.

Regarding the guidelines, I plan to open further issues to discuss the details. I think that this repo could be a good place to host them. The benefit of having projects under this org is that you can enforce these guidelines (turn them into requirements).
Agreed that having some way to check the guidelines would be good. I haven't looked into it yet but it's a problem that I am also interested for my personal projects.

Regarding forked/republished plugins, how are they blacklisted? On the Gulp website?
I am in favor of only accepting one project per "problem solved" in this org, even if it means to refuse maintaining another similar popular plugin.

[phated]

@demurgos the grunt-contrib problem was that they started creating blessed plugins - that were promoted to the top of their plugin list and made to stand out - and started absorbing features of other plugins. I originally created grunt-jade but as soon as they made grunt-contrib-jade, I quit working on it. We don't want to be the only place people look for plugins - it's more about maintenance (with quality tacked on).

The blacklist is just a filter on the gulp.com/plugins site. Maybe we can accept duplicate projects and merge them then archive one? I kind of like that idea.

[demurgos]

Ok, thanks for the explanation regarding Grunt.

Yep, I don't want to create a situation were people avoid plugins that are not on this org.

• This org should only accept existing packages that have proven to be popular. It should not create new projects competing with existing ones; or even start new projects because of a new tech. Start the project outside and move it here later on if needed.
• The plugins should still be published on npm as gulp-*, not moved to to an org like @gulpjs/*.
• We should not force the hand of maintainers to move their projects here. If they are comfortable supporting their project, let them continue.

I haven't though of the archive idea, I like it too.

---

Tagging @gulp-community/overlords (BTW, just noticed the name of the team 😄 )

[A-312]

I'm not the best one to write a English presentation but your comment seem good to be added like that.

[phated]

Some more things that I've been thinking:

• Projects in gulp-community should have a consistent structure. I'm building tooling to automate sweeping upgrades in the gulpjs organization and it would be nice to apply those here.
• Our plugin guidelines are very outdated, but they will be rewritten at some point. Once that is done, we should ensure that all projects here follow them pretty completely. These will likely serve as a reference for anyone building new plugins.
• We really need to nail down testing. I've done a ton of work around stream testing for gulp 4, but none of that has been adopted by plugins.