KWord is an application that uses the text (flake) shape to show text-based documents with arbitairy page sizes and it can do a lot of DTP-like functionality due to the featureset that Flake brings to the table. Since the main text layout and rendering core is moved into a flake plugin this can be used by any KOffice application and thus most of the KWord functionality is available across all apps. How this is done is to use the KoText library to contain the text loading code and various interfaces (APIs) for using text in an application. Most of the functionality is kept out of the KoText library to keep it small to link to and the real code all lives in the text shape (which can be found in the koffice plugins dir). KoText allows the placement of the text-lines to be reimplemented differently, so KoText has a powerful, but not very featurful version that is used everywhere except for KWord. KWord implements its own text layout class which has additional features that only a word processor needs.

After this 10km overview here are some pages with more details and design documents;

Text engine restructuring

Calligra/Words/Layout restructuring To do list

Current Design Explanation

Calligra/Words/Tutorials List of tutorials relating to ODF and KWord
Calligra/Words/Tables The tables in KWord can be based on Qt tables, here is how Qt tables work at the low low level.
Calligra/Words/RequirementSpecifications/ChangeTracking Requirement specifications for Change tracking.

Text Engine restructuring

Calligra/Words/LayoutRestructurings List of tutorials relating to ODF and KWord
Calligra/Words/Tables The tables in KWord can be based on Qt tables, here is how Qt tables work at the low low level.
Calligra/Words/RequirementSpecifications/ChangeTracking Requirement specifications for Change tracking.

Future Design

Calligra/Words/Text_Styles_UI_Mockup A UI mockup for a re-work of the text styles tree.

Usecases for new tech or 'in-development' stuff

Calligra/Words/Master Documents Explains how a master document can make life easier.
Calligra/Libs/KoText/Change tracking What do we want to do with Change Tracking then?
Calligra/Libs/KoText/Text Plugins Usecases for writing plugins for the text shape. And which technology to use.
Calligra/Words/Scripting Scratchpad for scripting. Nothing final, just designing at the moment. Input welcome.

End User Ready

In order to make KWord end user ready we have to know who the end user is. Turns out that there are different definitions which give different answers. The full details can be found at Calligra/Words/EndUserReady/Personas

Bug processing

We had some emails that stated confusion about the KWord bugzilla usage. The best way to help out with bug triaging and reporting is a lot easy to find after the process used by the KWord maintainer become clear.

Bug processing is done in 3 steps; first a priority is set, this includes a "release_blocker" tag. Second a bug is marked to be reproducable by setting it to 'new' or closed as fixed. Last, the bug is fixed and closed. It is important to realize that the prioritizing is something that is a continues thing; all bugs should get looked at reasonably fast in order to find release blockers and know what the state of the product is and not release something with already reported but not yet noticed release blockers.

When the above paragraph talks about prioritizing bugs this means in practice two things; release-blockers are marked as such (using the keyword) and one of the personas is selected.

After prioritizing there will be an order; stuff marked as release blocker comes first, stuff marked for persona Susan next etc. The next two steps are done in that order.

All bugs that come in are in the 'unconfirmed' state. This typically means that the bug is not reproduced or has other issues that may still need to be proven in order for the bug to be marked as a real bug. Proof may be asked for things like a user attaching a docx and claiming there is a rendering issue in KWord. What needs to be determined is if the issue is really a missing feature (and should thus be marked as wishlist). What needs to be determined as well is if the importer (filter) may have an issue or if its a KWord core issue. Ideally an odt is attached that is verified to have the feature. Last; a more detailed textual description of the actual issue should be given. A simple "document looks wrong" or similar is not useful. Ideally we get a document with a minimal example of the issue found.

After something is confirmed as a bug and cleaned up the developers will typically attack the list of bugs based on priority. Something marked with the lowest priority will likely not be fixed until all the issues with higher priority are fixed already. (so if you are a bug triager, feel free to ignore bugs that are prioritized with the Berna persona etc.)

A bug that is unclear and needs more info is closed using the 'needsinfo' resolution (NOT using resolved)
A bug that has not received any update or new information after 6 weeks will get closed.