Ideally, content (which could be proposals, notes, software configuration requirements, etc) and issues should be managed by the same system - or at the very least be close to each other. And projects need to be easy to add in to the system by either main user, from wherever they may be. And most of all - it should offer only just-enough project content management features.
We gave the Roundup (0.4.2) issue tracker a try. While fast, it was still a young product. Too much command line work was involved to set up a Roundup instance, and while there is a Zope-Roundup Gateway available, it didn't integrate too well with Zope based content. I really like Roundup and think it has a lot of potential, but it didn't satisfy our requirements.
Ultimately, we landed in the ZWiki 0.7 + Tracker situation. Each project was their own folder or wiki, and usually had a tracker in it. This approach succeeded on the simplicity category and has been used for almost half a year. But it suffers from a couple of problems. The first is that Tracker is an aging old beast. It's generally pretty thorough, but has some rough edges. It's no longer supported, and I've heard claims that it doesn't work with the latest "Zope" release family (2.6.x).
The second problem is that I'm no big fan of Wiki's. I never have been. They've been useful, but we don't need whatever supposed collaborative effects Wikis are supposed to have. I don't like Wiki names - they either end up looking funny (with words like OneDotOh or ZoPe) or kick in when you don't want them to. Now that I've done some work with reStructuredText, I've come to loath working with Zope's normal StructuredText. It just doesn't work well with TextAreas. If you're used to Zope's StructuredText and have a good editor on your side, it's not too bad. But StructuredText and DTML (outside of SQL methods and occasional small non-HTML uses) are two Zope technologies I'm happy to leave to the past. Finally, we needed a stronger content management system than a pool of individual wiki's provided.
We did (briefly) try out ZWiki 0.12 with setting up the ZWiki based Issue Tracker, but it was a beast to set up and configure (loosing out on the 'easy-to-add-new-project' requirement) and too dependant on DTML for me to debug and make work for us on short notice. I liked the integration of Issue Tracking with the Wiki (gaining points on the keeping-issues-close-to-content) but there was too much pain involved, and too much inolvement with the technologies I wanted to leave behind.
And I know Wiki's really really work well for some, but I've never really been able to get comfortable with the Wiki way (ask anyone that I used to work with). I've been able to get by, but that's about it.
CMFCollector is decent. It has some of its own rough edges, and is missing out on some of the nicer features of Tracker (mainly intra-issue explicit linking). But it has some nice new features, like the ability to automatically assign/accept a new issue. Its interface is a bit more streamlined, particularly in the Plone skin. It uses a very simple plain text markup language it calls WebText. It basically takes plain text, marks up URL's and citations/literal blocks (lines beginning with '>' or white space).
A downside to Plone is that it - for better or worse - just builds upon CMFDefault. And CMFDefault has very basic content objects, particularly the default Document, which is very monolithic. I partly blame myself for the design - I could have proposed a better solution back when I was on the team. In my vaporware compound document project, FDoc, not only are the parts of a document componentized, but so are the text handlers. A separate Handler Registry contains handler objects, which take a chunk of text and turn it into an HTML content body. This could be HTML (taking the content between the BODY tags), Structured Text, Plain Text, etc.
So today, wanting reStructuredText support, I tried to think of how to deal with this. I had a couple of options: either take the existing FDoc work, which is half baked (the most complete work is in a customer specific project and hasn't been backported yet due to time constraints) and add a reStructuredText handler (and also make a Plone friendly user interface), or make a subclass of CMFDefault's Document class, add in the ability to manage reStructuredText somehow and make it a new Content Type or replace the Document document type (this too would involve some Plone UI work, but it would only be a tweak of the Document's edit form).
Neither situation was quite what I wanted - there were too many existing dependencies on the default CMF Document behavior, and I haven't had the time to really learn how to make my own Plone UI pages work. So, I decided to do a hybrid of my original ideas. I made some new FDoc handlers that handled Zope's StructuredText and the reStructuredText formats. Then I made a subclass of the CMFDefault Document and started wiring in knowledge of the handlers and handler registry (based on the FDoc Text Part component, but made to match the default Document's interface). Then, out of some act of devilry, I decided to monkey-patch document by doing some good old fashioned Pythonic class __dict__ comparisons and substitutions. After a few tweaks to the document edit form to list the available text formats dynamically instead of statically, I had it working (aside from one infinite recursion bug my __dict__ tweaking introduced).
So now, it's mostly working. We have a decent looking project site that's navigation friendly. It's easy to add new content and to decide its form and format with very little restriction. And I'm finally away from StructuredText (although it still exists as an option). With other CMF and Plone options available from the likes of the CMF Collective, there's a lot of potential expansion if required.