It took me a while to figure out how this works - even to the point where this issue was originally a report of a bug because I misinterpreted why groups I expected to see in the list were absent.

I now realize that the criteria is groups I created (obvious) and groups created by others that I'm a member of (somewhat less obvious).

I think the one that is missing is 'groups I'm not a member of that were created by those who are in groups with me'. I would not call the absence of these groups a bug (I'd change this issue type if I could figure out how).

A potential enhancement that could support the missing piece I describe above:

I create a group on my account.

By default, the group is not available for others to use and is not inheritable on forks.

I, as group owner, have the option to make the group 'inheritable' for forks of repos on which it is used (turning off inheritability would not retroactively affect existing forks).

I, as group owner, have the option to 'share' the group, which would make it available to anyone I'm in any group with (even if they aren't in this particular group).

Clearly this would mean a lot more groups to choose from, so we might need some pollution controls - a user can remove groups shared with them from their view (and perhaps have a way to view those they've toggled off, in case they'd like to toggle them back on).

See BCLOUD-3807 for a related, but distinct bug related to groups.

The only groups documentation I can find does not discuss any of this functionality, so a lot of the above is based on assumptions for how you intended things to work.

http://confluence.atlassian.com/display/BITBUCKET/Managing+the+user+groups+for+your+Repositories;jsessionid=18AB3DAA8C4DF9B22B5D99C856DB7484