On Tue, Jan 25, 2011 at 15:03, Felipe Crochik <fel...@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:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
