Update:Remora Idea Dump

From MozillaWiki
Revision as of 16:40, 24 August 2006 by Cameron (talk | contribs) (link to mockups)
Jump to navigation Jump to search

« Back to Remora Main

Approval Queue

Metrics

I think we should take a look at making the review queue just one of many ways an add-on is "reviewed". Think of the other ways we could rate things and how much weight each of these sources should get:

  • user feedback, weighted based on the user's feedback rating (good reviewers' opinions score higher)
  • reviewer feedback, from the queue itself
  • mozilla QA approval (recommended list)
  • user ratings (thumbs up/thumbs down)
  • favorites list membership (how many times a user lists it as a favorite)
  • update check frequency (how many users actually use it)

Morgamic


[02:13] <morgamic> what could we do to make the good add-ons float to the top based on popular opinion as well as some minor reviewing by our reviewers?
[02:13] <fligtar> If we have a queue, I would prefer it list the extension name, and very very basic info like supported apps/oses and then you click to see an approval page where we can dump all the info instead of hiding the form and description and such
[02:15] <fligtar> we could add a field for a reviewer to mark that they are interested in reviewing this addon in the future (if it's not already taken by someone) and then when a new version is submitted, they get an email

shaverthoughts(tm)

I'd love to see the AQ die, or be something where N "random people" can review to ensure that the description is good, the policies are followed, and it's not obviously a scam or abuse of some sort.

For the "stamp of approval" cases, I think that our current crop of reviewers include a number of the right picky-and-thorough type of people. Add-ons could be "nominated" for a fuller review to become part of the "top tier".

I'd also like to see a way for updates to be pushed out automatically by the developer, perhaps via a per-developer or per-add-on flag to permit that streamlining.

EULA/PP localizations

If we support EULAs/PPs, we would either a) require someone that doesn't speak english to accept something they can't read or b) require an extension author to get the length EULA translated into all of our supported locales and either put into the install.rdf or use a special interface we make. Fligtar

Typically, the English version is the normative one, and translations are provided as a non-binding courtesy one. That's the case with the Firefox EULA, for example. Shaver 06:34, 15 August 2006 (PDT)

Dictionaries

The Firefox and Thunderbird clients have support for MySpell dictionary extensions. Currently the client treats a dictionary extension like any other extension, but the administration requirements may be unique:

  • There should be one official dictionary per locale.
  • It should be maintained by the l10n team that maintains the client locale
  • Because myspell does not support aggregating multiple dictionaries, there is little reason to support specialized (architecture, chemistry) dictionaries.
  • For locales that do not ship a dictionary by default in the client (due to licensing issues), the major AMO entrypoints might feature a "Install German dictionary" link.
  • The clients have an AMO entry point in the "Get More Dictionaries..." context-menu item in spellchecked textareas
  • Extensions for online services that provide dictionaries should probably be treated separately from myspell dictionary extensions

Which of those are actual requirements? Providing an English "basic + computing" dictionary seems like it could be worthwhile, even if myspell sadly can't aggregate for us (yet?). If such a dictionary appears and is useful, is it a requirement that we not post it? Or not post it as a "dictionary"? Shaver 16:46, 20 August 2006 (PDT)

Also: would we permit variant dictionaries for locales that we don't ship, such as en-CA (as distinct from en-GB and en-US)? Who would sign off on those, in the absence of a l10n lead for that locale? Shaver 17:43, 20 August 2006 (PDT)

Categories

Ought categories be able to apply to multiple applications? eg. "Developer tools" could be used on Firefox or the Mozilla Suite... Cameron 09:51, 22 August 2006 (PDT)

What's the point of categories for dictionaries, search plugins and locale packs? Cameron 09:52, 22 August 2006 (PDT)

Also, why are we calling them tags in the database? Cameron 09:51, 22 August 2006 (PDT)

Site banner/identity

Can we just have one banner for the whole site, instead of the silly app-spefic banner? I've seen the app specific one on the mockups and it gives me nightmares. Splitting the site by app causes problems when we want to add new apps, and search doesn't work properly, and we want to get the app parameter out of urls because it's silly, but then how do you say "hey check out this great thunderbird theme" and link your friend to it? I think it's a bad idea overall. Cameron 09:51, 22 August 2006 (PDT)

URLs

I want to get rid of all the cruft. I don't want to see a single .php anywhere. Atm we have faq.php, support.php, etc. etc.

I want 

/addon/1234
/addon/1234/previews
/author/321
/developer
/developer/myaddons
/developer/myaddons/new
/developer/myaddons/update
/admin/usermanager
/admin/appmanager

etc. etc.

(they're just ideas for the urls btw) Cameron

With cake, it's pretty much guaranteed you won't see .php anywhere. Also, because of the models, there will be very very few pages that aren't associated with a table. For adding/updating/managing addons, the url will be addons/add or addons/manage. The only thing in /developers will be a listing of your addons with links to the other models. For admin stuff, it will be a page with links to the administrative things for the various tables, like tags/manage. Obviously, this will all be controlled with cake's ACL so not anyone can access these features. Fligtar 18:46, 22 August 2006 (PDT)
I think that /addon/addon-name/ or even /addon/1234-addon-name/ is better than /addon/1234/ /author/321-john/ or /author/john/ is also better than /auhor/321/ Tbassetto 01:14, 23 August 2006 (PDT)
Sure, but I think we've been through this before and it creates problems if the add-on's name changes... Since it's all done through .htaccess anyway I suppose it could just match both the addon's current name and it's old name/s with the ID, if we added old add-on name info to the db... that's ugly though.

User accounts

Can we use only one database of accounts for the dev cp, forums, reviews and whatever else please? It's soooo much nicer. Cameron 09:51, 22 August 2006 (PDT)

Mark O'Sullivan (creator of the forums we'll be using, has said that it is possible to integrate with our existing sessions and users, so you won't have to login specifically to the forums or anything, it will all be the same login. Fligtar 18:48, 22 August 2006 (PDT)

Licensing

It would be great if each addon had a link to the licence or licenses it was available under, and to the source if the licence requires that distributors such as a.m.o. make it available. I believe we don't have a licensing policy for a.m.o, so it's all the more important to a) make it clear, and b) comply with whatever the licence is if it has things to say about distribution. Gerv 14:09, 23 August 2006 (PDT)

It's planned to have developers able to specify an EULA, and also for them to be able to use html in the developer notes about the add-on, so they could link to their source code there - is that enough? Cameron 08:02, 24 August 2006 (PDT)
Retrieved from "https://wiki.allizom.org/index.php?title=Update:Remora_Idea_Dump&oldid=32370"