Uru Code Release - Partial

Request: Proposal To Offer Fan Assistance To Cyan Worlds For Uru Operations

Moderator: MOUL Project Managers

User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Uru Code Release - Partial

Post by Nalates » Wed Apr 14, 2010 1:05 am

I just saw on GoMaand MOULwhere Chogon released some fo the code.

He also requested help sorting out the change approval process.

Some of the predictable sticking points are coming up. Something about Ivory Tower Guilds... Whatever...

While I may look through the code, I doubt I'll be submitting code for approval. I also have a bias... so I may be more bystander to the debate than a contributor. Check it out.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah

User avatar
Mac_Fife
Member
Posts: 1229
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Uru Code Release - Partial

Post by Mac_Fife » Wed Apr 14, 2010 7:06 am

The last I saw in the MOUL thread before going to bed last night was a trend of posts promoting either Cyan or "neutral" hosted services over use of Guilds.

The initial question seems to be about the "how" of carrying out peer review and QC, and I guess it's probably best if the assessors are people who do not expect to be "submitters" in the forseeable future, just for avoidance of any conflict of interest.

I'm also inclined to think that assessors may need to be anonymous - I can see the potential for some personality issues to get in the way otherwise.
Mac_Fife
OpenUru.org wiki wrangler

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: Uru Code Release - Partial

Post by Christian Walther » Wed Apr 14, 2010 1:09 pm

Is it still peer review if it is restricted to a group of selected (in whatever way) “assessors”?

Can we afford to exclude those from reviewing that would be most qualified for it? I expect a high overlap between “qualified people” and “submitters”.

It seems to me that the appropriate procedure for an open-source project would be that everyone can review and comment, and whose feedback is taken more seriously is based on whether they are a valued contributor, an unknown, or a known troublemaker.

But if the premise is that there are “assessors”, then I agree.

User avatar
JWPlatt
Member
Posts: 1100
Joined: Sun Dec 07, 2008 7:32 pm
Location: Everywhere, all at once

Re: Uru Code Release - Partial

Post by JWPlatt » Wed Apr 14, 2010 1:18 pm

This may be an issue but only until shards are licensed and legally able to operate publicly. At that point, testing, peer review and competition are unrestrained. Take the KI for example. For now someone's new KI would have to be approved and installed by Cyan on their MOULagain shard. And Cyan would probably like us to select one or give them a few to choose from - like a Liaison; everyone's concern. That's where the heat is coming from now. But if it's truly an open source project anyone can operate, there can be many KI skins or a plugins produced and tested on various shards. Like any free market, the victor is the one accepted by the most people as good and reputable. Anyone can build, test and implement. And Cyan has a market to choose from.
Perfect speed is being there.

User avatar
Mac_Fife
Member
Posts: 1229
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Uru Code Release - Partial

Post by Mac_Fife » Wed Apr 14, 2010 3:09 pm

Christian Walther wrote:Is it still peer review if it is restricted to a group of selected (in whatever way) “assessors”?
No, it isn't, but as JW notes, this is primarily an issue for the Cyan hosted shard: The question on the MOUL forums comes about because Cyan would like to get some fan created material on the shard, but aren't in the position to expend the effort to go through all the normal QA activities themselves. So they're looking for suggestions. I don't think they'd tolerate a free-for-all, so I'm anticipating that there has to be some sort of initial screening to get a short list of submitted material, and then a more open evaluation of the candidates thereafter. But the question then comes back to who does the screening? And who chooses the people doing the screening?

For the general case, you probably need to have two types of reviewer/assessor: The technical/developer type who can look at the design and say "Yeah, that works" or "If you go that route now, you're storing trouble for later" and the non-techy user who can say "this one is easier to use than that one", "I don't like how this looks", etc. The former is probably a "peer review" in the strict sense, but latter is more a vox populus, but is important as I know from experience that developers can become focussed on providing the technical solution and may miss the usability issues (we have a massive database application in my office that is horrible to use but you can tell from the UI that the programmers have been mapping it to the OO structure in the database rather than how people actually need to work). So the issue I see with the typical OS project is that it's primarily tech people that will review and comment on submissions, since they're more likely to be able to pull things from SVN repositories and rebuild the executables.

Since we're currently talking about the KI interface source releases, the user perception there probably carries more weight than it would with, say, a server side change.
Mac_Fife
OpenUru.org wiki wrangler

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: Uru Code Release - Partial

Post by Christian Walther » Wed Apr 14, 2010 8:00 pm

I guess what I still have trouble wrapping my head around is why the process used to get KI modifications into MOULa now should be different from the open-source development process used down the road. Why would Cyan want to get user contributions into MOULa before enabling the open-source process and having a market to choose from? That’s just more work for them, resulting in slower progress. Why put some proto-open-source process in place, with selected reviewers and all the ugliness that ensues? Opening the source completely is still the often-reiterated goal, so why not do that first (taking as much time as it needs), then everything else gets easier?

I fully agree about the need to have users, not just developers, among the reviewers. One more reason not to limit participation. I didn’t mean to exclude those when talking about “valued contributors” – user feedback is a contribution too.

Tai'lahr
Member
Posts: 233
Joined: Sat Dec 06, 2008 6:33 pm

Re: Uru Code Release - Partial

Post by Tai'lahr » Wed Apr 14, 2010 8:21 pm

Mac_Fife wrote:The initial question seems to be about the "how" of carrying out peer review and QC, and I guess it's probably best if the assessors are people who do not expect to be "submitters" in the forseeable future, just for avoidance of any conflict of interest.

I'm also inclined to think that assessors may need to be anonymous - I can see the potential for some personality issues to get in the way otherwise.
What do you think about flipping that around and have the Project Creators be anonymous? They could give their project a name and then submit it to a trustworthy administrator who would then post it under the project name. Then, the project would be judged on its merits and not the rep of the creator.

The creator could participate in the discussion and even address concerns as long as they didn't reveal themselves as the creator. Once a project is accepted by Cyan, the creator could be revealed. This route would also address your first point and allow assessors to be submitters, too.

P.S. Think maybe this thread should be renamed "Peer Review Process" or something along those lines?

User avatar
Mac_Fife
Member
Posts: 1229
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Uru Code Release - Partial

Post by Mac_Fife » Wed Apr 14, 2010 8:52 pm

Tai'lahr wrote:What do you think about flipping that around and have the Project Creators be anonymous? They could give their project a name and then submit it to a trustworthy administrator who would then post it under the project name. Then, the project would be judged on its merits and not the rep of the creator.
Probably a good idea, but I'd say you do that and keep any assessors anonymous.
Christian Walther wrote:I guess what I still have trouble wrapping my head around is why the process used to get KI modifications into MOULa now should be different from the open-source development process used down the road. Why would Cyan want to get user contributions into MOULa before enabling the open-source process and having a market to choose from?
I don't imagine Cyan think it's ideal either but I'm guessing that they're feeling the need to satisfy a couple of "wants":
- People want to see something new
- Some of the fan devs want to be contributing
I'm guessing that Cyan are working as fast as they reasonably can to get things ready for Open Source, but are maybe recognizing that getting fully there is still going to take a very long time, and "the natives are getting restless", so they had find things to hand out piecemeal. But I think that kind of delivery was implied in the original Open Source announcement anyway. I always felt that MOULa was launched as a kind of test bed to see if code was actually ready to handed out for Open Source, and it still feels like that to me. Or maybe they still want to run something in the interim along the line of the MORE model.
Mac_Fife
OpenUru.org wiki wrangler

User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Uru Code Release - Partial

Post by Nalates » Thu Apr 15, 2010 3:27 am

...Cyan gives me the impression of a parent not wanting to give up a child... Eventually it happens.

Not having a test system seems the most backward to me. If we write code and no one can really try it, most of the fans can't know if it is a good or bad thing. It also seems rather awkward to debug things.

Without a license... we don't know what we can do. I think that limits who wants to go ahead. Without having the people that actually will do the work, how we will decide to structure the process seems speculation. The MOUL thread does some good speculating and from a programmers perspective it is probably what needs to happen. I think it over looks the kids, novice, and amateur programmers that have no clue what version control is about. That seems to add fuel the exclusivity and elitist claims... but to get anything done it may need to be run by professional programmers. We may have to live with lots of people unhappy about any selection process.

Whatever the case and PR problems... those doing the work have the control. With a code revision system someone is going to have to be in charge. I think whoever does the work and sets it up will be the one that controls it. Since the community has social ...divisions... I doubt everyone will be happy with any one solution. So, we will have several... a few... may be a couple of three... Those will be in addition to Cyan's main trunk they have said they want to maintain.

For me I think the vote will happen by people working in one system or the other. We will work with whoever makes a more usable and friendly system. How much the manager listens to the community and implements various suggestions is up to the manager. We won't really get to TELL them what to do. But we can choose where we work or start our own trunk. At least that works for me.

Cyan can pick and choose from what fan's are supplying. That Cyan wants a 'selection' or 'approval process' was, I think, too broadly stated. Cyan can decide what they like in an age and they can see the quality of an age, so that should be easy and probably wasn't what Chogon was thinking about. Code is complex and I think that was more their immediate concern. With operational servers where code can be tested, the code process should be pretty objective. A new KI interface works and avoid problems or it doesn't. THAT will take some testing. Without testing it becomes subjective... oh... I think this code is nicely formated... It should work... and the interface is soooo pretty :) ...way too subjective.

When we can run server and client code changes, whether it works or not becomes objective. When fans can visit the server and try new features we can find out what is popular and handy or fun. The subjective stuff can then be evaluated and everyone gets a say.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah

User avatar
JWPlatt
Member
Posts: 1100
Joined: Sun Dec 07, 2008 7:32 pm
Location: Everywhere, all at once

Re: Uru Code Release - Partial

Post by JWPlatt » Thu Apr 15, 2010 4:07 am

Eat_My_Shortz's words about a distributed VCS have merit, especially if Cyan's role is to be minimal. And especially when it's clear that either no one wants to assume control or no one wants others to assume control. We can, for now, use just about any successful open source model out there - MySQL, phpBB, Linux, or whatever - to begin work. And we can used something very basic, like the KI code to get started. There really isn't much at face value about the KI unless Cyan is actually going to commit resources to approve and install the code any time soon. That does seem out of order from providing rights to build test platforms first. Rather, the KI code, or any further code released in bits, can be used to establish the flow of things. A little at first, even ridiculously simplistic, then more. There needs to be a repository or distributed system, and rarified has already set up CI here for anything out there. So we (the community) can just start small and get the machinery moving. When and if Cyan gets some momentum, they can hook in and define their main trunk if they coose to. Looking at it from a distrubuted point of view, there's little need to wait.
Perfect speed is being there.

Locked

Return to “MO:UL”

Who is online

Users browsing this forum: No registered users and 1 guest