Community Maintainer Guidelines

If we’re going to start having more people involved in Jimp’s development, it probably behooves the community to have clear answers for common questions like:

• If I have a question, what do I need to do to get an answer?
• When can an issue / PR be closed?
• When making pull requests, what are code style and syntax guidelines to follow (there are several active issues about ES2015 / typescript / .editorconfig / coffeescript right now)
• What are the testing requirements for PR’s to be merged
• Automated testing?
• Jimp conventions & clear development priorities
• Running list of bugs to be fixed and desired features for development

Additionally I think some conventions might be useful. For example, I think we’re starting to have a need for “optional” parameters to be passed into some Jimp function, and other Jimp functions which accept so many parameters that having them in a specified order becomes confusing. Mrdoob of threejs draws the line at three, but the terrific work in https://github.com/oliver-moran/jimp/pull/191/files implements a function with seven:

Jimp.prototype.composite = function (src, x, y, mode, opacitySource, opacityDest, cb)

Should that be this instead?

Jimp.prototype.composite = function (src, options, cb)

where options is an object with defaults like:

{
   x: 0,
   y: 0,
   mode: Jimp.BLEND_SOURCE_OVER,
   opacitySource: 1,
   opacityDest: 1
}

?

All just food for thought.

[iwsfg]

Perhaps, I should be more clear. That was in regard of npm://standard. I don’t like the way it’s being presented. There’s no standard guideline. The fact that Isaac and some other guy on the web like that particular code style doesn’t make it standard. The fact they have fancy name for their package doesn’t make it standard either.

We have configured ESLint on test branch though, it works just fine and doesn’t require existing code style to be changed all that much. And existing code is pretty consistent in its style too, so why change?

[iwsfg]

“standard” style guideline

No thanks.