It is currently Sat Dec 14, 2019 7:10 pm

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 163 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 11  Next
Author Message
 Post subject:
PostPosted: Tue Apr 13, 2010 8:57 pm 
Offline

Joined: Tue Mar 20, 2007 6:48 pm
Posts: 746
PaladinOfKaos wrote:
DarK wrote:
The guilds are great for IC efforts however I sadly see them as ivory towers and a lot of what goes on in the guilds still seems too old school authority to me.


OK, I have to comment on this. I can't speak about the GoMa, but the GoW is extremely decentralized. We show off projects and share ideas, but there is no central authority to say "you can do this" or "you can't do this". If we (as individuals) think something is a bad idea, we'll certainly say so, but those opinions are not the Guild position.


This is much the same for GoMa. We HAD a ranking system, but it was to reward people for inspecting Ages and participating in the Guild, not determine any kind of privilege. We stopped tracking the ranks shortly after MOUL closed and the elected leadership disbanded a little after that. Now we have Nynaveve in charge of our website/forum and the former leadership are admins on the forum.

On topic, I'm sure the GoMa will be glad to help in anyway we can. :D

_________________
Frisky Badger
Guild of Maintainers
My opinions are my own and not necessarily those of the Guild of Maintainers.
KI# 00140468


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 13, 2010 9:11 pm 
Offline
Obduction Backer

Joined: Mon May 15, 2006 2:02 pm
Posts: 818
Location: Switzerland
There is probably no need for anyone to set up repository hosting – any of the existing DVCS hosting services (Google Code, GitHub, Bitbucket, Launchpad, SourceForge, …) should do the job, once the code is under an open source license. We’ll probably never be able to agree on which VCS to use – choose one, Chogon, and we’ll stick with it.

We need a central place to discuss – I personally prefer mailing lists/newsgroups, but given that web forums are more common in this community, GoW or OpenURU.org look like the obvious choices. There seem to be people with allergies towards either, but hopefully the discussion will naturally concentrate in one place.

Foremost, as others have mentioned, what I am missing as a prerequisite for peer review (and development in general) is the ability to test stuff (without a conversion process that has the potential to create its own problems or mask others). Server binaries so we can run our own servers, some resettable sandboxed servers hosted by Cyan with limited access for developers to insert modified files, whatever.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 13, 2010 9:36 pm 
Offline

Joined: Tue May 09, 2006 1:04 am
Posts: 4134
I agree with BAD, it would probably be best if Cyan set up a "neutral" space otherwise this will get ugly fast.

_________________
-Whilyam
Cavern Link:My IC Blog


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 13, 2010 10:11 pm 
Offline

Joined: Thu Nov 29, 2007 2:02 am
Posts: 683
Location: Wherever my ages take me.
BAD wrote:
Chogon,

It seems that most people want this kind of system as well (peer review), however there currently is no way to review the changes beyond using something to convert the changes to a format that works with the current offline ways to play. Although this basically negates any additions to MOULa until testing servers can be created, perhaps getting the GOW or the GOMa to set up a site where new additions can be seen, explained, and voted upon would be a good start for now.

The structure of such a site won't be an easy thing to get approval of the community at large. Perhaps a better idea would be to find a way to get such a site up in Cyan web space. Therefore no one will question other fans motives.


I really like this idea and completely agree. :)

_________________
KI#46415
KI#80658


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 13, 2010 10:23 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
Whilyam wrote:
I agree with BAD, it would probably be best if Cyan set up a "neutral" space otherwise this will get ugly fast.


So far it’s been civil, and as long as it says like this, some progress can be made...

Chogon wrote:
Obviously, Cyan doesn't have the staff to look at *tons* of changes (such as for the KI, etc.) and apply them to MOULagain. So, fan help is needed!


We are been told here, cyan needs to work with less of us to get more done. I can only imagine that they are getting hounded by many people asking the same question.

If cyan set up a single repo it only solves the "golden" source problem, we are still at a point where a decision needs to be made on what will be submitted to cyan.

So how is that decision going to be made, and by who?

Moving into speculation: Cyan are ok holding the rains for a while, but I think we are been slowly weaned of their support to allow us to be more self sufficient and allow cyan to take more of a back seat.

Small steps...

To sum up so far the suggestions have been:

Cyan set up a "neutral" space for submissions
Guilds to pass submissions
Natural leadership to grow, leaders appear in time who will eventually pass submissions
OpenUru to pass submissions
Chosen Experts to pass submissions from test servers and popularity contest

Yell if I missed your suggestion, or paraphrased you incorrectly.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 13, 2010 11:34 pm 
Offline
Obduction Backer

Joined: Wed May 24, 2006 11:04 pm
Posts: 558
Location: Atlantis
first off no one other then Cyan should have a say in what is or is not good.

as far at the Guilds go they should not have a say in anything at all they are fan run. and as it has been tried before any time you have a fan run group try and say what is right and what is not right there will be a war. as many of the old Until UrU shard admins know too well.

i think Cyan should setup a forum or something with a Rating system where devs can post links to there changes and let all the fans vote on what is good and not good.

_________________
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 1:29 am 
Offline
Obduction Backer

Joined: Wed Dec 13, 2006 9:48 am
Posts: 216
Here are some possible frameworks for peer review. There are probably others, but this is what I thought of on the spot. My preferences are probably apparent from the rather obvious spin I'm putting on each ;)

Fully public test space: Suppose an alternate MOULa shard is running, where (perhaps) GoMa folks integrate new ages and features into the test environment, and the general public can choose to log in and test this content. If the migration of new content from Test to Live is too slow, people will just start playing on the Test shard. In that case, what's the point of the review process, if lots of people are just going to bypass it?

Private test space: Allow a restricted subset of players (regardless of how that subset is selected... perhaps GoMa folks?) to review submitted content. Of course, the problem here is unrest among some folks in the general public for not being "elite" enough to get first crack at the goods. In addition, some content creators may feel that the content approval process is unfair because only certain people wind up being the gatekeepers without necessarily having the credentials and respect to make them worthy of such a position. Yes, it's a somewhat juvenile attitude for people to have, but some folks will have it, and they'll probably be quite vocal about it.

Rotating personnel test space: Anyone who wants to help out with testing is able to apply, and when selected (perhaps randomly), those people serve a short term on the testing squad (e.g., four weeks, with one fourth of the testers being rotated in every week). Future eligibility is dependent upon participation when one's number is called, meaning you would need to file a test report on some number of testing goals; if you failed to live up to your duties, you would be barred from future participation. This prevents the "everyone already saw everything" problem and the "too good for the rest of us" problem as mentioned earlier, but adds considerably to the complexity of the process.

Menial duty test space: Reduce the testing process to something so boring that only truly dedicated people will volunteer. New game engine tweaks get rigorous testing, but test new ages only briefly to ensure no dramatic shortcomings such as gross geometry errors, easily findable stuck avatar issues, missing textures, scripting errors, obscene imagery, that sort of thing. Rubber stamp content that passes a very objective set of criteria. This eliminates the complaints about a potentially unfair subjective approval process, and reduces the number of people interested in the content and the duration that the content appears on the test shard, but probably reduces the quality of content going live.

Private test space with no approval powers: Have a select group of people test new content, but they only provide recommendations to Cyan in the form of a brief report compiled from all of the testers' opinions. Cyan reviews the reports and decides what content to push live. Has the advantage of a decreased sense of unfairness, but places a greater burden on Cyan.

In any case, one additional feature that I think would be important is that the reports generated by testers should be made available to content creators to help them refine their ages. For example, if someone's age is pretty good but just needs a little more polish, or if they have a few big bugs that still need fixed, then the testers' report should point these problems out. In other words, age testing should be a two-way street, not merely an approval process.

On the other hand, game engine modifications should start with a proposal, and most of the tedious approval process should be done up front in the form of discussion and refinement of how the feature should appear in the game. Coding, implementation, and testing would then be a rapidly iterative process until a particular feature can be considered bug-free.

Yeah, those are some scattered thoughts, but hopefully it will give people some ideas to spring off of. :)

_________________
I once followed blindly in Yeesha's footsteps. In retrospect, perhaps I should have taken my own journey instead.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 1:53 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Great. Looks like things are progressing towards open source!

I'll add in my many cents. I do have extensive experience managing code in revision control (but not much experiencing leading projects). There seem to be two threads of discussion above: how code should be managed (ie., revision control, patch submissions, whathaveyou), and who should manage the code (ie., Cyan, guilds, etc).

Distributed VCSes

I'll address the how question first, as I'm a lot more comfortable with technical issues. We definitely should be using a form of DVCS (distributed revision control). This means one of the big three: Bazaar, Mercurial or Git. (My personal preference is Bazaar and I can spend four hours arguing why Bazaar is better than the others, but as nobody ever agrees on this, I say Cyan should pick one and be done with it).

I've worked on large projects with non-distributed and distributed revision control. The DVCS is unarguably a better option for open source. I've worked on Python, for example, which uses SVN and I don't have direct commit access. The process there is terrible: checkout the source, make your patch, submit the patch file to the bug tracker, argue about it, change some more and re-submit the patch file, and so on, until it is finally accepted. This can go on for months, and in the meantime, you can't make any incremental commits, so you find yourself messing around with patch files and it's extremely messy, especially if you are working on several patches at once. Basically only people with commit access get to use revision control, and the rest of us are just working with plain files. Python is moving to Mercurial now due to these issues.

With a DVCS, the process is: checkout the source tree, make a private branch, make your changes (commit incrementally) and when you're ready, push your branch to somewhere public, and make a merge request. While I'm working on my patch, I can commit as many tiny revisions to my branch (which everyone can see, but doesn't become part of Uru just yet). When the time is ready, the maintainer just merges my branch with the mainline (which is a pretty painless process), and then it becomes part of Uru. The DVCS lets me work on as many "branches" locally as I want, at the same time.

I'll use Gwibber as an example of a project managed in the decentralised style (in Bazaar, on Launchpad). See the branch list -- see the trunk, recent releases, and a large number of development branches, most of which aren't ready yet. Anybody who wants to can open up a development branch, without any permission (no need, since it isn't incorporated into the project).

Bug tracker

A little note here -- I've submitted a bunch of bugs to Cyan's request tracker, and I got a reply saying they were entered into the database. It's good that Cyan is tracking bugs, but it would be great if there was a public bug tracker. Bug trackers are often the best management in an open source project (they become more like task trackers, as you add bugs representing feature requests as well). If Cyan provided an open bug tracker, that would be the fastest way to organise the community so we can see exactly what work needs to be done (without duplication), who is planning to do it and how important it is. I would personally be very happy to do bug triage (management of the bug tracker).

Community organisation

Now the process for who is managing these things. I don't know much about the guilds. I see some debate above about which guild should manage this, etc. I'm not really sure if these organisations should have the power to decide what gets accepted. They represent only a small part of the Myst community. I think a better idea is to make the source tree and relevant discussions in a "neutral" place (such as Launchpad, on the Myst forums, or on Cyan's website), so anyone interested in contributing directly can participate, without having to join an intermediate bureaucracy, however thin.

I don't really see the GoW as appropriate. I understand they are there for the writing of new Ages. While they have programmers and so on, I think it's quite a separate goal to be writing Ages than making changes to the engine. As someone who is interested in hacking the engine, but not necessarily writing Ages, I don't think it's appropriate for me to have to join the GoW to participate.

Patch approval process

My idea (at first) (and this is a fairly not-well-thought-out idea) is that initially, Cyan has a say in what's accepted. (After all, they are running the servers so we need them to at least have some part in the process). But we just need to set up the tools so their job is very trivial.

The process for submitting a new change would be:
1. Make the change in a branch somewhere. Either do it locally, or make it public and then a bunch of people can work on the branch together.
2. When the change is ready, make a "merge request". This shows up on the code tracker (e.g., Gwibber's pending reviews on Launchpad). These can then be discussed by the community.
2a. The changes could also be posted to a forum, such as the Open Source Myst Online forums, for discussion by the wider community. This could just be a link back to the code management site.
3. The original author makes changes suggested by the community. (S)he can also invite people to work on the branch as well, so a handful of developers can all work on the branch in public, even though it isn't part of the core Uru code.
4. Once some "trusted developers" approve the branch (usually by community consensus, but we'll have to define what "trusted" means), one of them will merge the branch into the trunk. This means it's playable by the public, but only on special "testing servers".
5. Once Cyan gets a chance to look at it, they can do a mass approval of the code in trunk, and merge it with their "Cyan production" branch -- a special Cyan-approved branch which is a sub-set of the trunk. By accepting code into the "Cyan production" branch, the code then appears on the official Cyan server in the next update.

This "three-step" process allows bad code to be detected before it goes even into testing, but if there's something in testing that turns out to be bad or Cyan doesn't like, it can be caught before it goes onto the production server. This is a fairly standard setup for web applications.

I understand that I'm just a little voice in the big wheel that is Uru. I'm not trying to run things, just offer some mostly-technical advice. I'd be happy to lend a hand in setting up these systems and processes. I think above all, it is crucial that a) it is very easy for anyone to submit their ideas and patches, without having to go through a lot of bureaucracy, and b) the community is very cautious about accepting these ideas. We want to see improvement in Uru, but we don't want it going off the rails and breaking things all over the place.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 1:58 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Dachannien wrote:
In any case, one additional feature that I think would be important is that the reports generated by testers should be made available to content creators to help them refine their ages. For example, if someone's age is pretty good but just needs a little more polish, or if they have a few big bugs that still need fixed, then the testers' report should point these problems out. In other words, age testing should be a two-way street, not merely an approval process.

I agree, but I think we need to keep fan Ages separated from core engine development.

Have the GoW manage fan Ages (including bugs and so on), but manage core engine development in a different space.

Dachannien wrote:
On the other hand, game engine modifications should start with a proposal, and most of the tedious approval process should be done up front in the form of discussion and refinement of how the feature should appear in the game. Coding, implementation, and testing would then be a rapidly iterative process until a particular feature can be considered bug-free.

Yep, I agree with this too. As I wrote in my post just above, I think the bug tracker is key here. A new feature starts with a bug report (tagged "feature request"). This allows discussion about the merits of the change before development even begins. The bug tracker can be linked with a public branch so people following the bug can also follow the code going into the branch.

The bug tracker is just like a forum, but with extra metadata for categorising and prioritising bugs, as well as linking it with individuals and branches which are working on the bug.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 3:53 am 
Offline

Joined: Thu May 11, 2006 5:22 pm
Posts: 1814
Location: California
Christian Walther wrote:
We need a central place to discuss – I personally prefer mailing lists/newsgroups, but given that web forums are more common in this community, GoW or OpenURU.org look like the obvious choices. There seem to be people with allergies towards either, but hopefully the discussion will naturally concentrate in one place.

I’m a great believer in consolidating information. However, a discussion on that subject in regard to manuals, code, discussions, and wiki information on OpenUru.org pointed out the pitfalls of having all the eggs in a basket. A forum controlled by a single person or group can be a problem if that person or group runs into problems.

Also, the social interactions have made some number of people unhappy with one or the other forum. Duplicating or having similar information on the two sites may not be that much of a problem and may offer benefits, such as giving people different groups to work with.

Whilyam wrote:
I agree with BAD, it would probably be best if Cyan set up a "neutral" space otherwise this will get ugly fast.

People certainly have the ability to turn things ugly. Whether that is allowed to happen will depend on the various forum admins and moderators. Also, the fans will have a large say. We have discussed what a number of possible options are to prevent or at least mitigate the problems we have seen in the past at Standards for Debate & Discussion. Now it is a matter of how many people pick up on the ideas and begin to use them.

Regardless of what fans or admin/moderators do Cyan is not going to have the resources to run a neutral play ground. Insisting Cyan do so; means that we are likely to slow this whole process. If the community takes on running the test servers and maintaining order, we can probably move pretty fast. I see it a matter of whether the fans will play nice and whether the fans will take action against those that don’t.

Cyan Control
This keeps coming up and Cyan keeps saying they don’t have the manpower. Seems like a settled point.

However, Cyan has said from the start, they will run a primary code base/trunk. I have yet to hear that they are not going to do that.
It would seem the fans need to decide how they are going to control their FAN made code revisions and additions. If we have a revision in a version control trunk separate from Cyan’s we can work on it at our pace independent of Cyan’s. Also, independent of approval processes. We will get to see all the creative ideas people have. From all those some process will decide what makes it into the main code trunk. Neat things that shard operators like can be added to fan run shards.

The idea that everything has to be created inside a single Cyan controlled code base just complicates the process. If a KI mod is created at GoW, another at OU, and another at GoMa fans can comment, Cyan can see the various ideas, comments, and fan reactions, as we all can, and decide which they want to adopt to the main code base they control. That should greatly reduce the interaction that Cyan has to engage in.

Plus whether we adopt this multiple independent code thread model or not, fans will engage in it.

Also, putting age builders through the same process we put code through seems to be overkill.

Test Servers
I can’t see anything serious getting done without some way to test. With fan run testing units we do not have to depend on Cyan. Please submit form 1022-A97rev697 in quadruplicate to the non-entity of unassociated former guild persons formerly known as DRC... or whatever...

Bad ideas, unexpected affects, inefficient code, and other problems are unlikely to be weeded out as well without a test system. With independent test systems we can run them at home (hopefully) and save everyone a ton of work. We can load up and test on demand. Otherwise we are going to beg for server time, hassle with getting age packages together, operator approval and cooperation… the more people and steps the longer it takes and the less testing iterations can be completed in a given time.

Seems we should be making this as painless as possible in the initial stages and work up to approval and inclusions as things are refined. Dachannien and Eat_My_Shortz have the plan many software projects follow. It’s good. I just see it as too top heavy for fans until code is ready to move to the Cyan trunk.

Test at home and get the dumb mistakes out. When one is ready for public testing move up to a fan run test station, i.e., GoW, GoMa, OU… When things are working and tested then move up to the approval process for addition to the current revision fork.

Andy is doing 3DMax tutorials now. But how does he or anyone test for MOULa? Convert from 3DMax to Bender to CC… and then wonder if the mistake that has the waves moving backward is in 3DMax, the Plasma export, the Blender conversion, in PyPRP, or is some quirk of CC? We need a MOULa test lab.

_________________
Nalates - GoC - 418 - MOULa I: Nal KI#00 083 543, MOULa II: KI#00 583 875Nalates 111451 - Second Life: Nalates Urriah
Guild of Cartographers Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 4:57 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Nalates wrote:
Regardless of what fans or admin/moderators do Cyan is not going to have the resources to run a neutral play ground. Insisting Cyan do so; means that we are likely to slow this whole process.

Yes. So out of the three options: a) Some Myst sub-community runs everything, b) Cyan runs everything and c) Put it on a generic open source hosting site (Launchpad, Google Code, GitHub, etc), the third option seems desirable.

A service like Launchpad gets you bug trackers (with discussion), code hosting, releases and automated builds. That can be a centralised place to organise the development. Then we just need a community to run the testing servers.

Nalates wrote:
If a KI mod is created at GoW, another at OU, and another at GoMa fans can comment, Cyan can see the various ideas, comments, and fan reactions, as we all can, and decide which they want to adopt to the main code base they control. That should greatly reduce the interaction that Cyan has to engage in.

I entirely agree. But I'll state again that I think the way this should go is that these mods should appear as branches in a DVCS, and posted to a centralised place for review (like the Gwibber example I showed above). As opposed to having these mods show up on all the various message boards all over the web.

Nalates wrote:
Also, putting age builders through the same process we put code through seems to be overkill.

I think we need a completely separate process for fan ages than for Uru engine code.

Nalates wrote:
Seems we should be making this as painless as possible in the initial stages and work up to approval and inclusions as things are refined. Dachannien and Eat_My_Shortz have the plan many software projects follow. It’s good. I just see it as too top heavy for fans until code is ready to move to the Cyan trunk.

Test at home and get the dumb mistakes out. When one is ready for public testing move up to a fan run test station, i.e., GoW, GoMa, OU… When things are working and tested then move up to the approval process for addition to the current revision fork.

I disagree with this. It seems to reflect the old view of revision control ("get everything ready, then when it's perfect, commit!"). The DVCS view is that everything should be under revision control, right from the start. The first change you make along the way, even if nobody has reviewed it or you're unsure if it will work, should be committed, so you have a) a permanent archive of the work going on, and b) a place to show people your work without having to post patches as attachments to bug reports or forum threads. Importantly, just because something is committed does not mean it has been accepted, not even by its original author (so "commit" is probably the wrong word). It all depends what branch something is committed to.

In other words, I agree with the above quote (work at home and test it out, push it up to a fan test station, then get approved for the current trunk, and finally get Cyan approval), except that I am saying it should be in revision control at all times, and those four "phases" are merely merges into more and more "official" branches.

I think I know what you mean by "top heavy" -- too much process. I used to think that way, but once you've used DVCSes, you realise that they relieve processes, rather than adding to them. You commit early to make it possible to merge later, rather than do patch-hell early (much more work than committing) and a huge commit later (much more work than merging).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:32 am 
Offline
Obduction Backer

Joined: Mon May 15, 2006 2:02 pm
Posts: 818
Location: Switzerland
MercAngel wrote:
first off no one other then Cyan should have a say in what is or is not good.

as far at the Guilds go they should not have a say in anything at all they are fan run.

Eat_My_Shortz wrote:
As someone who is interested in hacking the engine, but not necessarily writing Ages, I don't think it's appropriate for me to have to join the GoW to participate.

Why do people keep thinking of the guilds as some sort of humongous entities that have any kind of power or authority of their own? The guilds are nothing more than groups of individuals that congregate in one place because they like to do and talk about the same things. At least the GoW and (to my knowledge) GoMa are. If an individual considers themselves a member of a guild, that doesn’t give them more say in anything. The only way to have people grant you a say in their matters is to build a reputation by contributing.

There is no such thing as “join the GoW” (unless you count registering an account on the GoW forum as such). The GoW has a very loose concept of membership – basically you are a member if you consider yourself one, and being a member doesn’t gain you anything.

When I suggest the GoW (more accurately, the GoW forum) as a suitable place for discussing open source Uru development, that is solely because many of the people likely to take part in such discussions are already there.


Nalates wrote:
I’m a great believer in consolidating information. However, a discussion on that subject in regard to manuals, code, discussions, and wiki information on OpenUru.org pointed out the pitfalls of having all the eggs in a basket. A forum controlled by a single person or group can be a problem if that person or group runs into problems.

A problem that would be neatly solved by using mailing lists/newsgroups instead of web forums. (Though forums that have working RSS/Atom feeds, like OpenURU.org, are better than nothing.)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 10:05 am 
Offline

Joined: Tue May 09, 2006 2:10 am
Posts: 372
As former staff of the GOW I can assure everyone here that the GOW does not have any stigma or membership criteria to meet. You are a member just by joining the forum or just claiming you are. What ever hierarchy that may exist there is purely based on ability and overall respect within the entire Uru community and means absolutely nothing to any other member of the GOW.

The GOW has always been a loose affiliation of like minded creators and it intends to be that way for the entirety of it's existence. Any differing description of the group should be disregarded.

Enough of that.

I do not believe that any current fan group should run anything for Cyan. I think that Cyan should hire* fans (or hey, how bout some outsiders) to work on a site within Cyan's web space that easily allows fans to see, read about, and vote on fan made additions to Uru's source. Those that receive a lot of positive votes (or however they figure out it to work) can be considered for Cyan to add to MOULa.

I know that that is a big generalization, but I think it's important we all get on the same page early on to avoid the typical outrage and arguments.

*Hire meaning they should get stuff done for free, really cheaply, or for college credit.


PS: EMS, has hit it on the head I believe.

_________________
BAD is as good as BAD can be.

Visit our new site!

SOUP!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 10:54 am 
Offline

Joined: Wed Apr 14, 2010 10:36 am
Posts: 1
Being an avid World of Warcraft player, I noticed something that Blizzard was very keen on doing when it came to fan created mods for WoW. They would look at the community as a whole, seeing what mods were used the most by the community (which is easy to discern via download and usage statistics presented on the mod websites). Every major patch, they would take what everyone had been using the most of, and integrate it into the core User Interface for WoW.

Example: During the first months of WoW, additional hotkey action bars were only available through third party UI mods. Then one of the major patches came out, introducing the capability for non-modified UI's to enable additional hotkey bars.

Granted, Cyan by no stretch of the imagination has the resources that Blizzard does. But, the mechanism for selecting primary trunk modifications can be borrowed to suit the needs of a smaller head-company, and just as voracious fan-base.

In this case, a website is created to house all of the fan-made mods. It becomes a repository for all of the content that we've made, in much the same way that PlanetQuake was first built up. New models, animations, ages, etc. This allows the group of adventurous explorers (us) to see what's out there, and utilize these mods for single player exploration, or in the case of shard owners, what they want to host on their servers.

From there, the site begins to gather up usage statistics; Views, downloads, comments, ratings. This in turn helps the community see what mods everyone is playing, while also still giving lesser-played mods the ability to be used. Likewise, it'll give Cyan a clear-cut means of viewing what the fans are clamoring for the most, and consider bringing it into the fold, so to speak.

Then, when it's time for a particular mod or set of mods to be added to the main trunk of Uru, Cyan can work with the creators of the content on an intimate level, there by making the community as a whole, that much tighter. It will also serve not to push out small teams, or even solo-content creators, because the repository website won't discriminate against the actual creator size, and Cyan won't really care.

Ultimately, it also serves to fulfill the concept of Open Source, where in the community itself is deciding, rather than a core group of individuals who may or may not have any idea what they're actually trying to accomplish.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 1:21 pm 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
The problem with this "mods" approach is that it only really works for client-side stuff (like UI). Granted, we can do a lot of work on the client-side. But Cyan is also planning to release the server code, and that's where a lot of core changes will be made. You can't have server code in a "mod" for people to "try out".

Well, kind of. People can't choose to try it out. But you can have "custom servers" which people can log into to try out server-side modifications. In any case, that's a lot more work to set up. I imagine at least the server-side changes would be added in a more centralised model (they are submitted, trialled on testing servers, then either accepted or rejected).

(Though given what I've been told on the "Ki Source" thread, apparently a lot of the client-side code is actually server-side as well, and transferred to the client on login, so it might be harder to install mods than it would seem as well.)

Christian Walther wrote:
At least the GoW and (to my knowledge) GoMa are. If an individual considers themselves a member of a guild, that doesn’t give them more say in anything. The only way to have people grant you a say in their matters is to build a reputation by contributing.

Right. So there are a bunch of people (I guess me included) here saying "we shouldn't entrust this to the guilds because they are an exclusive bunch". At least that's the impression people are getting. Well ... OK. That isn't really my stance.

My attitude is that these are sub-communities. I'm sure if I went over to GoW I could get an account and start "being a member" right away. i.e., there's no "membership test" to get in. However, that's still a barrier to entry. You hit the nail on the head when you said "The only way to have people grant you a say in their matters is to build a reputation by contributing". See, I have somewhat of a reputation here, on the official Myst forums, because I've been around awhile. I do not have a reputation in the GoW, or any other guild, because I don't participate in those sub-communities. So my point is, the guilds shouldn't get to say what goes in, or get to manage the codebase, because then the decisions will be biased in favour of those sub-communities. It should instead be in some "neutral" space such as the Myst official forums, or the Cyan site, or Launchpad.

Having the guilds or other fan sites manage testing servers and so on, however, would be great.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 163 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 11  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: