1496893 - Figure out how to make GitHub-hosted products discoverable

Status: NEW

(bugzilla.mozilla.org :: General, enhancement)

Description

[Kohei Yoshino [:kohei]]

I’d like to think about ways to make GitHub-hosted major Mozilla products discoverable on BMO. This includes Firefox Focus [1], AMO [2], Common Voice [3] and more. Ideally, when the user tries to find these products [4] or file a bug against these products [5], the page will provide a link to the relevant GitHub issue tracker. The current “not found” situation confuses those who want to contribute.

[1] https://github.com/mozilla-mobile/focus-android/issues
[2] https://github.com/mozilla/addons-server/issues
[3] https://github.com/mozilla/voice-web/issues
[4] https://bugzilla.mozilla.org/describecomponents.cgi
[5] https://bugzilla.mozilla.org/enter_bug.cgi

Comment 1

[Kohei Yoshino [:kohei]]

See also: https://wiki.mozilla.org/GitHub#Is_.22mozilla.22_the_only_github_.22organization.22_related_to_Mozilla.3F

The redeveloped ProdCompSearch extension should combine the results.

Comment 2

[Kohei Yoshino [:kohei]]

Noticed that Custom Bug Entry Forms has obscure links to AMO and now-deprecated Persona Plus repositories:

https://bugzilla.mozilla.org/page.cgi?id=custom_forms.html

Comment 4

[Kohei Yoshino [:kohei]]

Possible implementation/UX:

• Add the external_link field to the products table, and expose it on the Edit Product page
• Let admins edit externally hosted products like regular products instead of hardcoding them in a file
• Show these products on Browse and New Bug pages, and link them to GitHub
• Hide these products from search and report pages

Comment 5

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

David, what would work best for the Fenix team?

Comment 6

[David Lawrence [:dkl]]

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #4)

Possible implementation/UX:

• Add the external_link field to the products table, and expose it on the Edit Product page
• Let admins edit externally hosted products like regular products instead of hardcoding them in a file
• Show these products on Browse and New Bug pages, and link them to GitHub
• Hide these products from search and report pages

This sounds pretty good. Right now we do not show any products without at least one component so we would also need to figure out a good way to circumvent that check as well.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for the NI! For next steps Emily Toop is investigating the github-bugzilla dichotomy and mitigation for mobile group.

Comment 8

[Kohei Yoshino [:kohei]]

One bad UX thing is, users can see the product list only after signing in.

1. New user is directed from somewhere else to BMO
2. They click New Bug, then asked to sign in or create an account
3. They create a Bugzilla account
4. They click New Bug again
5. The guided bug entry form is displayed
6. They try to find the product they want to report a bug against
7. Can’t find it or leading to a different product

We need to show the product list to logged-out users as well so they don’t have to create a BMO account.

Comment 9

[Emily Toop (:fluffyemily)]

This all sounds excellent, but I think it is only half the story.

The thing I am want to solve is the reverse - how to make Bugzilla issues more discoverable from inside related Github projects. Many teams, including the Fenix team, only ever come to Bugzilla to check on bugs that need to be completed before follow up work has to be done inside GitHub, and so being able to monitor the status of dependent Bugzilla bugs from inside Github is useful. I have started to put together a for this proposal.

Other things I would like to try and resolve:

• Security bugs for Github projects are raised only in Bugzilla. Should we surface these inside associated Github issues, perhaps with generic titles such as "Security issue 123456" with a link to the Bugzilla bug? This way the security issues can be triaged along with the other issues for the project without a separate board being monitored.
• Often bugs raised as Github issues are subsequently decided to belong to other teams and re-raised as Bugzilla issues. A "Raise in Bugzilla" button on Github that would copy all the commentary from GH to Bugzilla will ensure that all the background to the issue is available to Bugzilla teams without them having to follow links to GH issues.