Bradley D. Thornton wrote:

1.) Regarding the Private issues, to me what this implies is rather important, although my understanding might be completely wrong. Does this mean that say, if there is a team of five people working on a project, and I assign todos, tasks, or tickets etc., to only one member of the team where such assignments or whatever have sensitive info that shouldn't be privy to the rest of the junior team members, that I can't make those items private?

The current ChiliProject model of authorization is mainly dictated by roles in a project having access to actions of types of objects, which means all people with the same role (or to be precise with the same permission through those roles) have the same access to all objects of that type in the plugin.

In this particular case: no, you won't be able to have different "read access" (permission) levels to issues (type) in a project, if a user has the right to read issues in a project he will have the right to read all issues.

Regarding the private issues in Redmine (take this with a grain of salt as I've never actively used them), if I understand them correctly they allow you to define one level of access to issues (user with access to private issues and users that don't have access to private issues), where this line is drawn (logged in vs. anonymous users, members of the project vs. non-members, managers vs. other users of the project, …) depends on your config.

As to the inclusion of a similar feature in ChiliProject: it completely sidesteps the current permission concept and thus introduces a load of side-cases to take care of, as far as I know they took some time to stabilize in Redmine, and we decided to not add something similar with the current permission system.

2.) Multiple repositories per project: I don't really know what that means either. Does this mean that ChiliProject won't support our own git repo and also github at the same time or something, and if so, considering that ChiliProject was forked from redmine, it must have been a conscious decision not to do so, and if so, why? How is that better?

The multiple repositories per project feature has been added to Redmine after the fork (as has the private issues feature), so it's not something we've removed. Currently ChiliProject supports exactly 0 or 1 repository per project, but you can have as many repositories as you like in your whole ChiliProject. The origin of the repos is also irrelevant (though git repos need to be cloned locally) too.

3.) Visual Merging Branching History: Does this mean that we won't have a web-like view of the git repo's revision history? If I'm wrong, then please explain how this matters and why I/someone might care.

ChiliProject doesn't have a "visual" view of a repository's history. That's a hard problem to get right and not something we think is an essential part of what makes the core of ChiliProject, there's enough other tools for that (gitk, gitx, git log, github if you like…).

Forgive me if those are stupid questions, but I've been waiting a while for version 3.x to be released and now that it is I would like to move from trac to redmine or ChiliProject with both feet. I really don't want to choose one and then manually migrate to the other, and ChiliProject does indeed seem to me to be the logical choice moving forward :)

Not stupid questions at all :-) Most of them boil down to the current broader goal of the project: the focus in Redmine still seems to me to be to get features in (when something gets done) as fast as possible and with minimal work, our goal is to get rid of technical debt and consolidate the core before moving on (though we're a little stalled do to university, a master's thesis and some family issues).

I hope I was able to answer your questions, feel free to ask more if not :-)