Oops, I accidentally did a reply just to Dave instead of to all. So ... anyway, I think that we need an automated system that punishes spammers or what not who upload via bots or however, instead of punishing reviewers and bona fide developers by over-complicating the system. Our reviews should be sufficiently automated that a spammer gets filtered out. Our reviews should be sufficiently consistent that notes from a previous rejection should not be necessary, either it is suitable to pass or it's not, the history of the discussion for getting it there should not be relevant.
We really really really need to make this as highly consistent and efficient system for reviewers, for developers, and users. Any manual interventions at this stage should be considered 100% temporary until we figure out a way to automate them out. >From the developers point of view, I think every app submission should be accepted or rejected. If it was rejected, they can resubmit with whatever fix (to the description or to the permissions for the most part, since that is primarily what will be reviewed). The next reviewer doesn't need to do anything but review the current submission. The history of submissions should be irrelevant. Cheers, Rick On Fri, Aug 16, 2013 at 7:33 AM, Dave Morley <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It's dawned on me that it might be useful for people to know what > happens with each level. > > 1. Dev creates an app adds it to myapps under a draft status. > > 2. Dev submits it for review. This now shows up to us in pending review. > > 3. A reviewer click on review on a app and it enter Under review > > 4. During the review we have 3 buttons and a comment box > a. Ask for more info, Sends the application back to the dev in needs > info status (needs info is like the draft status) With an email sent > to the dev with the description added to the comment box. > > b. Rejected, is an end state this is for malicious apps to get rid of > them forever there is a duplicate checker that prevents an app with > the same name being resubmitted. > > c. Approve, sends it to the next stage. (in click apps that would be > ready to publish so the dev can push it out) > > 5. Ready to publish. This sends an email to the dev that says you app > is ready to publish follow this link and click on the publish button. > > 6. Published. Visible to the end user. > > > The reason for the two step ready to publish/publish is if the dev > notices an issue he can pull his app immediately back to the ready to > publish fix what ever then submit an update. Once the update is > approved it can be put back to published by the dev. Or if the dev > wants to make a big announcement on a specific date or HIB for example > it can be held in ready to publish till the announcement is made. > > I hope that makes things a little clearer? > - -- > You make it, I'll break it! > > I love my job :) > http://www.ubuntu.com > http://www.canonical.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlIODfIACgkQT5xqyT+h3Og0awCePeqnLmv0w1oToqGWUK1+PWwC > aUsAn2HY0jI8CozTIf+nAjMACclloxZf > =nK+E > -----END PGP SIGNATURE----- > > -- > Mailing list: https://launchpad.net/~ubuntu-appstore-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
