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

[Andreas Neustifter]

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