Collaborators wanted!

[oliver-moran]

Folks,

When I created Jimp in 2014, I didn't expect it to become such an important part of so many projects. Over the last few months, there have been so many great feature requests, issues raised and pull requests.

That's wonderful. It shows that there is a real community behind this project. That's something that I never imagined in 2014. I am humbled and grateful to everyone who has committed their time, energy and expertise to the project.

At the same time, it's clear that the significance of Jimp has moved beyond my abilities to actively administer the project on my own. So I am looking for GitHub collaborators with a view that in time Jimp will move into genuine community ownership.

With that in mind, I've invited the @strandedcity to become a collaborator. He/she has been the driving force behind the browser version.

If anybody else is willing to take on the work of bug fixes, integrating pull requests, etc. please says so below.

For now, I'll keep publish rights to NPM but in future I hope to share that with the community too.

Oliver

[aurium]

How effectively can we help to integrate pull requests?

• test it;
• evaluate code quality; (how?)
• other detail?

[strandedcity]

Oliver,

Congrats on Jimp's success! You've fostered a great piece of work, and I'm likewise humbled to become an ongoing part of it. It's great that Jimp has become such a useful and popular project (4,500 daily downloads on NPM, wow!). I see people have been using it in Electron apps as well, which is also very exciting.

Real life has been crazy for me lately, but I'll try to make sure to carve out some semi-regular time for the Jimp community once things clear up next month. I see there are all sorts of pull requests and issues live; the sign of a healthy and vibrant community project for sure. Community projects need love and attention of course, and I'll try to bring both.

Thanks so much for creating the community, I'm honored to be a part of it!

Phil

[strandedcity]

@oliver-moran it seems like @iwasawafag has also been contributing actively. Another community maintainer to add?

[iwsfg]

I do not know much about inner workings of many operations in image processing, so I doubt I'm a good candidate for the role. Never heard of a Convolution Matrix for instance, not until I came across #185.

Personally, I'm fine with just sending Pull Requests from time to time

[strandedcity]

Fair enough, though the image processing Jimp does (up until that PR) is relatively straightforward.

@oliver-moran one other question here... When I contributed before, I was able to run the tests to make sure I wasn't breaking anything, but now the tests don't seem to compare the Jimp output to anything. They test that the various functions run, but there's no way to know the results are correct. Am I missing something?

[oliver-moran]

@iwasawafag I never heard if it either, so your help is as good as mine :-)

@aurium good questions!

Test it

There is a test script but, like @strandedcity says, it does nothing more than run through every method and makes sure that nothing throws an error.

I suggest we need genuine unit tests that does the above but also checks the outcome. This isn't hard. Jimp itself can check one image against another. All we need is to check the output of the current script against a set of images representing the expected outcome.

Would be nice to automate these unit tests before accepting pull requests.

Evaluate code quality (how?)

The code quality of PRs have been very high. The most only refactors I've done have been to integrate with the philosophy and API pattern that Jimp was originally written in.

That's a very soft concept to evaluate but at the same time we all know the importance of a consistent philosophy/pattern in an API.

Perhaps a contributors' style guide would help?

Other detail?

Something to look out for is that changes have come in the form of feature requests/bug fixes and sample code rather than proper pull requests.

I've added @aurium and @iwasawafag to the list of GitHub contributors.

[iwsfg]

This was a little sudden. I can't promise to be very active here on a regular basis as I have other projects that needs love, but I guess you could use an extra pair of hands, so I'm going to accept this generous offer. Thanks for putting your trust in me, I'll try my best to be helpful.

I would like to ask few questions as well:

What's the scope of the project?

There isn't a single issue with label "Wontfix", not many pull requests rejected either and features suggested in issue tracker vary from highter level manipulations like drop shadow effect to drawing API. So I find it hard to tell if originally it was supposed to provide low level API for image manipulation or should it be offering highter level APIs as well?

Also what is the main concern? Is it keeping file size reasonable or adding more syntax sugar to make it easier to use instead? If it's latter - it may get too heavy for use in browsers one day. Should modular architecture be considered for some features? Maybe something like image.draw.lineTo(x, y) as far as syntax goes.

And how do Collaborators should decide where they're taking the project?

Should new features be discussed on the issue tracker first and possibly wait for your (@oliver-moran) approval then submited as Pull Request or everyone is free to work on whatever they feel like?

[aurium]

Thanks @oliver-moran!
I can work on unit tests, beginning on next week.

[oliver-moran]

I find it hard to tell if originally it was supposed to provide low level API for image manipulation or should it be offering higher level APIs as well?

IMHO it's as low level as Gimp. So any individual method that's useful in image manipulation is fair game - but if a feature starts to get a life of its own then it should be spun out as a separate project.

For example, in the past there was a stab at creating a command line interface. Initially, it was assumed that the CLI would be part of Jimp itself. However, a decision was taken that it would be better to have Jimp as one project and the CLI as another.

I would take the same perspective with something like a high level drawing API. It sounds like something that is worthy of an project by itself. Likewise, if the number of "special effect" API, like drop shadows and the like, start to grow out of control then maybe these should be spun out as separate (optional) packages too.

Also what is the main concern? Is it keeping file size reasonable or adding more syntax sugar to make it easier to use instead?

I'm a UX guy. So I come from the perspective that if you need sytatic sugar to make it easier to use then the problem is that it's hard to use.

Philosophically, I think a Unix approach to each method is best. Each method does one thing. Does one thing only. And does that one thing well.

Should new features be discussed on the issue tracker first and possibly wait for your (@oliver-moran) approval then submitted as Pull Request or everyone is free to work on whatever they feel like?

Don't wait for me. I trust your (community) judgement. It's the only way. Ping me when you want a release to NPM.

The only thing I ask is that backward compatibility is maintained unless there is a (well thought through) decision to jump major/minor version number.

I can work on unit tests, beginning on next week.

Thank you! I think this is the top priority. If we could get automated integration testing for each pull request up and running then I think that would be brilliant.

[aurium]

I see Jimp much alike GEGL, where real work happens. Jimp may learn something from that project.

[aurium]

If anyone like Telegram and want to talk about Jimp, I would like to do so! Call me! 🙂

[abritinthebay]

Open to helping!

Re: code quality. Things like ESLint standards really help not just from a consistent style point of view but also avoiding bad practices.

For a library like this Benchmarks would make sense too: does a PR slow down a function? Is it faster on certain file sizes? Etc.

Looks like testing is probably the main place to start now tho...

[rafaelcastrocouto]

Hey guys, I've just found out jimp (it's awesome) and after some google I could not find any editor.
Is there a editor/playground/"photoshop like"/wysiwyg that's using jimp?

[iwsfg]

If anyone like Telegram and want to talk about Jimp...

How about IRC? I would love to use it to ask other contributors about what stopping us from accepting some of those pull requests that don't have any problems with them?

I would like to start accepting those and if person submitted them does not respond in a long time – modifying as I feel needed and accepting them anyway.

Is there a editor/playground/"photoshop like"/wysiwyg that's using jimp?

Not that I know of. Honestly, I doubt somebody will try to build one on top of Jimp. In browser WebGL is available and it's much faster and for standalone application native code will always win over JS. As for "playground" - RunKit works, but still requires writing code - it's not a graphical editor. Can displaying images though. Example. Is this what you're looking for?

That said, we should probably include a snippet to be loaded in RunKit by default