BitBucket vs Github issue tracker choice for Jajuk

We are currently moving our Jajuk Trac issue tracker to a better place, mainly for spam reasons. A developer suggested BitBucket, others (me included) GitHub which I already use. I cloned our secondary project QDWizard on a private BitBucket repository to make an opinion. I have to say BitBucker is really good too.

According to me, both systems deliver the most important features :

• Simple to import from Trac.
• Export facilities to make change possible in the future.
• Clean and simple GUI.
• Clean roadmap/version support.
• Assignation facilities.

But:

• Github has much more users (around 4M compared to 1M for BitBucket). More developers already have accounts and are used to it.
• GitHub GUI is a bit faster.
• GitHub is more "open source" minded, I feel BitBucket more enterprise oriented (private repositories).
• BitBucket is free only until 5 developers.

Specifically about issues management : the issue manager in Bitbucket is not actually Jira but a lightweight tracker. It doesn't come (hopefully) with the full workflow support. Like most tracker, each ticket has a type (a "kind" : bug, enhancement, proposal, task) , a priority (trivial,..., blocker) and a status ("workflow" : "on hold", "resolved", "duplicate", "invalid", "wontfix" and "closed"). Note that these states can't be changed nor augmented (many users asked for adding "tested" but it has never been added). It's like Trac without the possibility to customize new types and new status. Some Jajuk Trac types are not supported : "known issue", "Limitation", "patch", "support request", "to_be_reproduced" (and we map our "discussion" to BitBucket "Proposal"). Some status are missing too : "worksforme", "not_enough_information". I suppose a migration would have force us to map several status and several types to the same Bitbucket kind/workflow.

From its side, Github comes with (according to me) a very elegant solution : there are no tickets priorities, types or states but only "labels" like : "important", "bug", "wont fix" , <whatever>... OK, it may be more laxist but on the other side :

 - it allows to add any labels to qualify a ticket against any aspect you may think about ;
-  it doesn't force to use potentially useless fields like priority. 

I suppose the migration scripts will be able to simply create any new labels to reflect our existing status and status (yet to be proven). We still have to run the migration script, I'll test this probably this week end.