Update The Feature Plan! NOW!

[Diego Iastrubni]

I have an idea which might help in qt4.5:

1) How about marking each feature with a mark similar to: plasma-4.5-1, 
plasma-4.5-2, plasma-4.5-3 - etc.
2) (somewhere) in the plasma SVN, programmers should be able to edit the SVN 
copy. 
3) When feature list is frozen, the pages on SVN get locked and only "people 
with enough karma" will be able to modify it
4) "People with enough karma" will then only need to look into changelog files 
for simple text - and just move text around.

My main idea is:
a) developers may touch wiki until feature freeze
b) promo team is then dealing with those pages - less people to sync. 

(b) will fix most of the issues you reported: locking of pages, developers not 
understanding the HTML format (IMHO people who do it several times will be 
better at modifying the HTML).

I am aware that this brings lots of work to everyone - but this is one 
solution for this large scale problem.

On Tuesday 01 December 2009 19:13:49 Aaron J. Seigo wrote:
> 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?
>