Re: finally: new authors

From: Date: Mon, 05 May 2003 15:45:28 +0000
Subject: Re: finally: new authors
References: 1 2  Groups: php.doc 
Request: Send a blank email to phpdoc+get-969353187@lists.php.net to get a copy of this message
This mail was not intended to be sent out in this state :) Anyway, I have written it half so I'll only post the last part with my comments again... I have pressed the wrong button in the wrong window... Goba Gabor Hojtsy írta:
But how do we determine this? Past contribution vs. future?
On a case-by-case basis, I guess.
Well, that makes automation tough....
Well, I never really thought with the automation possibily in mind when comparing past contributions to current ones (though there are CVS logs, but as said, the quality can't be checked from them).
OK, OK. So we came to some point where actual contributions are welcome.
What is the preferred language? Most of this is doable in perl, or C, or even PHP.
To handle this on an ongoing basis, a CVSROOT/loginfo(.pl) module could spread the work per-commit. Compare the changed *characters* between two versions, log it somewhere. If you integrate this into loginfo(.pl) then probably Perl (it is used currently there). But if you would like then you can probably plug in anything.
And what if we have a system counting real changes. How do you compare those changes to work done by closing bug reports, or with work done on user notes. How does that fit into the system. Will the guys reading notes deleting / editing them be honored in such a system?
As authors? No. I think they should be honored too, but not as manual changers, unless they changed the manual..... since bugs are already db-driven, the top bug workers should be easy to quantify.
As I have said, I am talking about contributors. Manual notes are treated as an integral part of the manual by our users. Many users base their decisions on suggestions provided in user notes, or correct their local stuff with advices from user notes. Documentation bugs help us to spot errors in the manual. So as I said earlier, I think contributors include authors and other roles too. I don't consider myself as an author for example, as I have not added too much content to the manual. I worked mainly on the things behind. So I won't get listed, if we list authors only ;) My question was how would you compare bugs closed / commented on or notes edited with chars added / modified in the manual. Still keeping in mind, that you don't know if a note added to a comment has a great value, or is nothing.
A person, thinking alone, in a room, and being brilliant with only *one* line or character is very hard to measure. We cannot measure it well by code, by lines, by characters, or even by their popularity among others.... no system has been proposed for such a case, be they doc, bugs, dev, notes, etc..... :-(
Well, nobody said that the human voting will be based on 'popularity among others'. At least I never thought.
Well, that's *bad* automation. This is not 1986, we can now all afford computers which can compare thousands of lines in a short period of time.
OK. Can you afford to contribute time to code such a system (set of filters and stuff)?
To compare lines and changed characters? Yes, I have written much of this code already. To compare the *value* of the changes? No. :-)
As I have said I think numbers should only be used to help in the decision and not to be based the decision on.
Your new examples (though trimmed) are good, and have altered my perspective. How would you (and others) feel about the following: 1. Authors voting *must* read all commits. 2. Of the 20(?) fixed authors, at least half (10) must be changed per year (to ensure new credit, stimulate keeping a position of credit, and avoid author overload). If there are ten listed, 5 must be changed. 3. Depending on the systems available, the voters *should* look at changed lines/chars, XML changes, section changes, etc. They should (by charter) look at as many pieces of information as they have available to them. It is up to the candidates to provide any enhanced information beyond the current systems. 4. Voting should be sealed and private, to eliminate peer pressure, until votes are final. 5. Discussion of their expected votes, and actual votes should be public. 6. A majority of the voters should be allowed to disqualify any other person from voting. 7. Put us lesser authors on another page, so we can get our 6px credit. :-) 8. Non-voters should not be put on the updated authors list, without explaining extreme difficulty (to prune inactive authors).
I think I can't be convinced with a beer. I don't like beer anyway ;) [By the way, I would like to buy a laptop, in case anyone is interested ;)]
ROTFL.... what make/model? :-)
Nothing expensive. I need a stable and modern one, but I have no big budget for this. There are some 900-1000$+VAT modoles in Hungary, which seem to be ok. The very low cost models here are Gericom (from Austria) and Portocom (Hungarian brand, assembled with parts from Taiwan :). Goba
Cheap stuff, my business is doing good. Is there a good money-transfer system to there? Ronald Chmara Ronin Professional Consulting LLC 520-326-6109 "It can only be attributable to human error." --Hal.


« previous php.doc (#969353187) next »