When we say complete, we don't necessarily mean all functionality is implemented, but if the functionality is indicated to be present, it must work. It must not segfault. If there is some chunk of code or stub sitting around for future functionality that will not have time to get completed, it should be commented out or somehow hidden. Users of KDE 2.0 will be expecting things to function perfectly. It is better to have no functionality than broken functionality in a final release.
Broken functionality generates bug reports.
We will try to coordinate action items and deadlines in a consistent yet time-aggressive manner. This timeline is very aggressive, but necessarily so. We need to get KDE 2.0 stable and available to develop applications with, as many third party developers are starting to depend on Qt and KDE 2.0 functionality. KDE 2.0 has been in development for over a year at this point. It is time.