Hi Diego . I think it's a good direction.

Since I want to see your work used as much as you do, and since nobody
can give you any sort of warranty, let's do it another way - I'll give
you some tips that minimize your risk. It may seem less exciting this
way, but I'm talking from experience here - there's nothing more
frustrating in this arena than running ahead implementing what seems
enough to the implementor and finding that the people that need to adopt
it don't see it the same way.

This is relevant to anyone (and not just in the Squeak world).

* Don't make your changes dependent on any technology that isn't already
in the image. If you do, don't hope for them to become anything more
than an SM package. It's better to scale down the project or delay it,
because what seems like shoo-in for adoption today, might end up taking
a couple of months or years yet. Just ask Craig, Anthony, Henrik... So
for now, I strongly suggest you not depend on Traits.
* Your idea of taking small pieces is great. Under the new rules of the
game, it's almost a requirement. Before your stuff gets into the image,
it will have to be reviewed by quite a few people, and before they put
that time into it, they'll want to understand what it's good for. So you
want to structure your work as many small bits *that are each obviously
a good thing by itself*. If you're doing refactorings, the same idea
applies. Don't change everything around - make local changes, and let
the add up.
* As you can see from the recent discussion, radical changes are
controvertial. We're probably not ready to do something as big as
convert Morphic to Traits, or separate it completely from eToys. We
don't yet know enough. Start small. Start with obviously good things.
Want an example? Make Genie separatable from Morphic. If you want more
likely tasks, I'll generate more.
* Build the work process over time. Send in something really small at
first, we'll have a look. We'll have comments. As we get our
expectations synchronized, you'll be able to assess what we'll accept
and what we won't. And then you can decide to do bigger pieces (take a
bigger chance).

Does this make sense to you?

Daniel Vainsencher (Guide in charge of refactoring the image, along with
Ned)

diegogomezdeck at consultar.com wrote:
> Hi guys...
> 
> We [1] are interested in performing the famous cleaning process of Morph
> hierarchy.  We want to expose our ideas/limitations/questions.
> 
> 
> Ideas:
> 
> - We'll create a page on swiki with the ideas of cleaning.  Examples of
> cleaning tasks are: remove of direct accessing of variables, template
> methods for the creation of halos to avoid unnecesary ones, etc
> 
> - We'll spend a short(?) period of time to create a tentative list of tasks
> 
> - We want to publish a lot of small pieces instead of a big one. In this
> way, if we cann't finish the work somebody can continue from this point
> - The state of the process will be informed in the swiki.
> 
> 
> Limitations:
> 
> - We'll use our free time to do that. Don't expect big changes in short time
> 
> - We know about morph, but our initials are not DI, AR, JM or AK. So we
> need support from the community
> 
> - We don't want a signed contract, but a small warranty that our work will
> be used could motivate us
> 
> 
> Questions:
> 
> - How the community consider using Traits?  Could be a good point to test
> the Trait concept, but if in the short future we decide Traits are not the
> way to go we'll waste a lot of effort.
> 
> - Guys at Bern: What about the stability of the current traits implementation?
> Do you expect too much changes?
> 
> 
> Cheers,
> 
> Diego Gomez Deck
> 
> 
> [1] We=German Morales, Jose Laiolo, Diego Gomez Deck and probably some
> others