features progress list

[C. Boemann]

On Wednesday 20 June 2012 08:23:29 Jaroslaw Staniek wrote:
> 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.)
> 
No No. We don't need filtering or anything. Just an update version of what we 
had. Updated meaning that it handles the extra column for version and a narrow 
column (1 char) for link to git.