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
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpZYEzxxfatv.pgp
Description: PGP signature
