Websites/Plugincheck: Difference between revisions

Websites/Plugincheck (view source)

Revision as of 13:40, 7 May 2014

1,366 bytes added , 7 May 2014

no edit summary

Espressive

Confirmed users

210

edits

@@ Line 47: / Line 47: @@
 [https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check]
+== Ideas On Improving PluginCheck ==
+=== Plugin Release Notifications by Vendors and Community ===
+One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:
+) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.
+NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.
+) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification.
+) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email.
+) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.