[Soc-coordination] Re: Deciding on our applications

[Wookey]

On 2007-04-07 10:26 +1000, Anthony Towns wrote:
> On Wed, Mar 28, 2007 at 03:45:53AM +1000, Anthony Towns wrote:
> > As a first pass (after removing some dupes), I came up with the following
> > categories: (one x per application, one line per topic)
> >  1. cd tester               (16 applications) xxxxxxxxxxxxxxxx
> >  2. security                (15 applications) xxxxxxxxxxxxxxx
> >  3. website                 (13 applications) xxxxxxxxxxxxx
> >  4. piuparts, u/g testing    (7 applications) xxxxxxx
> >  5. emdebian/embedded        (5 applications) xxxxx
> >  6. user2user communication  (5 applications) xxxxx
> >  7. livecd                   (4 applications) xxxx
> >  8. debbugs                  (4 applications) xxxx
> >  9. openid                   (3 applications) xxx
> > 10. apt-checkpoint           (3 applications) xxx
> > 11. biometric auth           (3 applications) xxx
> > 12. kernel config            (3 applications) xxx
> > 13. mirroring                (3 applications) xxx
> > 14. cdd toolkit              (2 applications) xx
> > 15. i18n/l10n                (2 applications) xx
> > 16.                                           x
> > 17. misc                     (3 applications) x
> > 18.                                           x
> > My guess would be we'll probably have a guaranteed slot for each of the
> > top four (CDs, security, website, u/g testing), and the others spots
> > we get to fight for :) We've got around 18 unique topics; last year we
> > ended up with 10 slots, iirc.
> 
> Okay, so this year we've ended up with 9 slots by the looks, which is
> pretty limited compared to the apps we'd like to accept... I figure
> we'll want to do a final reranking based on:
> 
> 	- how useful the project is
> 	- how necessary it is to have the project as a SoC app
> 	- how well prepared the student appears to be
> 	- how helpful the mentor's going to be
> 	- how likely the project is to succeed
> 
> If students or mentors would like to take the opportunity to add any extra
> comments to apps over the weekend showing any progress that's been made
> on the app or working with the mentor or similar since initial submission,
> that'd probably be helpful.

This all seems sensible. From looking at the top 20, it does seem to
me that the process tends to mean that applications (which are any
good) tend to get rated higher simply because more people read it and
rated it. But if the application is more specialised then it can score
worse as people do not feel qualified to express an opinion. I'm not
sure how we normalise the scores.

And I have no real idea how to rate applications for 'how useful the
project is'. e.g. there are two for improving the bug system (marga
doing web interface, Gustavo doing bug upstream linking/triage
interface). Both of these are clearly useful to many people as everyone
uses the bug system, but from where I stand it seems a pita to have
two bug system projects and niether of the emdebian ones make the cut.

Similar comments could be made about the two internationalisation
projects ('Improved package management of language packs' and
'Building localization infrastructure for the Debian project'). Both
are reasonable projects (although I think the former has a fundamental
flaw in it's approach (unless I misunderstand)), but I don't feel that
_both_ are more valuable than embedded. 

Of course from an objective POV many fewer people are interested in
debian on embedded, than the bug system, or localisation, so maybe
that is the right answer. It doesn't feel right (for me) to go round
modding those bug apps down just because I think something else is
more important - they are good applications.

So I'm left feeling the overall ranking is not optimum, but not at all
sure what might be done about that, or whether others would agree.

Is this just me and my pet project, or do others agree? 

Wookey
-- 
Principal hats:  Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/