--===============1171833696==
Content-Type: multipart/signed;
  boundary="nextPart1591284.1WQp2Zgo3t";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1591284.1WQp2Zgo3t
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On December 1, 2009, Sebastian K=C3=BCgler wrote:
> Dear Plasma Developers,
>=20
> Please edit the feature plan:
>=20
> http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan
>=20
> 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=20
difficult to edit" to "when someone else editing somewhere else on the page=
, i=20
get to do it over again") and the only time i ever go there is to edit it f=
or=20
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=20
underperforming. trying to force people to use the system as it is won't fi=
x=20
that, it will only increase the amount of time we spend with the=20
inefficiencies inherent to that wiki page.

in this case, i suppose promo wants to know what we've been up to? in that=
=20
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=
=20
doesn't have to chase down N different files in N different places were N i=
s=20
the number of subprojects we have.

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

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

=2D-=20
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

--nextPart1591284.1WQp2Zgo3t
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAksVTs0ACgkQ1rcusafx20PffQCeLmjTbYoBn0SC97+0jR8gBx9i
X/oAoJapjcjDAIfZhr0E9Lq4zHef6URq
=E2Da
-----END PGP SIGNATURE-----

--nextPart1591284.1WQp2Zgo3t--

--===============1171833696==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.
--===============1171833696==--