Web development project management software
It makes no difference whether you know Python or not to use Trac just like it makes no difference whether you know PHP or not to use Wikipedia.
The biggest gap of Trac's implementation is one that only a project participant on multiple projects would see, namely that each project must be in a separate Trac instance. That means you would have no unified view of all issues from all projects. For us, that hasn't been a show-stopper.
We have modified Trac's workflow to model our actual workflow. Our clients get accounts on Trac and we use the ticketing system as a "ball in court" system where we bounce issues back and forth between our team and the client's team until we arrive at resolution.
For example, a client might open a ticket that describes some feature request. Invariably, the client will be looking for an estimate of effort on that feature. By default, all new tickets are assigned to the PM. The PM gets notified by email with a summary of the ticket, logs into Trac, and accepts the ticket. Optionally, he might accept the ticket and assign the ticket. The assigned party might not have information in the ticket to provide an estimate of effort. There might be other critical pieces of information missing so that person will ask questions of the client, set the ticket to "need_info" state and sets the owner of the ticket to the client.
At every state change, Trac will notify the reporter, the owner, and by default, the PM so everyone who needs to know is kept informed. Additionally, we have the option of cc:ing others on the ticket, which we sometimes do as necessary.
The client answers the questions, sets the ticket to "info_provided" state and sets the owner back to the party who had bounced it over them. Assuming we don't have to do another round of Q&A, the owner will comment on the ticket and estimate the effort, set the ticket to "needs_approval" and set the owner to the client.
If the client has enough information to make a decision and they want us to implement this new feature, they set the ticket to "approved" and bounce it back to us. If they don't want to proceed, they can close the ticket.
If we're ready to start working on that ticket, the team member who will be implementing the feature will set the ticket to "work_in_progress". That gives the client an indication that this issue didn't just disappear into a black hole.
When the developer has finished, he'll set the ticket to "ready_for_qa" and set the owner to someone on our QA team. The QA person can either bounce it back to the developer as "needs_work" with comments or bounce it over to the client as "ready_for_user_acceptance". Again, the client can bounce it back as "needs_work" and explain why or they can accept by closing the ticket.