This is a general proposal. Lots of little details need to be worked out still, but I feel it's a solid framework for how we can handle the content in a mostly-organized fashion.

The first question is how to host the files. Unlike the textual source files, the binary Max files cannot be merged. Because of this restriction, a centralized RCS that supports file locking is the only real option. Additionally, it must have some sort of semi-friendly GUI for the artists to interact with. Subversion immediately comes to mind as fitting all of these requirements.

The other aspect is the question of who has commit access. Because we're dealing with binary files, we cannot accept patches. We must find some other way of vetting contributors before giving them access to the Max files. Portfolios are the obvious solution here. We should not be requiring everyone involved to be able to produce a Cyan-quality age all on their own; rather we should be looking for their skill in whatever they wish to work on. So if someone wants to work on improving physicals we shouldn't care if they're bad at lighting. Likewise an animator shouldn't be required to demonstrate good texturing skills.

Initially, these contributors will have to be vetted by some sort of selection committee. Eventually good artists who have shown an eye for handling Cyan-style content will be promoted to the management group. Once there are enough artists there, the initial non-artist committee should step down, unless the artists prefer to have them remain as advisers.

In cases where something not up to standards does get committed, it will just have to be reverted and the offender can be warned and/or be stripped of commit privileges as deemed appropriate by the repository managers.

And finally: because the talent and target audience for these files are somewhat clustered there, we feel the GoW should be involved in the initial oversight of the Max repository. We have no objections to sharing that role, but we don't think it's unreasonable to want a leadership position here.

We already have Subversion repositories here for a number of things (most of the OpenUru.org site code, styling, etc., is in SVN). The actual mechanics of how submissions are handled will need a bit of thought; what the "workflow" is, etc. Maybe rarified will have some ideas on how repos could be "staged" to provide a kind of buffered pipeline to make it easy enough to submit a contribution for vetting, without creating a huge management burden in moving in on into an "accepted" store.

I'd agree that supporting a cross-disciplinary approach is desirable. That is how I always assumed that age development work would go in an Open Source environment (but I also know a few age creators who will say that they can do everything by themselves, thank you very much, and I wouldn't argue with them). Maybe a bombastic approach might be to create an "in-work" repo for each age, cloned from a master then allow a designated team exclusive commit access to that repo, then clone back to the master once the work is "approved." That way you could potentially allow more than one group to work on their own "version", and then choose the best result.

Whatever is done, you need stay wary of the perception of creating a "closed shop", an elitist clicque of "approved artists", and remain open to allowing new artists to offer their contributions (to a large degree that was the grumble I had about Cyan's original MORE proposal - it seemed to be promoting that kind of clicque).

I'd guess that it should be possible to form a pretty fair and representative volunteer interim selection/management committee from the known artists and developers, if the role and scope are reasonably well explained, and undoubtedly that means they'd mostly come from GoW. I'd just say that it shouldn't be exclusively GoW people. Maybe there's scope for people from GoMa too (OK, that's beginning to sound like MORE-II, but maybe in a way it is). If the age to be evaluated can be put into a "rehearsal" shard so it can be play-tested then you could also involve "established" fans that are not actually artists but "know what's what" in Uru.

If we're ultimately talking about an OU hosted repo at the core of this then OU would have overall "ownership" of the repo, but I'd see it probably being like any of the other OU hosted projects we've had here: They're by and large independant of and autonomous from OpenUru itself, with thier own management. In fact, about a year ago, Nye_Sigismund started his OSCAR (Open Source Creation And Restoration) project here with vaguely similar sounding aims, but directed more at age creation rather working on Cyan's material. Maybe there are synergies there.

Mac_Fife wrote:We already have Subversion repositories here for a number of things (most of the OpenUru.org site code, styling, etc., is in SVN). The actual mechanics of how submissions are handled will need a bit of thought; what the "workflow" is, etc. Maybe rarified will have some ideas on how repos could be "staged" to provide a kind of buffered pipeline to make it easy enough to submit a contribution for vetting, without creating a huge management burden in moving in on into an "accepted" store.

We can't really get commit-level granularity staging, we can at best get file-level. That may be worthwhile for two reasons (and maybe more, but these ones jump to mind): It gives artists an opportunity to fix anything that's not up to standard, and it lets multi-discipline features that require more than one contributor be kept out of the main repo until they're complete.

I think as far as dealing with "unstable" vs "stable", we're going to have to implement feature freezes and other commit protocols. They're lame and outdated in our dvcs world, but unfortunately we just don't have that sort of flexibility when dealing with binary files on subversion.

Mac_Fife wrote:Maybe a bombastic approach might be to create an "in-work" repo for each age, cloned from a master then allow a designated team exclusive commit access to that repo, then clone back to the master once the work is "approved." That way you could potentially allow more than one group to work on their own "version", and then choose the best result.

SVN already has locking. Given that teams for a given feature will probably never be larger than two or three people, this seems like it's making managers do what Subversion does for us. As long as incomplete features are only committed to the staging repo, I don't see this as being necessary.

It would be good for the management group to say "we need X and Y and Z done on this age" and ask for volunteers, but I think that can be properly handled through people skills and the staging repo rather than through additional complexity.

Mac_Fife wrote:Whatever is done, you need stay wary of the perception of creating a "closed shop", an elitist clicque of "approved artists", and remain open to allowing new artists to offer their contributions (to a large degree that was the grumble I had about Cyan's original MORE proposal - it seemed to be promoting that kind of clicque).

I agree we want to foster the feeling that people can join, but we also need to make sure we really do only accept the artists who are going to make good contributions. Nothing will kill the fan support for open-source faster than watching the quality of Cyan's ages degrade. It's a very careful balance, and we'll likely have to work it out as we go.

Mac_Fife wrote:I'd guess that it should be possible to form a pretty fair and representative volunteer interim selection/management committee from the known artists and developers, if the role and scope are reasonably well explained, and undoubtedly that means they'd mostly come from GoW. I'd just say that it shouldn't be exclusively GoW people. Maybe there's scope for people from GoMa too (OK, that's beginning to sound like MORE-II, but maybe in a way it is). If the age to be evaluated can be put into a "rehearsal" shard so it can be play-tested then you could also involve "established" fans that are not actually artists but "know what's what" in Uru.

I don't know how much of the GoMa is left . But I agree we should try to involve a good section of the community. A rehearsal shard is a very good idea - I'm sure Minkata or Gehn (or both) could fill that role.

Sounds good, although it sounds a bit too artist-centered to me. Maybe it’s my skepticism of making artistic changes to Cyan’s work, or my expectation that Cyan will be skeptical of it as well, but to me technical changes seem a more important use case – things like adjusting colliders, enlarging text fields to accommodate longer localizations, properly sorting the layers of the big KI to fix their X-raying, adjusting things to improved engine capabilities.

There will also need to be some rules about how long one can hold a file lock: If I announce that I’m going to do XY, need to make changes to files A and B for it, and expect to be done in a week, what happens when I go MIA, am still not done after three weeks, and someone else wants to work on those files? Obviously sooner or later my lock will have to be broken. Clear rules about when that happens could avoid bad blood.

Christian Walther wrote:Sounds good, although it sounds a bit too artist-centered to me. Maybe it’s my skepticism of making artistic changes to Cyan’s work, or my expectation that Cyan will be skeptical of it as well, but to me technical changes seem a more important use case – things like adjusting colliders, enlarging text fields to accommodate longer localizations, properly sorting the layers of the big KI to fix their X-raying, adjusting things to improved engine capabilities.

Definitely a lot of the initial work will be to wiring. But there are areas where engine improvements will require artist intervention - updated graphics pipelines come to mind as one of our long-term goals there. Plus there are places where Cyan really did just do a bad job and letting some artists with free time touch things up can only help.

Christian Walther wrote:There will also need to be some rules about how long one can hold a file lock: If I announce that I’m going to do XY, need to make changes to files A and B for it, and expect to be done in a week, what happens when I go MIA, am still not done after three weeks, and someone else wants to work on those files? Obviously sooner or later my lock will have to be broken. Clear rules about when that happens could avoid bad blood.