[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Measuring skills of a Debian Developer



On Sun, 12 Nov 2000, Aigars Mahinovs wrote:

>      With increasing number of Debian Developers, it is getting hard
>      to measure skill of a DD in a particular area of interest. For
>      example there are DD's that make phenomenally good Debian
>      packages, others are professional designers, others are genius
>      in HTML, others grock Perl.

Okay, for those great skilled DDs this may be a good idea, but what
about the others?  Do you want to fire them from the project or do you
want to blame him?  Except this I don't see, what your idea should be
good for.

>      basic packaging, advanced packaging, C, C++, Perl, Python, use
>      of BTS, [add others here]

And where do you need this for?  Sounds like you are creating a
database for head hunters, but I don't see the need for our project.

>      At first this info would be strictly informational while after
>      some time (2 releases should do the trick), this info should be
>      used to determine if a certain DD is skilled enough for a
>      certain task (NMUing libc, packaging GPL'd Corel Draw :).

IMHO it's a better idea to work on the distribution instead of rating
other developers.

>      There should be different ways to get the next level of certain
>      skill. Some skills should be updated by scripts only ("bug
>      fixing speed" :).

Nice idea, but how does this robot decide _why_ a bug is open for a
long time?  Okay, there are developers who are a little bit lazy in
fixing trivial bugs but to find them out I don't need a new database
or rating, I only need to look at the BTS page of the package/user and
into the changelog.

>      Some could be based on a feedback from users.  An some skills
>      could be updated by passing some tests.  There should also be a
>      translation table for known certifications (Brainbench, RedHat,
>      ... ).

Do we really need this?  We need motivated people who spend time in
the distribution, but where do we need certifications for?

BTW: IMHO we need some mechanism to find out which developers are
inactive for a long time, while their packages have many open bugs
(which means that someone should adopt these packages and fix the
bugs), but as far as I know someone is already working on such a
database (don't know whether it is already evaluated).

>      If there will be no good reasons against this, I'll work on a
>      proposal.  Comments? Ideas?  Suggestions?

I dislike your idea.

Tschoeeee

        Roland

-- 
 * roland@spinnaker.de * http://www.spinnaker.de/ *

Attachment: pgpp1gWUHbKLC.pgp
Description: PGP signature


Reply to: