The OP has left out several key information which will enable us to give the most appropriate answer.
- What revision control, if any, is used to track the code changes in those website (assuming they are actually coded). In my experience, coming out of the scientific lab with 85 people and multiple small to medium projects used by various government agencies, a bug tracker without code tagging is pretty useless. Bug tracking system has to be integrated with the version control system to be seriously useful.
- Who will be submitting the bug reports, internal only or external people as well? If the external users have ability to submit a bug report what is their general computer lever? Again in my experience computer savvy users are outliers and mediocrity is the norm. I would generally expect "bug reports" to consist of useless rants and occasional screenshots uploads which might or might not be useful.
- How robust bug tracking system should be in the terms of management, code assignment, code review and similar?
- Number of developers and users.
- Left for possible few more things to be added..
Above being said without knowing anything but the size of the team I would go with
devel/fossil which is an excellent distributed version control system which comes with built in web browser for tracking projects, bug reporting system, and wiki. It enforces a proper workflow and pushed you for adoption of proper developing habits. It is written by Dr. Richard Hipp the same guy who created
databases/sqlite. Actually it uses sqlite as a backend which enable simple backup and migration strategies. The package consists of the single pre-comptiled binary and the whole infrastructure can be set in less than a minute on any platform/OS. The only draw back if the lack of GUI clients for developers which should be non-issue for serious teams. Do we use it in my lab? Now we don't so please keep reading.
Historically (my lab is over 23 year old) we used two version control systems. CVS originally and circa 2008 we ended up using also Subversion due to the ill fated effort to migrate from CVS to Subversion. That created multiple problems. We had to use
devel/viewvc for web access to code (the only one which had a good support for both CVS and Subversion). We used to bug tracking systems,
devel/bugzilla and
databases/mantis which both turn to be useless as they were never properly integrated with neither of of version control system we used. If you need more about them I will be happy to add things to this post.
About a year and a half ago we started ambitious plan to create a proper development infrastructure. We chose to migrate to Git primarily due to the obvious social coding benefits (GitHub) familiar to our faculty, post-docs, research programmers, and Ph.D. student. We evaluated two self-hosted front ends for Git with built in bug tracking system
www/gitlab and
Gogs which is not in ports but its fork
www/gitea is (Gogs is turning to be a quite turbulent project from the political point of view).
Gogs was clear winner and this is a little howto to run in FreeBSD jail
http://www.cs.cmu.edu/afs/cs/user/predragp/www/git.html
Both systems had everything we needed including built-in bug tracking system with version control integration, web interface, and much much more. However GitLab a Ruby project turns out to be a night mare to install, manage, and very heavy on resources. Gogs was the things for us. We are currently evaluating/monitoring political stand off between Gogs and Gitea but have not make a discussion to switch to it.
