It sounded to me that Alexander understood the issue you explained and 
proposed a process that included a way to alleviate your issue.

stéphane ducasse wrote:

> Sorry alexander
>
> you miss my point, my point is not about the process of harvesting. My 
> point is about
> recording in executable manner knowledge about the system. This is not 
> linked to any bureaucratic
> mechanism. People are crying that there is no documentation about 
> squeak, then they build big plans,
> then NOTHING happens but they talked and talked and talked. While 
> writing a 1 min test is a small
> but a real tangible step in that direction, and in addition I can 
> understand it.
>
> Have a look at the test of UUID, you do not need to be an expert to 
> understand them and everybody can write
> tests like that.
>
> Just for your information, I started to harvest without BFAV and this 
> is a HUGE improvement.
> Still, just uploading a single file in the update stream is painful, 
> marcus is working on that.
> We have to check conflict, updload file, rename cs...
>
> Now people can talk hours about x or float precision, if at the end we 
> do not get
> code with tests, then we all lost our time.
>
>> Hash: SHA1
>> Although I'm on a strict eMail diet I can't resist to write a short 
>> note:
>>
>> Did you ever play the Infocom game ``Bureaucracy, A Paranoid Fantasy''
>> (written by Douglas Adams)? Sometimes I think the harvesting process
>> is a remake of that textadventure. "Tag it with [ZORK], compress it
>> with KNORTZ but never with KNORZT and send it to the BFAV. Then ..."
>> You can't blame people for not loving bureaucracy. If the harvesting
>> is not working than it is the process that is flawed!
>>
>> To be a bit more positive here just a quick thought that may or may
>> not work:
>>
>> How about we move all the bug reports, fixes and suggestions for
>> enhancements to the mantis server? Then a casy study could be like this
>>
>> - - user creates a new report with the serverity *feature*
>> (=enhancement)  describes the enhancement and attaches the code. Now
>> the user knows that his thingy got registered somewhere and does not
>> silently dissapear in a mail archive....
>>
>> - - harverster looks at this entry later on, sees that no test is
>> included and puts this report on hold (=feedback) and adds form Z9 to
>> the report
>>
>> Z9:
>> "Your enhancement was put on hold because we decided to only accept
>> new enhancement if they include a minimal test. Look here for an easy
>> HowTo for writing unit tests and ...." (this gets automagically mailed
>> to the reporter)
>
>
> It may work.
>
>>
>> - - user reads the mail and now knows that somebody looked at his
>> stuff(!) and that there is a problem. If he cares about the thingy I
>> bet he will go the extra mile and provide a test.
>>
>> - - next harvester sees that there is now a test for the enhancement,
>> changes the status of the report to whatever, test the thingy and can
>> add a note that appoves or declines it
>>
>> I think when to reject or to hold a report should be briefly layed out
>> in some kind of policy doc that should be agreed on once (by the
>> harvesters?) and placed on a swiki for public notice.
>
>
> We said that several times, already.
>
>> A sender of a mail that shows up in the mailing list with a subject
>> tagged with [(ENH|FIX|BUG|GOODIE)] should get (once) an auto reply
>> which tells him to use mantis. This auto reply should of course
>> include form Z9'.
>>
>> Alex
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.4 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>> iD8DBQFBTA8rYiF2wSTEZ9gRAgPcAJ9odFI4Ncu2NSb8xAAhl/VwkpvKpgCdGajn
>> 4b8AQ1BBSCREfCXxCwhpheM=
>> =2qsb
>> -----END PGP SIGNATURE-----
>>
>>
>
>
>
>