features progress list

[Jaroslaw Staniek]

On 19 June 2012 22:52, C. Boemann <cbo at boemann.dk> wrote:
> On Tuesday 19 June 2012 22:43:31 Cyrille Berger Skott wrote:
>> On Sunday 17 Jun 2012, C. Boemann wrote:
>> > Now while in theory I like it, I also dislike that the height of each
>> > entry thus will grow to more than one line of text.
>>
>> That said the branch could be simply replaced by just the link. I just did
>> the change on the webpage and it now takes one line. And with a bit of CSS
>> work, the status, branch and target columns could be reduced (it would
>> also be good if KDE's CSS designer could learn to make CSS with dynamic
>> page width for wikis...).
> Ok, with some work on the css it could work.
>
> Maybe use the description as the link. Then we don't need a separate column.
>
>> > When having features for all future versions and for all applications,
>> > then we have a very long list. And when many people don't seem to keep
>> > the list up to date we get a lot of cruft, with no regular releases to
>> > clean out. (eg look how the krita 2.5 list was not updated, since I
>> > copied it from the 2.4 list)
>> >
>> > I fear this will be an unmaintained mess pretty quickly
>>
>> That is an other argument for having the column with targetted version.
>> Since we could simply remove all features that have missed two releases.
> Ok let's give it a try
>
> But we really need the CSS
>
> jaroslaw, will you be able to do that?

If I understand correctly we need a view that lets us to focus on
current work, i.e. version, with ability to browse throught past
versions. Like a filter, for project management. Wiki is limted here
(has sorting) and wiki user CSS isn't enabled IIRC (I also vote
against enabling it). Good solution could be a mediawiki plugin in PHP
so intelligent tables can be embedded transparently. Why isn't this an
idea for GSoC? Bugzilla sucks even more here since its origins is bug
tracker (in UX aspects it's now even worse that trac now...). My ideas
you already heard from me:
0. keep the Calligra/Schedules/x.y/Feature_Plan pages as before, and
look for right solution
1. right solution could be to eat own god food (Plan, Plan + Kexi db,
Kexi db, with some integration with bugzilla as external system)
2. go for working solution (e.g. JIRA which is used by qt-project;
since it's free but closed solution, we could just 'buy' a lot of time
to switch to idea 1.)

Please note, project management database for Kexi is planned anyway,
so it _will_ eventually happen, with possible fine reuse of Plan's
components and data models.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra.org/kexi)
 KDE Software Development Platform on MS Windows (windows.kde.org)