75172 - FeatureZilla - an integrated SW development tracking tool

Status: RESOLVED DUPLICATE of bug 9412

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Andreas Franke (gone)]

Bugzilla can deal with bugs (i.e. with defects in software, or in a specific
part of it), but it is not really good at tracking other aspects of that
software and its parts (which we'll call "features" from now on), or even the
relationship of features with respect to each other and the software as a whole.

Recent symptoms of this lack of functionality:
- Gerv's "Features Update" on mozillazine was a great success since this
information could not easily be found elsewhere. See
http://www.mozillazine.org/talkback.html?article=1854
- chofmann's "Branch Landing Info Roller Upper and Carpool Reservation Hack."
was developed as a standalone tool. See
http://komodo.mozilla.org/planning/branches.cgi

Both of these would benefit from a tool for integrated feature development
tracking.

Comment 1

[Andreas Franke (gone)]

"feature"s can have "sub-feature"s, so there should be a feature hierarchy.
Probably some things belong to more than one parent feature; to represent this,
a tree structure is not sufficient, instead a DAG (directed acyclic graph)
structure is needed. 
Ordinary (non-feature) bugs could be seen as leaf nodes in this model. For these
leaf nodes, multiple parents are a necessity: All those bugs about feature A not
working together with feature B would have both A and B as parents.
 
Each "feature" should be able to store at least the following information:
1. links to specifications (and relevant/interesting discussions about them)
2. links to the source code (e.g. lxr URLs)
2a. links to source code history (e.g. bonsai links, recent checkins)
2. links to documentation
3. links to examples and testcases
4. links to bugs (separate links for open issues and others)
   (if "features" are "bugs", then this could use the dependency mechanism)
5. pointers to contacts (the assignee and QA contact of the "feature" bug are
    a start, but maybe this would be a good place for a centralized overview of 
    all people involved: authors & contributors for specs, code,
documentation,      testcase, ... Or perhaps it is better to have this info
decentralized only?)
6. pointers to related newgroups, newsgroup articles, other information on the
   web, ...

Basically, most of these "lists of pointers" are a generalization of the
existing "URL" field ("bug_file_loc" in the DB) for multiple values (URLs),
but each field contains only pointers to a certain type of targets (specs,
source, docs, ...)

So, a general solution for this would be to implement an additional database
table with the following columns:
- bug_id         (not unique, since multiple entries are allowed per bug)
- url_targettype (conceptually an enum)
- url            (short text)
This could be generalized for other things than urls (e.g. use "info" instead of
"url"); in this case, there should be information for each type whether the
information is a clickable link or not, or maybe even how to transform that
information into a clickable link.

Sometimes, there will be very fine grained features. In this case, it would be
overkill to all this information for each single features. So there should be
support for inheriting missing information from parent features somehow.

Comment 2

[Andreas Franke (gone)]

Bugzilla currently has three orthogonal mechanisms that could be used as a basis
for an additional "feature" tree/DAG, but each of them has severe shortcomings:

A.) components. Currently components are flat in bugzilla. See bug 43940 for the
plan to turn this into a component tree, or even DAG.

B.) keywords. Having a keyword for each "feature" would be a solution for the
relationships between ordinary bugs and features. Unfortunately, the current
keyword system doesn't scale well enough to handle this. At least two things
would be needed for this to work: 
1. a keyword hierarchy, and
2. an automatic bug_ids-as-keywords mechanism for bug_ids of "feature" bugs.
For some ideas about improving the keyword system see my 2001-01-20 06:12
comments in bug 65965.
 
C.) tracking bugs. This is actually the closest approximation of for "feature"
bugs, and this approach is already used in several places, e.g. imagelib 
(search for "ALL @pavlov meta" on bugzilla.mozilla.org's QuickSearch text box,
or see http://bugzilla.mozilla.org/showdependencytree.cgi?id=66967)
The formal difference between tracking bugs and ordinary bugs is that tracking
bugs have the "meta" keyword. Dependency links are used for both types of edges:
feature hierarchy edges and association of ordinary bugs with a particular
feature.
However, references to other resources are not formally tracked yet, and
navigation in the dependency tree not well supported (e.g. there is no way yet
to cut the dependency tree at a certain depth, or to exclude non-meta bugs from
the view, etc. etc. ...)
If tracking bugs are used as a basis for FeatureZilla, then support for
dependencies must be polished a lot, and the "meta" keyword should be turned
into a special binary property of each bug. Also, query results should be
reported separately for "feature"/"meta" bugs and ordinary bugs, and the bug
view should to become different for the category of "feature" bugs to include
"feature"-specific fields. But this is just the tip of the iceberg...

Comment 3

[Andreas Franke (gone)]

So what would be the benefits of better support for "feature-oriented"
development for mozilla.org?

I. One simple, but important reason: If you are a volunteer contributor, there
is a not much difference between having "fixed one bug in mozilla" and having
"fixed two bugs in mozilla". But things are completely different thing when you
can identify yourself with a feature, with some well-defined functionality. You
will be much more motivated to keep "your" feature working, and bug-free.
(And here is the important point: You will not only fix the worst bugs, or the
set of bugs some PDT thinks needs fixing for the next release, no, as a
``feature owner'' you will care that your feature is sufficiently polished,
working correctly, never crashing, and hopefully even performing well enough.

Open source seems to be based on this kind of rewards, to a large extent: small
units with well-defined interfaces, that can be re-implemented in a naive way in
at most a week or two, maintained by individuals who are recognized for
providing a good, small piece of software. Some of Mozilla's interfaces are
already frozen for embedding, ane more will follow, so IMO now is a good time to
try to wake up some sleeping power.

II. Doing this now will help improve the quality of the mozilla 1.0 release: 
If a prototype for an integrated "feature" layer was implemented soon, it may be
possible to fill the structure with Mozilla's real features by 0.9.1 and
associate most of the existing open bugs with one or more of these features.
Then, all these features can be independently checked if they "ready for 1.0".
This would shift the perspective from a negative view ("Mozilla is completely
buggy, and the number of bugs is increasing every day") to a positive view
("There are already some features working well, even well enough for mozilla
1.0, and more features are getting there one by one, step by step.")
I expect this to be a great benefit to the mozilla 1.0 release process.

In addition, it would make reduce the chaos in bugzilla.mozilla.org a bit, make
bug finding easier (before you file a bug, you must locate at least one feature
it is belonging to, and by looking at that feature's existing bugs (which will
be few enough that you can scan all their summaries) many duplicates can be
avoided because people see that the bug already exists. Less duplicates filed
means less time spent by QA on hunting duplicates, which in turn means more time
can be spent on systematically testing and improving mozilla itself, thus
helping increase overall quality.

For these reasons, I'm nominating this bug for mozilla0.9. If you think Bugzilla
bugs shouldn't be nominated for Mozilla milestones, then you may reassign this
bug to the mozilla.org product, but please do not remove the nomination. Thanks.

Comment 4

[in9mar]

My company is about to throw out Track Record as our bug+feature tracking 
system.  Bugzilla has most of the functionality we are looking for.
The main thing missing is a propper distinction between features and bugs.
Andreas feature request (bug 75172) would bring this distiction.
I agree with all his reasons for having feature tracking.

Some further consideration is that it is often much easier to decide whether to
include a feature in a release or not, than it is to decide about the 
improtance of bug fixes.

Right now bugzilla treats features and bugs equal. Making features a higher 
class citizen than bugs, bugs can be organized by their dependence on features 
which makes large projects easier manageable. 

Comment 5

[Andreas Franke (gone)]

-> Bugzilla product, General component, reassigning.

Comment 6

[Andreas Franke (gone)]

> I agree with the concern of altering a "long comment" field (comment 5) since
> it is frustrating when "my" well-thought summary line gets changed.

Well, you always have the history, and hopefully people will be reasonable
enough to not overwrite your words just for the sake of it. :-)

Comment 7

[Andreas Franke (gone)]

Sorry, the last comment was meant for bug 136310.

Comment 8

[Dave Miller [:justdave]]

Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them. (sorry for
the spam if you got this twice, it didn't take right the first time)

Comment 9

[Basim Baassiri]

I would agree with comment #4 that bugzilla should include features as higher 
priority than bugs. In my company we are finding out late in the software 
development cycle that features are missed or incomplete and thus we assign a 
bug to them. This differs from a bug which might be defined as a defect in 
software. An incomplete or missing feature isn't truly a bug since it is not 
yet created in the software and therefore should be categorized as a bug.

I agree that features tracking should be considered as a tool and perhaps 
tightly integrated with bugzilla. By doing this, for example incomplete 
features can be tracked and bugs can be assigned to them thus creating a 
collection of associated problems. Once all of the problems have been complete 
they can be considered for release.

I would like to vote on this bug and perhaps even help on developping this 
feature

Comment 10

[Bill Barry]

With the right implementation features could replace milestones and most meta bugs. It also sounds like the right way to go to get to better project management reports (gantt charts and the like).

Comment 11

[Max Kanat-Alexander]

The only remaining real feature proposed in this bug that's still lacking is bug 9412. Otherwise everything here can be accomplished with URL Attachments, custom fields, and the like.