Is it too much hassle to have a community vote?
For example, nominations open until 23:59 xTZ* on 7th Mar 2012, voting 00:00 xTZ on 8th March until 23:59 xTZ on 14th March 2012?

The notion of super-testers is a very good one. However, I have to I agree with freemangordon's comment re: administrating testing vs responding to tests (i.e. fixing bugs & writing/editing code). (post #3)

While super-testers should be code-aware, perhaps they should not be responsible for contributing code to the piece of software they are testing (and trying to promote through the QA system). The reasons for this are
(a) time is finite so it's very much a case of, either administer the bugs or write code; a programmer will, quite rightly, believe he or she is of more value to the cause by writing code - especially if the bugs pertain to software he/she has very little to do with.
(b) managing bugs is not about programming itself, it's about describing problems and finding out whether/how they can be resolved.

Another reason for Not having key developers administering bugs is that a significant bug for many end-users is the absence of documentation. Preparing documentation is time-consuming so arguably someone whose strengths are writing C/C++ etc. are probably best directed to creating software, not paperwork! On the other hand, decent explanation of how to use software is truly vital. Indeed, I would consider it part of the UI, especially for terminal programmes where there is no graphical UI; "<command> --help" isn't always that enlightening!

Once a tester has investigated a programme, he or she should be able to verbalise how to get the most out it, as well as converting (sometimes terse) developer comments into cohernt prose. The most technologically averse user can be surprisingly helpful in doing this.

There is obviously a problem when developers no longer attend (for want of a better word) the community. In this case, talented coders may be needed to coerse the problematic parts of programmes that are languishing in -devel or -testing to get them functional enough to do the intended task (even if with no-frills). All the same, is it not a waste of time for active developers to be doing testing when they could be coding instead?

The criteria for being an admin is more about competence in communication than anything else:
- Can he/she extract info from the developer about how-to?
- Can he/she explain clearly what isn't working in a way that can be addressed be a developer (i.e. write a proper bug-report and separate one feature from another)?
- Does he/she want to bring as much of the software in the repositories up to release standard?
>> the only proviso is that the tester is aware of what the programme "should" do. This is more of a pre-requisite for a testing than a testing-admin role, I think?

Regarding how to test and what to test, this is an area that needs to be negotiated by community developers (as a group) and those willing to test. There needs to be a very simple checklist for software to pass, which any user can test against; where a programme fails a check point, the tester simply needs to say doesn't pass [test] and describe why. Where bugs have already been filed on a programme, the testing admins role would be to gather reports into a todo list for development. Much quicker than have a/the developer go through the bugs because the collater wouldn't be trying to solve things while organising them!

There is this programme - perhaps it could be the first item to get sorted and pushed through the system? KISStester Package | KISStester TMO. Its official bug-tracker is empty but the TMO thread is full of references to problems. KISStester would provide a good basis for promotion. Some variation is required for different types f software e.g. GUI/terminal/library/etc.

Aside: there are some programmes in extras that are barely passable in terms of doing what they're supposed to. Perhaps all software in the repos needs to be 'bugtested' and there also needs to be a means of downgrading software from extras to -testing?

The priority/order for pushing through programmes will always be contentious. IMHO, it would be best to get all latent** -devel programmes to -testing. Once that state has been reached, process latent -testing programmes on a popularity basis (i.e. num total downloads).

Concluding suggestion: appeal for testers and testing-administrators: users and fringe-members might like to do/know more about maemo and their devices. So long as how-to information exists, the main pre-requisite is moviation and willingness.

In this way, there could be a collection of small teams, each with a testing admin, and a couple of testers. These teams would each have a section of the repositories to bug test and promote. For those programmes that failed the test a bug summary could be posted.

To actually fix bugs, very clever people (developers) are required, who are prepared to edit others' code. For this purpose, might a number of community developers might be happy to act as a pool? The idea being that testing-admins could present a todo list for one of these forgotten programmes to the pool, and the next available programmer can convert a well described bug to either fixed or wontfix. I know bug-fixing can be dull but if you're a programmer it's better than writing instructions, right?

*xTZ: any specified time zone - whatever is specified but the same for all.
**latent - not moving through the repos - e.g. un touched for 4+ months.