Maybe to set scope/expectations, we should specify which upstream trackers should be supported. In my humble opinion, github and gitlab would be a great start, we can add more if need arises.

And to mention some complications that come to my mind with this change, without more deep thinking about it:

• We need to pay more attention to the database - as it currently stands, we can drop the bba db and reconstruct it from bugzilla/pagure without too much trouble, it won't be possible once this is implemented
• We'll need to hold mappings from upstream component (name, url) to Fedora component (naming might be different)

Also, there are possible complications with our Fedora processes. Users don't necessarily have to use the bba app for blockers tracking (they can follow bug dependencies on bz). Shall bba in such cases automatically create a blocker placeholder bug?

We need to pay more attention to the database - as it currently stands, we can drop the bba db and reconstruct it from bugzilla/pagure without too much trouble, it won't be possible once this is implemented

No, I specifically wrote "It would create a bug report in RH Bugzilla" to avoid this problem. The whole process would stay as is, just the manual opening of a placeholder RH Bugzilla report would be automated.

We'll need to hold mappings from upstream component (name, url) to Fedora component (naming might be different)

Two options come to mind. First, ask for the component name (you'll need to ask about the URL anyway, so you can also ask about the component), or second, create everything in distribution or a similar component. Since those bugs would be for tracking purposes only, it doesn't really matter. I'd definitely want to avoid maintaining tracker<->tracker component mappings.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/blockerbugs/issues/267

Please continue any further discussion there.