Choosing from the 30 or so components is too much of a burden on people trying
to reports issues.  IMHO if we want people do report problems we should make
this process as easy, consistent and understandable as possible.  As I
previously said in the recently fixed issue 9299, I doubt that the highly
complex differentiation of components serves its purpose (see my comment in
issue 42229) and I am equally sure that quite a number of people that want to
contribute by filing an issue stop half-way through because of the overly
complex process.

Taking a look at the current components I think it might be possible to
aggregate them as follows (* denotes group heading which are not
links/components themselves)

Testproduct

* Main Software components
Chart:
Presentation:
Spreadsheet:
Word processor:

* Secondary Software components
Database access: (merge with bibliography component)
Drawing:
Formula editor:
groupware

* Other
OOo Int'l   -> put ALL those languages in here and let reporters choose in
               in a second step.  Furthermore l10n, native-lang
Source Code: merge api, framework (?), framework, porting, sdk, tools, utilities
Distr & Install: merge Installation, marketing and distribution, kde

lingucomponent could either go to OOo Int'l or secondary SW components

And that still leaves too many, some of which I cannot make either head or tails
of even after reading their description.

bizdev
council
documentation: merge with user-faq
gsl:
incubator: 
oopm: 	
qa  -> do we really need a separate issue component for this?
specs: 	
stats: 	
ucb: 	
udk: 	
ui: 	
website:
wp: 	-> does such a minor component need its own component?  Why is there is not
a separate one for the MS word filter which surely must be more important?
www:
xml:

www and website definitely need to merged, maybe with other components to join them.

Above idea is by no means perfect and should only be taken as a first shot at
it.  But I strongly feel the current situation is overly complex and that
something has to be done about it.