[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    releases
From:       Thomas Zander <zander () kde ! org>
Date:       2007-07-07 11:05:04
Message-ID: 200707071305.04587.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Morning!
I've been wondering if I should speak my mind on some issues; I don't want 
to be a 'boss' here, but at the same time I feel these issues need to be 
taken seriously if we want to release a KOffice2 we can all be proud of.
So, I'll take the chance, please don't feel offended, just take home the 
lessons I learned the hard way;


* It is very useful to put effort in first implementing GUI technologies 
in your KOffice app which lean on classes in KDELibs and Qt. We are one 
of the few mature application suites using these libraries and there will 
probably be bugs or worse.  And if you find them too late in the cycle 
everyone will suffer.
So, change those priorities and bite the bullet. It will get harder if you 
wait longer.

* Use the extreme programming concept of setting your TODO priorities 
based on how hard they make your app to use RIGHT NOW.
Or, in other words, if your application is not usable / crashy / etc due 
to a problem put resolving that highest on your priority list.
I have heard people say that KWord is pretty complete already; which is 
funny since things like find or save are basically not there yet. The 
reason people think this is because the basics are there and the 
application is responsive and doesn't crash (well...).
Lets take KPresenter as an example; it currently is not very usable due to 
there being almost no actions available from the menu to alter the app. 
In fact, if you don't have an empty doc, you can't even start it. Just 
adding a 'new page' menu item and one empty template makes the 
application look a LOT more mature already.

Bottom line; don't wait for the next release, work on stuff based on the 
idea that your application can be released tomorrow and look its best.

So, like we had to wait 2 months before someone reordered the tools in 
krita to make sense, lets put some time in finishing the work done to 
make them shine a bit more and we all feel better about the progress we 
are making. Finishing a feature is a higher priority than starting one 
that you think should really be in the final release.  Again; order your 
TODOs as if you are releasing tomorrow.

* I hear quite often that people want a class to be a public API (aka 
install the header file). While that's fine in most cases; I notice that 
the lessons learned on what makes good libraries are then ignored :)
Specifically; it typically means the class should from day zero have a 
d-pointer, should have totally no implementation in the header file, 
should have library quality API docs and should follow our design and 
naming principles. (see EBN for the current state)
Honestly; if you want to make something a public class, then you must take 
the responsibility to do these things.  Its just rude to expect someone 
else to do the boring work.


As an ending note; I have seen people walk away from the KOffice codebase 
because it is not mature enough for them to hack on. The last 2 points 
are aimed directly at countering that. We should polish our features and 
write more unit tests so they don't regress and we avoid not moving 
forward in many different respects.

Lets make a great KOffice2 release, people!

Thanks for reading :)
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]