Update The Feature Plan! NOW!

[Aaron J. Seigo]

On December 1, 2009, Sebastian Kügler wrote:
> Dear Plasma Developers,
> 
> Please edit the feature plan:
> 
> http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan
> 
> I'm looking over it, and it all does not make sense. There are many items
>  which should be green, but are yellow. That means that you, my fellow
>  developers did not update it. I'm not going to run through them all,
>  everything yellow might simply not be in the list of new and improved
>  things in for KDE SC 4.4 as I cannot confirm for every single item in
>  there if it's in and if it's supposed to work.

this happens every release. why? simple: time and effort.

the wiki and its tables is a complete PITA to edit (from "the format is 
difficult to edit" to "when someone else editing somewhere else on the page, i 
get to do it over again") and the only time i ever go there is to edit it for 
the beta/rc cycle. there is no other reason for me to go there.

imho, this is one area where both our rel eng and our promo is currently 
underperforming. trying to force people to use the system as it is won't fix 
that, it will only increase the amount of time we spend with the 
inefficiencies inherent to that wiki page.

in this case, i suppose promo wants to know what we've been up to? in that 
case:

http://websvn.kde.org/*checkout*/trunk/KDE/kdebase/workspace/plasma/design/CHANGELOG-4.4

the nice thing about the wiki page is that it's all in one place, so promo 
doesn't have to chase down N different files in N different places were N is 
the number of subprojects we have.

unless other developers are completely happy with the wiki, why don't we fix 
this whole situation and come up with a better centralized location for these 
things? a rel eng module in svn with schedules, plans and "effort highlights" 
changelogs might work nicely; iirc our feature planning used to be in an xml 
file in svn that was processed into html to be displayed on the website. that 
worked pretty well, though even that could be improved on.

is there any possibility of improving the situation rather than flogging a 
dead horse?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091201/c4ba3c74/attachment.sig