If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all.
In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked.
It's possible that there might be some reason, valid or not, that developers shouldn't be entering bugs. One possible reason might be that the bug tracking system is visible to outsiders, and having too many reported bugs looks bad. That's a very bad reason, which should be addressed in some other way that still allows bugs to be tracked. Ask your boss.
(Of course if there's a bug in code that you're still working on, and it doesn't show up in anything that's been released, there's no need to track it in the system, though a TODO comment in the source code may be a good idea. To take an extreme case, "This code won't compile because I haven't yet typed the semicolon at the end of this line" is not a reportable bug.)
As for why other developers don't enter bugs, you'll need to ask them. They probably should.
I'm writing this from the perspective of Redmine. I haven't used Trac and only massaged the source with my eyes (not even reading it). At a high level, it appears to be similar to Redmine so many of the things that I say may apply to it too.
The first question that you need to look at is the integration between the bug tracking (and code change) side and the "customer facing" issue tracking. Different places may allow for a degree of openness that is not available in others.
- A closed-source software product certainly won't let the code changes get anywhere near the customer facing bug tracking system. The risk of having some code getting out is a worry for many of them.
- An open-source software product will often host the source code and bug tracking right alongside the customer issue tracking (they are one and the same). This can be seen in both Redmine and Trac.
- An academic setting... well, its probably somewhere in between.
That last point is key - is it a problem if the source gets out? Or for that matter, is it a problem if people see the discussion between developers of the product in the notes of an issue?
Redmine has the ability to restrict which certain users can read. You may have individual notes marked private or things such as "only people with the programmer role can see the repository."
If this is acceptable, the easiest thing is to integrate the end user issue tracking and bug tracking in the same system. You will likely want to separate "bugs" and "issues" from each other, though note that there is a relationship between them. An end user issue may be caused by a bug, or it may be something the end user doesn't understand.
Issues and bugs have different work flows - issues may go through something like "new -> confirmed -> waiting for fix -> resolved" while a bug may go through "new -> assigned -> working -> code review -> working -> code review -> deployed -> closed" or something like that. There are likely as many work flows as there are installations. Having a "blocked by" relationship from the issue to the bug allows you to easily relate the two systems together.
All of that was assuming that it was acceptable to have one system host both, you will then find yourself with two different systems - one that is customer facing, one that is developer facing. This may involve a bit more work - somehow, someone needs to bridge the gap between the two - developers need to be aware of bugs that are discovered by the end user in their bug tracking system.
I haven't found a modern bug tracking system that plays nicely with others. Everything tries to be self contained and when commercial products have bug tracking systems, they make it so that it's easy to migrate to it and use everything within its own product line. You may find an API that lets you do some things, but for the most part - nope.
The question here becomes what is the workload and how does one want to integrate the two (picture two spoiled children sitting with their backs to each other not wanting to play)? Is it enough just to have a link from one system to the other? Is the amount of new issues low enough that this can be done by hand? or will you need to start exploring some way to poll from one and update the other?
Make sure that when integrating the two systems that you use the API rather than trying to go behind its back and tinker with the database with updates directly. There are dangers to that - the table structure of modern bug trackers is a big large and they are managed in the application. Going behind the back of the application may cause issues with data integrity. As mentioned before, instead of updating and inserting at the database, use the public API for the application (Redmine's API for issues for example).
The extent of the business logic and the integration points are something that needs to be examined before jumping off and doing it. Which way does the data flow (both ways gets very interesting at times) and what data flows. Are you copying issues into bugs once they reach a certain state? How do you keep track to make sure you don't create the same issue again and again (need to update the data model of the bug tracking system)? What happens when an issue is marked as closed in a bug tracking system - does that flow back?
All in all, its probably simplest to try to use the same system and manage the permissions / customize it so that it works the way you want it to if it is not critically bad if some bit of knowledge from the developers leaks out.
Best Answer
Assuming that one can move bugs to their own item (not sub features), the way to relate bugs and features is to relate them to each other. This will fix the target version being populated correctly and allow you to use the roadmap with its intended functionality.
The next consideration is "are features actually things to do? or are they general areas of the site?"
If you look at how Redmine organizes itself you will see "Category" being used. These are what I believe your 'features' really are. This becomes even easier to work with - you set up the categories in your project and the category becomes a drop down on the issues page. The roadmap can then show what categories are going out in the next target version very cleanly. Reports can easily be generated against categories.
The system component I believe would be best served with a custom field that allows a list (possibly the multiple, though you might also consider separate sub-tasks under an issue with one for each task - "modify database" and "modify back-end" for a single bug could be assigned to different people).
If in doubt, Redmine issue tracking for itself is likely the best example of how to organize Redmine.