> Right... How about this:
>
> 1. Packages are always owned by ONE account. That person is the
> maintainer.
> 2. The maintainer can mark the package as "orphaned" meaning that it is
> free to "pick up" by another account. This would solve the issue Doug
> mentioned.
> 3. The maintainer can add other accounts as "co-maintainers". I am
> actually not sure though why this would be useful. Colin? Concrete use
> cases?

Well, more than one person might be working on a package. Right now 
it's easy to handle that because each package has its own password. The 
person that registers the package just tells the others what the 
password is. Once we have accounts, though, that won't be a very good 
idea, because you can't have a different password for the other 
packages you maintain.

It's basically the difference betweeen authentication and 
authorization. In the current model, they're basically the same thing: 
once you authenticate yourself as "the maintainer of Package X" you 
have authorization to do all maintenance on that package.

Moving to an account system gives better control over authentication. 
Now people log in to their account, authenticating themselves as a 
specific person. Once we know people's identity we can make more 
community-oriented tools around SM. Great!

But we still need to handle authorization. Now that we know who you 
are, what are you allowed to do?
I was thinking of the SourceForge model, where each project has a 
collection of accounts that are authorized with various roles - admin, 
developer, documenter etc. We probably won't need that kind of 
complexity for quite a while, but we shouldn't have each account be an 
island unto its self, cut off from the rest of the community.

Anyway, use cases. Avi and I develop Monticello together. He and Julian 
develop Seaside. Tim's the maintainer of VMMaker, but John and Andreas 
do quite a bit of work on it too, and there's no reason why they 
shouldn't be allowed to release a new version, if Tim's away or 
whatever. The Guides collectively administer the core image, which will 
gradually become packages. The KCP and MCP teams will hopefully evolve 
into maintainers for the Morphic and Kernel packages.

As our tools - SqueakMap, BFAV, Monticello - get better, I suspect 
we'll begin to collaborate more and more, and packages with multiple 
maintainers will become increasingly common.

Colin