Bugzilla is the issue tracker that we use for most of our feature development, not just for handling bug reports.
Reporting a bug
Go there. While entering the summary, a list of possible duplicates appears. Check these to avoid entering duplicates -- you can add yourself to the corresponding cc-list, add a new comment or edit the fields. Try to select the right component, or set it to 'General' if you don't know. Use the 'severity' field to indicate the kind of problem. If you are unsure use 'Unknown', or ask in IRC or the mailing list for other values. This has been added recently (2014-06-10), so many old bugs still have 'Unknown' severity.
Developing a new feature
You should file a new 'bug' for each feature that you're developing. Henceforth it's important to note that in bugzilla terminology, a 'bug' is not necessarily a bug in the usual sense, it is just any issue under tracking.
You can split big features into smaller bugs, but then it's a good idea to file a meta-bug about the feature and mark it as 'depending' on the smaller bugs.
If your feature should make it into a specific Eigen release, add to the 'Blocks' field the tracking bug for that release. You don't need to know the tracking bug id, as tracking bugs have the version number as alias, e.g. the tracking bug for the 3.0 release has 3.0 as alias
Tracking the development of future Eigen versions
Each planned future Eigen version should be represented by its own 'tracking bug', for example Eigen 3.0 is bug 25.
Tracking bugs have the corresponding version number as alias, so you don't need to remember their ids.
Features wanted in a given release are the bugs blocking the tracking bug.
If you're taking care of a bug, mark it as 'assigned' to you. By default, bugs are assigned to the dummy 'Nobody' user, which means that they need someone to take care of them.
Attaching a patch
When you attach a patch to a bug, make sure to tick the 'patch' checkbox.
Asking for review
Asking for review serves two main purposes. First of all, unless you are a very experienced Eigen developer, we ask that you get your patches reviewed before you can push them. Second, asking for review means that the requestee gets notified about your patch and can't forget it.
In order to ask for review, when you attach a patch, or later on in the 'Details' page of the patch, at 'review', select the question mark '?' and select the person who should review your patch.
If you don't know whom to ask, you could look at Mercurial history for the files you're touching (hg log or hg annotate), but make sure to choose someone who's made lots of commits to Eigen already.
Reviewing a patch
By clicking on 'Details' for the patch, you can see on one page the raw patch, a text area to type your comment, and the review status controls. Don't hesitate to copy and paste lines from the patch into your reply. You can then replace the review '?' by a '+' to accept the patch, or '-' to reject it.
Updating a patch
If you're uploading a new version of a patch, please mark the previous version as 'obsolete'. This will cancel existing review requests and hide it by default.
If a review was pending for this patch, you need to review again.
If the patch had already been reviewed, and your changes are trivial (you only fixed a typo), you may review your own patch (select review '+') and add a comment saying 'Carrying forward r+ ...'.
Linking to other bugs
If you say 'bug 36' in a comment, bugzilla creates a link. You can link to a specific comment by saying 'bug 36 comment 12'.
The lines 'Blocks' and 'Depends on' are where you can enter the ids of other bugs to create dependency relations. Note that if A blocks B, automatically B depends on A, and conversely.
Notice that certain important bugs have aliases so you don't need to remember their bug ids. In particular see the section about tracking bugs. For example, to mark a bug as blocking the 3.0 release, just enter 3.0.
Notice that for each bug you can view its dependency tree and graph.
Another kind of relation is that of being a duplicate. When you change the status of a bug, under RESOLVED, the entry DUPLICATE prompts you to enter the id of the other bug of which the current bug is a duplicate. If you hesitate between making X be a duplicate of Y or conversely, the rule of thumb is: make the bug with the most interesting content (patches...) be the one that remains open.
Email notification works by "watching" other users. Just by watching the 'Nobody' user, which is the default assignee for new bugs, you'll get notified of almost all new bugs.