[croquet-dev] Method of adopting public contributions

Hi,

I have been thinking about this for a while, and trying to decide what
would be the best time to present this.  Not being real savvy about
things like that, I decided that it's probably better to just put it
out there and not worry about the timing.  So here it is!

There is currently a PublicContributions repository on the
CroquetSource Monticello server.  One of the conditions for posting
packages there is that they may be considered for adoption into the
main Croquet distribution.  Apparently there is some confusion over
exactly how that should happen.  Here is a little discussion about
methods of adopting public contributions.  This does not address any
part of the decision process, only the method of adoption.

1.  Probably the easiest and most direct way to adopt a public
contribution into the main Croquet distribution would be to just merge
it into the image directly from the PublicContributions repository.
This would be bad because it would destroy the line of control between
unsupported and supported packages, and implicitly bless any future
versions of the public package.

2.  The next easiest way of doing this is to use the Monticello
browser to just select the package on the PublicContributions
repository and copy it to the Contributions repository, as is.  On the
plus side, this makes it easier to track any potential newer versions
on the PublicContributions repository.  If, at some later time, there
is a newer public version of the package available that should be
adopted, it can just be copied over again.

On the minus side, there is no easy way to track required
corresponding changes in other packages, such as menu/navigator item
changes to directly use the new package.

3.  A somewhat more difficult method would be to merge in the package
from the public repository, potentially rename categories and/or
classes, tie together corresponding changes in other packages
(somehow), and save a new "standardized" package in the Contributions
repository.  This might improve the integration of the package in the
standard distribution, but would definitely separate it from potential
new versions from the public and make it more difficult to track
changes.

I can see a similar set of methods eventually for content files, such
as new meshes, textures, and so forth, although there are additional
"in-world" methods too.

Being a part of the public community for Croquet, I am in favor of
using method 2.

One of the main considerations for adopting public packages into the
main distribution would have to be one of support.  By adopting such a
package, the core team is basically also assuming ongoing support
responsibilites for that package, which I am sure they don't really
want unless the package is exceptional.

There is also the question of ongoing development.  If a package
originated as a public contribution, there is a fair possibility that
further development will come from that community as well.  And there
is also the possibility that further development will come from within
the core team, which might be a reason for using method 3 above.

I would guess that the line between the Croquet core technology
framework and the supplied example/demo applications plays into this
too.  Sometimes I wish that line was drawn with a wider nib, maybe
colored red for greater visibility.

Unless new releases of the main Croquet distribution are treated
strictly as "here and now" images, where various contained packages
may come and go from release to release with no particular promise of
ongoing support, I would guess that there will be extremely few
adopted public contributions.  And I guess I lied about not addressing
the decision process.

Comments?  Suggestions?