← Back to team overview

ubuntu-appstore-developers team mailing list archive

Re: Summary: Planning going live

 

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 <davmor@xxxxxxxxxxxxx> 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     : ubuntu-appstore-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers
> More help   : https://help.launchpad.net/ListHelp


Follow ups

References