MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/MDN-dev-survey

This translation is incomplete. Please help translate this article from English.

Kikorokoro hiki kinapeana mahitaji ambayo programu lazima itimize ili kusambazwa kupitia Firefox Marketplace. Mahitaji haya yameundwa ili kusawazisha yanayotakwa na waendelezaji na watumizi wa programu kutoka kwa Firefox Marketplace. Waendelzaji wanataka mahitaji yaliyo na haki, yasiyobadilika, na ambayo hayana ukatili na yenye uaminifu ili kuwawezesha kutengeneza biashara. Kwenye upande mwinigne, watumizi wanataka hakikisho ya kwamba programu ni zenye usalama, zitatumika kwenye vifaa vyao, na programu itafanya ambavyo inasema itafanya. Mahitaji ya programu yanayofuata yana malengo ya kutimiza usawa wa mahitaji haya.

Haya ndiyo matarajio ya Mozilla yanayoeleza mapitio ya programu ni nini na sio nini:

  • Vigezo vitatumika kwa njia yenye usawa, huruma, na isiyobadilika. Njia hii ya kupitia programu haina lengo la kuwa mlinzi, ila lengo lake ni kuwa njia ya mguzo ya kutoa maoni inayowawezesha waendelezaji kufaulu zaidi.
  • Wapitiaji sio timu inayohusika na maswali na majibu! Wakati wanapopitia, watainagalia manifest ya programu kisha waitumie programu kwa dakika kadhaa kama mtumizi wa kawaida.
  • Programu ikikosa kuhitimu, mwendelezaji atapatiwa maelezo kamilifu ya shida zilizopatikana, hatua za kutoa mapato hayo, na patakapowezekana, wapitiaji watawaelekeza waendelezaji kwenye njia inayofaa kwa kutoa viungo vitakavyomwelekeza kwenye nyaraka au watoe mapendekezo ya mabadiliko yanayoweza kufanywa.
  • Wapitiaji watatoa maoni kuhusu programu inavyofanya kazi, ila hawatatoa maoni kuhusu umbo la programu. Kwa mfano, programu iliyo na aya yenye maandishi mekundu kwenye usuli wenye rangi ya chungwa haitakataliwa kwa ajili haivutii, ila itakataliwa kwa kukosa kusomeka.
  • Kwa kawaida huwa tunawapatia waendelezaji faida ya shaka. Kama wapitiaji hawana uhakika kama programu inafaa kukataliwa au la, watauliza maswali kabla ya kuikataa programu. Programu hazitakataliwa (ikijulikana) kwa ajili ya maswala ya jukwaa ambayo hayawezi kubadilishwa na mwendelezaji; hata hivyo hatutapatiana idhini kama programu haifanyi kazi.

Usalama

Maelezo kamili ya usanifu wa usalama wa programu yanapatikana hapa: https://wiki.mozilla.org/Apps/Security

  • Manifest ya programu lazima itolewe kutoka asili moja na programu.
  • Manifest lazima ihudumiwe na kichwa cha aina ya yaliyomo katika application/x-web-app-manifest+json.
  • Programu hazifai kutumia vielekezi au iframes kupakia vitu ambavyo muendelezaji hajaruhusiwa kutumia.
  • Ruhusa zinazoombwa lazima zibainishwe katika manifest ya programu na maelezo ya mbona ruhusa zinahitajika.
  • Programu ya aina iliyopendelewa itaangaliwa kwa undani, ikiwemo uangalizi wa kodi, kwa sababu ya uwezekano wa kuwepo kwa mambo halifu na upotezaji wa data katika API zilizopendelewa.
  • The Content-Security-Policy (CSP) defined in the app's manifest determines what the app's code can do.  The default, if unspecified, for non-privileged apps is the same as any website; apps of type privileged have a more restrictive default.  The validation report created on submission to Firefox Marketplace will indicate potential CSP violations in your app - though beware false-positives and usage in parts of 3rd party libraries you don't use.

Privacy

  • The developer must link to a privacy policy during submission, but there are no requirements for the format and content of this privacy policy. Feel free to use our privacy policy template. Also take a look at our privacy policy guidelines.

Content

  • Any apps that violate our Content Guidelines below are not allowed. If you think you have an edge case, please ask the review team for clarification, even if the app isn’t yet ready to be submitted. We want to help you stay on the right track, rather than invest development time into content that will be rejected.
  • Starting in January 2014, all apps must receive a rating from the International Age Rating Coalition (IARC).  To obtain this rating, we'll direct you to a brief questionnaire during the submission process, and you'll receive the rating immediately.  More information about the rating process is available here.
  • Screenshots and descriptions submitted to the Firefox Marketplace must accurately represent the app.  You may include 1-2 "marketing" images that show compatibility, compare features, or otherwise generate interest, but there must be at least one screenshot of the app in action, so that users can preview what they're actually getting.  If one of your screenshots is a splash or launch screen, you must also include a screenshot of the functional part of your application.
  • In the app manifest, the locale keys should match the localizations that your app supports. By providing a locale key in Polish, users will expect your app to be available in that language.
  • The app icon should follow the Firefox OS app icons style guide. Only a 128 x 128 icon is mandatory, but we also recommend a 512 x 512 icon too (for more details, see Icon implementation for apps.) Note that icons can be round, rounded corner square, or square, as per the style guide.

Content guidelines

This list describes types of content that are inappropriate for the Firefox Marketplace. This list is illustrative, not definitive, and may be updated. If an application is found to be in violation of these content guidelines, Mozilla has the right to immediately remove the application from the Firefox Marketplace.

  • No obscene pornographic materials, or graphic depictions of sexuality or violence.
  • No content that infringes anyone’s rights, including intellectual property or other proprietary rights or rights of privacy or publicity.
  • No content that is designed to harm Mozilla or users (such as malicious code, viruses, spyware or malware).
  • No content that is illegal or promotes illegal activities.
  • No content that is deceptive, misleading, fraudulent or is designed to phish or perform other identity theft.
  • No content that promotes gambling.
  • No content that engages in the advertisement of illegal or controlled products or services.
  • No content that exploits children.
  • No content that degrades, intimidates, incites violence against, or encourages prejudicial action against someone or a group based on age, gender, race, ethnicity, national origin, religion, sexual orientation, disability, religion, geographic location or other protected category or constitutes hate speech.
  • No content that misleads a user into making a purchasing decision.

Functionality

  • The reviewer must be able to perform the app's primary advertised features. Cosmetic flaws and minor inconveniences will be reported to the developer, but will not prevent an app from being approved.
  • The app must not compromise system performance or stability.

Usability

  • The developer must make a reasonable attempt to optimize app layout for the target platform. The intent of this requirement is to catch obvious failures, such as:
    • An app submitted for mobile that's obviously a desktop site.
    • An app that very obviously doesn't stretch to fill available screen space (imagine a 320x480 app that only takes up the top corner on a tablet, with the rest of the screen blank. This is surely not intended!)
  • The app must implement its own method of navigation and not rely on browser chrome or a hardware back button, which will not be present on every device.
    • For example, an app will be rejected if the reviewer navigates somewhere within the app and isn't able to navigate back. Apps are NOT required to implement a button bar common to native apps.
    • On Firefox OS v1.1 and greater, you can add the chrome manifest property to add minimal navigation controls.
  • Navigation elements, such as buttons and links, must be easy to click or tap.

Blocklisting policy

We hope we never have to use it, but we do reserve the right to remove ("blocklist") any published app that is later found to violate any security, privacy, or content requirements, or apps that seriously degrade system or network performance. Developers will be informed of the situation before an app is blocklisted, will be assumed to be a good citizen unless we have specific evidence otherwise, and will receive full assistance from the app review team to communicate what's going on and get the problem resolved. Specific examples of situations where blocklisting is warranted include:

  • Phishing
  • Spamming
  • Changing content from Puppy Pictures v1.0 to Brutal Violence v1.0 (without updating the content rating)
  • Severe misbehavior of app for a large percentage of users — degrading phone performance, causing reboots, causing user data loss, etc. where users can't tell that it's because of the app and where it isn't solved by rebooting the device.
  • An app being used for attacks on the network, such as a distributed denial of service (DDOS).

More information

The following resources provide more information on the review process and app reviewers:

  • Reviewers test criteria — this page describes the tests that app reviewers will perform on your apps
  • App reviewers — how to contact the app review team and get involved to review apps

Document Tags and Contributors

 Contributors to this page: denomain, buluma_michael
 Last updated by: denomain,