[KPhotoAlbum] Improved Image Viewer? [PATCH]

[Shawn Willden]

Thanks for the response, Jesper, and thanks for taking it in the spirit in 
which it was intended.

On Wednesday 20 December 2006 23:30, Jesper K. Pedersen wrote:
> I'm afraid that the world unfortunately is not as black and white as this.
> I do want to share. I do realize that the project could run much faster
> were we several people to take care of it. Unfortunately, the 4-5 people
> I've asked to step up so far has all sayd no.

:-(

> Regarding packing, man have I asked for this forever. I don't have time,
> nor interest, and esp not abilities to pack for a lot of different systems.
> I've tried to pull of that I contacted the big players asking them to pack,
> but even that takes a lot of time. So by all means, HELP!

Okay, I'll try.  It shouldn't be too hard to build Debian packages, since I 
can use the kphotoalbum package in Debian as a starting point.

> Regarding patches. The reason for my response is that I'm older than many
> of the other projects maintainers, and thus more wise :-)))
> Seriously, I always have to compare the time it takes to integrate a patch
> with writting the code myself. Over the last few month, I've had very
> little KPA time as you may know. Most of that time has been spent on
> integrating patches. That includes everything from ensuring the correct
> naming convention to the right way of doing it. I DO WANT MORE PEOPLE TO
> CONTRIBUTE to the project, but by far I prefer people contributing a longer
> time with many patches than just with one monster patch, and then running
> of.

Hmm.  I have some suggestions that may help.  They may be things you've 
considered and discarded -- perhaps for good reason -- but I'll offer them 
anyway.

1.  Perhaps it would help if you put together a brief (1-2 pages) style guide 
that covered most of your key requirements regarding structure, naming 
conventions, etc.  That way when you get a patch submission, you could point 
to the guide, and ask the submitter to please comply with those guidelines.  
That might reduce (though not eliminate) your patch integration effort.  If 
you're not sure what to put in the style guide, just build it bit by bit as 
you notice problems in patches.

2.  When you get patches that comply with the style guide, but still don't 
meet your expectations, I think it might be more effective if you push back 
on the submitter and make them fix the patch, even if it ends up delaying the 
patch integration, and even if it seems easier just to fix it yourself.  What 
you'll get out of this longer and more tedious process will not only be a 
good patch, but it will also be an educated contributor.  Of course, telling 
people to fix their code without making them angry at you isn't easy.

3.  Raising the quality of the required patches may reduce the flow of 
patches, so you also need to increase the number of people willing to 
contribute, and I think Lars' suggestion is a good way to do that.  If you 
could provide some documentation on the structure of KPA so that potential 
contributors could get into the code quickly and easily, more people would be 
willing to help out.

All three of these ideas are, of course, more work for you in the short term, 
but I've seen in other projects how they actually help a great deal in the 
longer term.

As I said, I'll explore creating Debian (and maybe even Ubuntu) packages of 
your snapshots.  Also, I'd be happy to help with structuring and critiquing a 
kphotoalbum architecture document, although you'd obviously have to do most 
of the work.

Thanks,

	Shawn.