This page is an archive of announcements and policy clarifications sent to the firstname.lastname@example.org list.
Subject: Reminder: Always translate foreign apps!
List URL: https://mail.mozilla.org/private/app-reviewers-internal/2013-August/000164.html
I just rejected this previously approved app due to content reasons: https://marketplace.firefox.com/reviewers/apps/review/testo
Check the app history if you want the full English translation, but let's just say the sound clips in this app talk about unsavory Polish women and vulgar acts with tomatoes, and clearly falls in the category of "obscene pornographic materials, or graphic depictions of sexuality or violence."
We've not had much obscene content submitted yet, but will get more as the Marketplace grows. This is especially challenging for us as a global team with different standards in each of our home countries. Support for an independent 3rd party content rating system is on the roadmap and should be implemented by the end of the year , but in the meantime we need to rely on each other to stay in sync about what content crosses the line.
And if you're reviewing an app in a different language, make a best effort attempt to translate enough of the content to get a good idea of what the app is about. Here are some tools I use (and please chime in with others):
- http://translate.google.com, obviously =]
- If you have an Android phone, you can use the Translate app to take a picture of any text and then select it with your finger to translate
- This add-on enables you to select any text (like an app description) to quickly translate it: https://addons.mozilla.org/en-US/firefox/addon/s3google-translator/
If you're uncertain about the appropriateness of content in an app, ask somebody in #app-reviewers or escalate for a senior reviewer to investigate.
1. International content ratings PRD: https://docs.google.com/a/mozilla.com/document/d/1Dqg-U-zdinUwG3DO94SBmUf0irtwqw5A_YxIW60-qhU/edit
Subject: New app review policy on link opening behavior for Adsense
List URL: https://mail.mozilla.org/private/app-reviewers-internal/2013-August/000144.html
Happy Monday, team!
There have been an increasing number of rejections recently for Adsense and other ad links opening within the app. This is a frustrating situation for these developers, since this content is out of their control so there's nothing they can do to fix it. There's ongoing discussion on how Mozilla can address this , but in the meantime rejecting these apps is doing more harm for the Marketplace than good.
Effective immediately, send developers a [Notice] instead of [Required] feedback if links within ads or other accessory content outside of their control opens within the app, as long as the only impact is that the user is unable to navigate back to the application. If opening the link causes a Gaia reboot (which happens sometimes for non-mobile pages that use up all available memory), then you should still reject the app. Content that is within the developer's control or is a primary focus of the app will be held to the original guideline.
I'm also seeing a lot of questions coming back from developers asking what links are impacted, so try to add some extra detail and/or a screenshot of where you found the links. It would be nice if developers tested to find this for themselves, but since we already know we might as well tell them. =]
Subject: PSA: Don't stop reviewing, hold on to that (rejection) feeling
List URL: https://mail.mozilla.org/private/app-reviewers-internal/2013-July/000124.html
When you're reviewing an app and find a problem that's rejection-worthy, don't reject it right away. Keep reviewing and try to cover as much of the app as you can, then send the developer one list of things that need to be fixed. This reduces the number of times an app needs to be reviewed and helps everyone be more productive.
PS: bonus music video that you should sing along to after reading this email: https://www.youtube.com/watch?v=rfUYuIVbFg0
Subject: PSA: Consistency is the watchword
List URL: https://mail.mozilla.org/private/app-reviewers-internal/2013-July/000132.html
Greetings, intrepid reviewers!
This morning, we got an unhappy email from a developer:
> This morning my app was approved after being taken out of the market because
> the manifest file was temporarily unaccessible. Why has it now been rejected
> only a few hours later? This app has been in the market for serveral months.
> Why were these problems not picked up the first time? I am only glad that this
> is not a comercial app as I would face a financial lose. I am very
> disappointed with this firefox project. It seems unprofessional and badly
> organised. It is no way near ready to be released commercial.
Ensuring consistency of reviews is a normal growing pain of an app review team, and is the biggest issue we'll face as we add more reviewers. Here's a few things you can do to stay in sync:
- Understand the context: always skim the app history to understand the context the developer is coming from. Has the app been rejected previously? Does the developer seem frustrated?
- Thoroughness: review as much of the app as you can, don't stop when you find a rejectable issue
- Lenient mindset: our goal isn't 100% compliance with the guidelines, but to provide reasonable assurance that apps are safe, that they work, and do what they claim to do. Err on the side of leniency -- better that a guilty app go free (and therefore get negative reviews from users) than an innocent app be punished.
Consistency is an especially sensitive issue for re-reviews, since these developers consider themselves to be in production mode. Removing a published app from Marketplace is much more disruptive than rejecting one that's not gone live yet, so in this case stop and ask yourself if the issue is bad enough to merit removing their app completely. You can always send the developer a note and ask that they fix the issue at their earliest convenience.
Subject: PSA: login information for apps
List URL: https://mail.mozilla.org/private/app-reviewers-internal/2013-May/000002.html
Many apps will require the user to log in. As long as registration doesn't require money and the process isn't extremely complicated, we should test the sign up process. You can use the following info:
username: mozappreview at gmail.com
password: [REDACTED] -- ask the list if you need this!
This is also the username and password for our test Facebook and Twitter accounts, if logging in to those social networks is required.