Symphony.

Well... I didn't want every aspect of the site to be manageable on the frontend. Instead, all rarely-edited items should only be editable by the site owner: Projects, Categories and Statuses.

Milestones and Users on the other hand should be editable by "regular frontend admins".

Does that make sense?

I guess the tricky one will be Users: Adding them should send an email and stuff like password recovery should be available.

Ah, I see. That makes sense.

As for adding users, the Forum ensemble has some forms and events that are used to manage self registration and includes processes for password recovery. The access control layer could be adapted to allow registration only by admin users.

I know i'll be asking a bit too much - but this 'bug tracker' doesn't have anything to link-to/work with a something like a Source Control System? like Subversion or Git for example?

Currently looking at finding a decent system that we can use for a small team to track Issues/Bugs/Requests along with some version control software as we're not so synchronized. When we were 2 it was fairly easy to manage but since we're more and expecting to add more players to the team; its getting a bit complicated to know who updated what etc etc... so we really need to get a workflow sorted - any feedback with the use of this tracking system would be much appreciated :)

If you want source control management, look no further than Github. Pay up $12 a month and you'll get private repos and private teams. It's Github, but private. So you get a repos, issue trackers and repos... and no additional user accounts to remember. But if you want your clients to log issues, I recommend Codebase, which offers repo hosting as well as issues.

BitBucket does private repos and issues for free, with up to four or five users having access iirc, and their pricing is better on the value concerning number of repositories (unlimited) and users. Its UI doesn't seem as polished as GitHub, though.

I probably wouldn't recommend it for client issue reporting.

I've been using bitbucket for a few private repos to test it out and mixing github and bitbucket for projects has caused some issues!

If the last submodule is from bitbucket, it would not allow the next submodule from github to be added to the .submodules and no submodule is pulled in.

It's good for isolated projects where private small repos are used and not crossing of services is done all seems fine. Just so you know.

I don't need external issue reporting; only the developers (mainly lead dev) who will be putting issues in.

In regards to Github vs BitBucket any major difference except pricing? We'll only need something like 5-7 repos for now at least.

Another quick question - I'm pretty sure that its 'safe' to use github but not sure I'd get full approval to host our code elsewhere - you know confidentiality and stuff. Would there be a decent alternative that is self-hosted?

Would there be a decent alternative that is self-hosted?

Yes, and it's pretty simple, too.

Yes, and it's pretty simple, too.

but I don't think that git on its own includes issue tracking right? We would need something like maybe 'trac' to keep track of issues & deadlines? (A white-board / spreadsheet doesn't cut it any more unfortunately)

Github offers a self hosted enterprise version too.

No, it doesn't.

Back in the day when I was looking for a solution I expected it to have such a SCM-to-Bugtracking-bridge as well. But truth is, I didn't end up using it. At all.

I mean what do they offer? You can have a list of commits mentioning an issue, sometimes you may close issues from commits.

Thing is though I never really remember the issue-number I am currently working on. So in order to put the number in the commit message I have to look it up in the bugtracker anyways. So what's the point when I still have to go to the bugtracker myself? Also, as soon as one single commit doesn't fix the problem, that list of "mentioning commits" becomes quite messy as well. Instead I'd use a separate branch and mention it - manually - in the bugtracker.

Also, I don't really trust opening/closing issues from Git. So if this feature still requires me to check if the issue has been closed after all I rather make sure it's been properly discussed and close it in the Bugtracker itself.

So, in essence: You need a Git repository and a bugtracker. A Web-based changelog for your repositories is a nice-to-have but a SCM-Bugtracker-bridge is not too useful.

The nice thing about those hosted solutions is that you have everything in one single interface. A self-hosted solution is a bit messier in that regard.