During my short summer holidays I had the opportunity to perform overdue bug triage for Kexi.
Now "only" 130 bugs of 426 are opened. Below I'd like to discuss some software development workflow-related topics. I think it may be most interesting for people new to the KDE project or those who so far only contribute sporadically and would like to do more.
I am curious how do you look at the bugs.kde.org KDE Bugtracking System. Is it "just" a bug tracking site for you or a project management tool? There were numerous blog entries on the topic but I will share some thoughts on the Project Management aspect.
One can argue that in projects consisted of volunteers we shall not push for project management tools or procedures since everything the project members do is out of their good will. This applies to actual work and commitments or schedules. Volunteers' time is so much limited, why to risk another overhead and boring tasks?
But I would say conversely. Basics of project management can improve quality of the communication by reducing risk of unnecessary work, duplication of efforts or even conflicts. Every project with limited resources (read: every project on this planet) where planning is involved benefits from prioritization of tasks. Similarly, relationships with the customer^w FOSS users require that we have realistic and frequent releases and we plan them in the open, inclusive environment.
To address the needs of more editing freedom, a simple rather minimal approach to Feature Plans for Calligra has been introduced within the KDE Community wikis. It's admittedly, slightly redundant to function of bugs.kde.org but the goal was to have usable tool as soon as possible, providing one “bird's-eye view". The page can be found at http://community.kde.org/Calligra/Schedules/Feature_Plan.
Since Calligra is a family of apps, there is one table per app. For nontrivial tasks I often create separate complex wiki pages (example), and a Wishlist entry in bugs.kde.org. A link to the page can be then inserted in the Wishlist's URL field, what results in two-way references between a task and description page. It all makes sense for nontrivial tasks that involve communication and extra documentation, analysis or planning.
Adding table rows in the wiki is simplified thanks to extensive use of wiki templates (but let's admit, still error-prone), e.g.:
If you look closer, the tables have sortable columns, so one can group tasks by status (TODO, In Progress, Done), description, optional git commit, contact person, and target release. Formalized short component name (e.g. KexiDB) goes first in the Description, so the sorting works nicely.
Previously there was one Features page per minor release but it has moved to a single page, with extra Target release column, so tasks can be freely moved between release. The table can also help to craft change logs based on key changes in a bit more convenient way than the read-only git logs.
Should you have special bits of your workflow or ideas, please share them in the comments.