Hi,

I think, the list Stef provided was meant as a set of tasks which  
would suit for such a system. The list does not provide a concise  
specification for each task, which will eventually be needed as I  
agree with you. But in my opinion it can very well be extended to  
that and the items are not too bad to start with. For example, tasks  
such as "fix the slow redraw problem", "implement an atomic load for  
MC" or "double the speed of MC package loading" (*) should work well  
and be valuable to many users, no?

Adrian

(*) btw, just did that the other day (asking a class for its system  
category is slow but performed very often while loading. Since Class  
already has an ivar "category", it was quite simple to make faster).  
Marcus added the change to the most recent 3.9a version.


On Mar 19, 2006, at 23:00 , Andreas Raab wrote:

> Hi Stef -
>
> Well, the good thing is it's *really* easy to prove me wrong. Just  
> do it. But I think you didn't read my previous message very  
> carefully; I actually pointed to a number of (what I think)  
> important questions that we need to ask ourselves (like: Is the  
> scope well-defined? Can an "average" squeaker do it or are there  
> only three people in the world who can solve that problem at all?  
> Is there an existing support network? Is this an issue that is of  
> interest for a significant number of other people to solve?) in  
> which (at least by my counting; YMMV) many of your tasks do not  
> rank very highly which (again to me) makes them unlikely candidates  
> to work out in a bounty system. I just don't think that all tasks  
> are equally valid in a bounty system and much depends on why we  
> think a bounty system works at all.
>
> Cheers,
>   - Andreas
>
> stéphane ducasse wrote:
>> I would have not expected something more positive from you.
>> Stef
>> On 18 mars 06, at 10:47, Andreas Raab wrote:
>>> Hi Stef -
>>>
>>> I hope you're not too disappointed but personally I don't think  
>>> that this list is particularly well suited for applying bounties.  
>>> Most of the goals seem way to unspecific ("improving", "fixing",  
>>> "making X better" mean little without saying what to improve,  
>>> fix, or make better) and some of the tasks seem quite large and/ 
>>> or complex. But feel free to give it a shot, your opinion is as  
>>> good as mine (or perhaps better) in this area. I'm actually kinda  
>>> curious myself what (if anything ;-) might happen.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>> stéphane ducasse wrote:
>>>> On 18 mars 06, at 01:28, Andreas Raab wrote:
>>>>>
>>>>> Personally, I think bounties work best if they are used in the  
>>>>> context of an existing support network. For example, I would  
>>>>> think that a bounty for, say, "making loading in Monticello  
>>>>> faster" might work because there is a community of MC  
>>>>> developers/users out there, it's a small, tangible (and easy to  
>>>>> measure) improvement and it's (most importantly) not in the  
>>>>> critical path of anyone (if it doesn't get done, so what).
>>>> Exactly.
>>>> Here is a list of item
>>>>     improving squeaksource
>>>>     fixing scriptloading
>>>>     making MC loading faster and been better
>>>>     having a better OB faster integrated RB
>>>>     fixing the weakreference
>>>>     fixing the refresh
>>>>     curving MVC
>>>>     cleaning the image to use toolbuilder
>>>>     ...
>>>> are the kind of items we would like to see fixed.
>>>> So this would work.
>>>> Stef
>>>
>>>
>
>