[maemo-developers] adaptation of Extras QA hurdles

[From: Andrew Flegg]

On Tue, Jan 25, 2011 at 15:03, Felipe Crochik <felipe at crochik.com> wrote:
>
> I assume we all agree that the two most important goals for "testing" are
> making sure that the developer has "good intentions" and that the
> application will not break anything. I know that in a "perfect" world we
> also would like to have the testing assure that the "application" is of a
> "good quality" but I think we may need to delegate this to the "entire
> community"

Indeed.

> I like the concept of "developer in good faith/standing". I think by now we
> can "trust" some "developers" in the community for not having bad
> intentions. These should receive special treatment. A developer could enter
> this "group" after having "published" few applications/versions w/o any
> major incidents and "sponsored" by one (or more) "approved developers"

Agreed. Proposal:

  * The first page of http://maemo.org/profile/list/category/products/ are
    given "track-record" status.

  * Other accounts can be given "track-record" status by two developers
    who have "track-record" status or by two "super-testers" (an existing
    flag).

  * Updates of packages from developers with track-record status have
    the karma threshold reduced to 5 (from 10). However, negative votes
    on such a package count as -1.5, rather than -1. New packages for
    "track-record" status still have the same karma threshold.

  * The "super-tester" process stays as-is to catch the edge cases.

For example, if thp uploads a new version of gPodder it will be
promotable after 10 days when:

  +-------------+--------------+-------+
  | Thumbs up   | Thumbs down  | Score |
  +-------------+--------------+-------+
  |  5          |  0           |  5    |
  |  7          |  1           |  5.5  |
  |  8          |  2           |  5    |
  +-------------+--------------+-------+

> A new version of an existing application should have a lower barrier to
> promotion than a new application.

It's obvious; but even a minor change can have an enormous impact.
However, it's unlikely that the package (once optified) will become
non-optified and numerous other things (descriptions will only bitrot
when major new features are introduced; icons won't disappear; bug
trackers are fairly persistent etc.)

> I think each developer could have a "sponsor/partner" developer (one not
> involved with the application) that would be the responsible for the "final"
> approval. This sponsor would be responsible to assure the original developer
> is not doing anything dangerous to the system and could even help the
> original developer with some suggestions. We would have a "mandatory period
> of time" for the application to seat on extras-testing but the "sponsor"
> would be expected to check the app before this period of time. If the
> sponsor failed to do so the application author could try to find another
> sponsor.

TBH, I think that's over-complicated and still likely to result in
many of the same delays. However, I've folded your "sponsor" idea up
into my proposal above.

Cheers,

Andrew

-- 
Andrew Flegg -- mailto:andrew at bleb.org  |  http://www.bleb.org/
Maemo Community Council member