[KPhotoAlbum] Future Roadmap and Development (was: kphotoalbum method of storing Tags, description)

[Joe]

On 01/30/2012 05:01 PM, Andreas Neustifter wrote:
> Hi All!
>
> On 30 January 2012 12:14, Risto H. Kurppa<risto at kurppa.fi>  wrote:
>> As Miika said, it is possible to write code to implement this.
>>
>> However, in projects like this, to implement new features, two types
>> of people are needed (who can be one person):
>> (1) the developer one who WRITES the code. Anyone with the skills is
>> free to do this, no matter what others think.
>> (2) the project maintainer one who ACCEPTS the code to be integrated.
>> Here the acceptance of the community is very useful but not a must.
>>
>> The community members with no coding skills has no ways to push the
>> developers to implement anything. We can only add wishlist items (see
>> http://tinyurl.com/kpa-wishlist ) and hope that someone picks our
>> ideas up. In that sense, only the developers have the power. But on
>> the other hand when a developer writes the code, he has no way to be
>> sure that the project maintainers will accept it. So in that sense the
>> power is divided between the developers and project maintainers. The
>> rest of us can only make wishes and hope that the project goes into
>> the direction that makes us happy.
>>
>> In KPhotoalbum's  case, Jesper/blackie has been the one with the
>> 'final word' what will be committed and what not. Now as he's focusing
>> on other stuff and there are around 5 people (just a guess) with
>> commit rights, again I want to remind that some kind of common vision
>> / direction / roadmap would be useful. It'd help both the developer
>> and non-developer community to see what's the direction the project
>> maintainers want to take the project.
> I agree with that but also want to add some comments:
>
> I think we all agree that KPA needs more focus and well tought out,
> solid features and less "bells and whistles". So all developers with
> commit access should strive to discuss all new features before
> accepting them into the code base (this is harsh, I know, but
> necessary).
>
> Also commiters and developers should discuss there efforts before
> working to hard on them, there may be good ideas from the community or
> a consensus that a given feature will not be well suited to KPA. (Yes,
> I'm too guilty of hacking away on personal pet features that may have
> been to much :)
>
> To sum up my opinion: First there will be a new release that contains
> everything that is in GIT right now puls all necessary bugfixes.
> ("Better" is the enemy if the "good" here, bugs that are not blockers
> may be fixed only after the release.)
>
> After the release a discussion on the future of KPA should ensue (yes,
> in this order, otherwise the discussion diverts resources from the
> bugfixing/releasing). I have no idea how to collect the information
> from that discussion, I presonally hate to have "whishes" mixed into a
> bugtracking tool.
>
> This future roadmap should be broken down into self-contained features
> that push KPA into the discussed direction. That features should
> either be the most frequently requested from the users or the easiest
> and quickest to implement. The way the features are implemented should
> be discussed first too, I guess. Hm maybe, or not, I don't know about
> that.
>
> Okay, thats enough of my opinions.
>
> Andi
> _______________________________________________
> KPhotoAlbum mailing list
> KPhotoAlbum at mail.kdab.com
> https://mail.kdab.com/mailman/listinfo/kphotoalbum
I'm not a developer of KPA, but I'll add a few comments anyway.

I agree about wish lists in bug trackers.  A number of projects do it 
that way and say that it's the only way the developers will ever see 
them.  Bugs and wishes are largely unrelated and combining them can 
cause someone with the best intentions to go off and code a shiny new 
feature instead of fixing an important, but unglamorous bug.

Wishes/feature requests do need to be in some kind of tracker so they 
don't get buried in a long term discussion list and can unambiguously be 
identified in discussions.

If someone wants to contribute, there should be an easily accessible 
list of things people already want done along with any comments from 
developers and users about how to do it or what's involved/impacted.

I also like the feature some trackers have where members can vote for 
issues so people can see how much real interest there is in a particular 
item.

I don't know the first thing about implementing systems like this, but 
open source projects are using them, so I know they are available.

Having a road map/vision is what distinguishes good projects from great 
projects.  It's essential to developing a system that makes sense and is 
consistent - not only with respect to new features, but also determines 
what current features may need to be enhanced or even eliminated.

In my first programming job, I was given an assignment to add a number 
of features to a program that was a precursor to spreadsheets (It had 
everything except the essential concept of formulas in cells.  I'm 
dating myself!).  I wrote some very nice code that really impressed my 
employer, but it was so tightly self-integrated that it was thrown out 
because it wouldn't merge well with the rest of the program.

In short, the way things are implemented matters!  Not only from an 
integration standpoint, but also so that once a designer/coder/(or 
heavens forbid, a documenter!) learns how one part of the system works, 
most of that transfers to the rest of the system.

This should (at least theoretically) promote code ,KPA, make it more 
likely that, once a problem is solved in one place, it can be solved 
everywhere else with little additional effort.

This also applies to functional changes that affect the overall 
program.  It should be "easy" to make a change throughout the program 
without having to recode it several different ways.  From what I 
understand, these issues were the major motivation and success of object 
oriented programming in general (regardless of whether part or all of 
KPA is coded that way.)

And, last but not least, please remember to include documentation as a 
priority.  A program is only as good as people's ability to figure out 
how to use it and what work flows are most productive.  This is KPA's 
most serious "bug".

Turned out to be more than "a few comments" .  ;)

Joe