Since we want to start making the image smaller, this requires we find a
way to refactor things in it so that they can be easily removed. Since
we want this valuable functionality we've accumulated over the years to
keep working and be available for those that need it, we can't just rip
it out. Here's a little analysis of how we could do this with minimal
pain.

I've looked at Colins changes to PWS to remove it. They're a very good
example, because they're done well, PWS is not a very complicated
example (try to remove Etoys...), and it touches a sensitive spot we
should be aware of.

Here's a summary of what Colins changes include (let me know if I omit
something important):

The file PWSRemoval -
1. Removes references to rendering HTML from (the static version of) the
FileList.
2. Removes references to PWS from discard methods in SystemDictionary 
3. Removes all PWS related classes.

The file PWS.st prepares the ground -
1. Separate PWS into layers - it moves classes to new system categories
for PWS-Kernel, -Swiki and -Actions.
2. Move the method FileList>>renderFile into the method category called
*pws (which is the DVS convention to mark the method as a class
extension by the package PWS).

What is good?
1. PWS.st makes the image cleaner right now if we load it, and the
separation between it and the rest of the image explicit.
2. PWSRemoval does leave us without it and unbroken.

What is less good?
1. PWS.st leaves a call to the method #renderFile in the the method
#fullFileListMenu:shifted:. So the dependency is made somewhat explicit,
but not cleaned up completely.
2. PWSRemoval needs to modify methods, not just remove classes and
registrations. This requires the modified version of
#itemsForFileEnding: to be maintained whenever a new package adds a
handler for a new file ending.
3. No two packages that modify #itemsForFileEnding: will be able to be
loaded together properly at the same time, because each has it's own
version that doesn't know of the other.

How to fix this, and make your refactoring acceptable?
1. First fix the hard coded references, so the package only registers in
various places, and doesn't show up in code. In this specific case, this
should be already almost done in 3.4a, because the FileList there is
dynamic.
2. Then create a change set that clearly bounds the code of the package.
This can include renamed/new system categories, and declaring methods in
other classes DVS style class extensions.
3. Make sure no existing functionality is broken in and out of the
package, when it is loaded.
4. Make sure everything that used to rely on a package but doesn't have
to and remains behind in the image works without it, and without any
changes at all.

Then the process for removing a package will be:
1. Contributor posts changesets.
2. Community+Guides review, test, and include refactorings in image.
3. After some testing, and sometime for the package maintainership to
move to SM, the removal script is made into an update.

This should let us clean and shrink the image, while making it more
general and flexible so packages don't conflict in it, and while not
dropping broken surprises on the people that might be relying on a
package.

Daniel