It is currently Sat Nov 16, 2019 9:42 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 ... 6, 7, 8, 9, 10, 11  Next
Author Message
 Post subject:
PostPosted: Sat Apr 17, 2010 10:12 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
This is getting beyond farcical!

The topic is how do we veto and submit changes to cyan; this is talking about actual systems.

It is not about what we allow and what we exclude with the veto,

It’s just how do we set that system in place, we can decide the particulars of the veto later on.

It is just pure and simple, how we move data from developer to cyan,

Whilyam wrote:
DarK wrote:
Guess it’s time to hit your panic button.
Whilyam wrote:
I find no sense in yours.

It was highly insensitive to people who have been well known in this community and have passed on, I am sure in actual face to face conversation you would not have said that to someone you have only a passing knowledge of.

It's insensitive to mention that people died? Sorry, it's the truth. The game has been around for somewhere around 12 years (I have been around for 6 of them). We need to be open to new ideas. Not just because the community is growing old an dying, but because doing so allows people to enjoy the game in different ways.


Then why not just say that, we need to be open to new ideas?!

Leads to so much less confusion in the end

Whilyam wrote:
DarK wrote:
FACT: Cyan need to tell us what to throw out

Objection here. Cyan needs US to tell THEM what to throw out. What we disagree on is by what criteria we throw things out. I think:


Cyan is holding on to the keys to Uru, please read the topic title.

Submitting changes to Cyan

If it was something along the lines of “How to release code to the community” then I would not be spending my time trying to come up with a system that pleases the vast majority of people in Uru.

So they need to tell us what they want, not the other way round.

Whilyam wrote:
DarK wrote:
Generally In most projects you could count the number of patches on one hand that would meet that criteria.

In most projects you have illegal, crashing patches? Which ones? Every project I see has legal, stable patches.


Actually if you go ahead and read what I posted, we are in agreement here.

My point was that your criterion does not filter out enough patches to make a difference.

Whilyam wrote:
DarK wrote:
Additionally under your rules: I could create a loop that calculates Pi for 2 hours before you link into relto. I can claim it’s by design.

No, that would violate the ToS. Specifically the part about harming game experience that was recently incorrectly referenced in regards to OHBot.


The 2 hour wait is part of the game experience; I placed it into my projects design specifications

Can you start to see why cyan needs to tell us what they want in Uru yet?

Specifically, if they are to up hold a ToS as you suggest, they need to be in control of the system specification. Otherwise we could just submit anything and they would have to work harder to remove the changes.

Whilyam wrote:
DarK wrote:
So: Cyan needs to specify what we need to keep and what we need to throw out for the official cyan source.
We already have some guidelines on what that might be with the age builder’s guidelines, but we can ask cyan to confirm any other rules they think they need.

Wrong. This increases Cyan's workload. We need to objectively look at patches and send the list to Cyan for implementation. The patches are implemented and people decide whether to install them or not.


You also have to look at the technical reason why this will not work until various changes have already been made to allow it.

We need to be able submit changes to cyan first.

Chicken and the Egg.

Without a submission system, each time a patch needs to be implemented we will need to have more farcical conversations such as this one.

Whilyam wrote:
Whilyam wrote:
It freezes creativity and the urge to do voluntary work when that work can be discarded like this.
.
DarK wrote:
FALSE: Nothing is stopping you from forking from cyan’s code base and making your own version of plasma (plasmuru if you like)
Your work is only a waste if people do not use it. If you have a fear of that, there may not be a use for the change you are planning in the first place.

Except people will want to develop something for Cyan's Uru shard (although there will certainly be those who don't care one way or the other). If it doesn't go onto Cyan's shard, it's likely not to be seen by as many people, if at all. Also, no one wants to fork the code just so they can have a Twitter plugin when some dunces declare it "not what Uru stands for" or "not needed."
That is a stupid reptilian criteria of wants and needs, not an open environment of creativity and experimentation.

We are not creating art here; we are developing a computer program that has set requirements to perform.

Age building goes through a similar stage set of, design, implement, test, maintain ...

Computer programs are best built using lifecycles and methodologies.

Interestingly I was scanning through an old college document on systems design and I ran into this.
Code:
Requirements

What the client will need the system to perform

Wants: A specification that the customer thinks they need
Needs: A requirement for the system to produce specific output

An Environment of creativity and experimentation is a want, not a need.

What Uru needs is developers to program code that meets criteria. You have to limit your creativeness and experimentation between those criteria.

Otherwise you just end up with crap that does not work!

Whilyam wrote:
Whilyam wrote:
That is not the consensus, that is your desire

DarK wrote:
Well it’s actually consensus, because the few people who are responding to the original post seem to have the same or similar ideas to mine.

Dictionary.com describes consensus as the majority of opinion or general agreement of a group. You have the minority opinion of a small segment of the community and are attempting to claim that as the majority.


In that small segment of the community that are discussing the actual topic yes. The rest of the community are failing to understand what the topic actually is in this thread.

Whilyam wrote:
Whilyam wrote:
And I am contributing to the discussion.

DarK wrote:
:?

See, it's not actually a discussion if you are the only one talking. If it's a bunch of people agreeing on something and saying what a good idea it is, that's called a support group.


Which would suggest I am leading them ... Kind of a shock for me there, because I didn’t sign up for that roll.

I will lead if it’s required of me, but no one has stepped up and told me to lead on this project. So I will not do so.

Whilyam wrote:
But what am I saying, discussion isn't allowed on forums. :lol:

It is, but you just seem to be berating me with pointless text that I can’t actually discuss and arrange compromise.

Your way or no way apparently, that’s all I can see from your posts. Give me an idea, something I can actually work on to create a system that might work for your environment of creativity and experimentation and that protects the original aspects for cyan.

Whilyam wrote:
To reiterate: The fans CAN filter the patches.


Correct

Whilyam wrote:
They MUST do this through objective criteria.


Cyan decides the criteria

Whilyam wrote:
If not, we repeat the Liaisons. Plain and simple.


I can already see that the Liaisons will repeat its self; your plan requires us to make a decision on what is Uru.

We can’t even decide how to best to submit work to cyan, let alone what will be considered correct to be submitted.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Apr 17, 2010 10:35 pm 
Offline
Obduction Backer

Joined: Tue May 09, 2006 6:35 pm
Posts: 1045
Location: Brighton and Hove, england
can we stop this argument. I've not followed this thread since the first couple of pages and I don't intend on reading this argument. We all have the best interests of URU in mind and all want to further the progression of moula lets agree to disagree and move on.

_________________
The ending will never be written as long as the called remain to continue on the path of those who came before
http://www.kicktraq.com/projects/cyaninc/obduction/


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Apr 17, 2010 10:46 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
Samsbase wrote:
can we stop this argument. I've not followed this thread since the first couple of pages and I don't intend on reading this argument. We all have the best interests of URU in mind and all want to further the progression of moula lets agree to disagree and move on.


Apologies

This thread seems to have taken a turn too much away from the topic at hand.

Currently I only respond to keep the thread on topic, which I have again attempted to do so with previous response.

The post I selected was where the last set of diversions stemmed from.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Apr 17, 2010 11:00 pm 
Offline
Obduction Backer

Joined: Tue May 09, 2006 2:00 am
Posts: 1669
Location: Lakewood, WA
Quote:
This is getting beyond farcical!


After nine pages I agree. With this pot being stirred so much the cream will never rise to the top. Cyan’s request is complex and requires some room for healthy discussions. Maybe with some help from our fellow posters and Moderators we can make it better.

I purpose a possible solution. Instead of clogging up this thread with all of the purposed suggestions and their discussions, how about some structured discussions. This topic needs its own forum.

Each of the purposed suggests have merit. Make a separate thread discussion for each purposed suggestion linked from the suggestion post here. Leave room at the top of each of those discussion threads for the proposal and a summation of what came out of the discussion. When discussions are finished and summations posted lock thread with sticky for all to see.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 1:45 am 
Offline
Creative Kingdoms

Joined: Tue May 09, 2006 8:06 pm
Posts: 6229
Location: Everywhere, all at once
May I suggest that you just do it? People can just post code somewhere, let us know where these repositories are, and see how different people or organizations procede with their reviews. Then post links to your reviews on these forums or point folks to your own places of review and discussion where those things are openly accessible without registration. Experiment, discuss, but experiment more. You don't have to ask for our permission to do it your own way and you won't convince everyone. Just do it. The most acceptable process will persuade or entice folks to use that one. If there's more than one acceptable way to do things, we have choice.

Lacking a universally acceptable or neutral fan venue, It might be nice for someone motivated to commit to maintaining a thread here to accumulate links to repositories in one post and links to code reviews in the next post. Folks would post links to their code and/or reviews for the organizer to categorize and list in the first two posts. Or something similar.

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Make a commitment.
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 4:19 am 
Offline

Joined: Tue May 09, 2006 1:04 am
Posts: 4134
Condensing this so we don't keep doing this blow-by-blow nonsense. Particularly when you are unclear.
DarK wrote:
Then why not just say that, we need to be open to new ideas?!

Because everyone is "open to new ideas" if you ask them. The problem is that people operate through subjective criteria at what an acceptable new idea is to them.
Quote:
Cyan is holding on to the keys to Uru, please read the topic title.

This doesn't even make sense as a response to what I said. Cyan wants the fans to tell them what should be in MOULa, not the other way around. We do not need Cyan to tell us what gets included, clear? As Chogon said "the best stuff is what is submitted for inclusion into the next build of MOULa." Stop distorting what Cyan says for your own gain.
Quote:
Whilyam wrote:
DarK wrote:
Additionally under your rules: I could create a loop that calculates Pi for 2 hours before you link into relto. I can claim it’s by design.

No, that would violate the ToS. Specifically the part about harming game experience that was recently incorrectly referenced in regards to OHBot.

The 2 hour wait is part of the game experience; I placed it into my projects design specifications
Can you start to see why cyan needs to tell us what they want in Uru yet?
Specifically, if they are to up hold a ToS as you suggest, they need to be in control of the system specification. Otherwise we could just submit anything and they would have to work harder to remove the changes.

A 2 hour wait for a link is not part of the game experience because it halts any potential gameplay (all linking has an unnecessary wait time). This is important to distinguish between this and the pellet cooking times as there no gameplay is stopped (i.e. you can leave Er'cana if you want). Your strawman fails, DaRk (or however you capitalize that). Let's move on.
Quote:
We are not creating art here; we are developing a computer program that has set requirements to perform.

This is the ignorant opinion that has ended countless projects. That because something isn't art, creative freedom doesn't matter. It is plainly wrong. People are creating code to introduce features to the game. The process of thinking up an idea for an add-on is a creative one, whether you like it or not. A (good) developer will ask himself how he could make the game experience richer. Social network connection? In-KI browser? Simpler way to load Ages? What should he work on? Those are the questions going on in a developer's mind. When I make Ages, that's how I think. How can I make he player's experience better? What will impress them? It is that process that dies with subjective, backwards criteria like those proposed. It is, quite simply, an ancient way of looking at development.
Quote:
In that small segment of the community that are discussing the actual topic yes. The rest of the community are failing to understand what the topic actually is in this thread.

That is a fallacious excuse. The rest of the community does not agree with you.
Quote:
Your way or no way apparently, that’s all I can see from your posts. Give me an idea, something I can actually work on to create a system that might work for your environment of creativity and experimentation and that protects the original aspects for cyan.

Give me your idea as a set of objective criteria and I'll give you mine in subjective terms.
Quote:
Whilyam wrote:
They MUST do this through objective criteria.

Cyan decides the criteria

Cyan has asked us to come up with the criteria. Stop trying to give Cyan more work.
Quote:
Whilyam wrote:
If not, we repeat the Liaisons. Plain and simple.

I can already see that the Liaisons will repeat its self; your plan requires us to make a decision on what is Uru.

My "plan" requires we DON'T decide what is Uru. That would be a subjective criteria. Again: Legality, Stability. As soon as you venture into nonsense like "do we need it?" and "does it fit what I think Uru is?" you set up more nonsense, drama, and power-grabbing.

_________________
-Whilyam
Cavern Link:My IC Blog


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 4:51 am 
Offline
Obduction Backer

Joined: Wed Apr 14, 2010 2:46 am
Posts: 34
Samsbase wrote:
can we stop this argument.


Well, when it's a dozen people v one man, you know where the power rests...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 5:20 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
I'm sorry to continue this argument, but it's quite important. We can't "agree to disagree" because we're arguing about what goes in Uru -- that is the topic at hand. Ultimately it won't really matter, because if you ruin Uru with stupid non-canon things, Cyan simply won't accept it.

Cyan has already been very clear on their guidelines. Whil, as you argue, the code we submit is part of that art. The same rules apply. See Montgomery's post on Page 7.

Whilyam -- I agree we need somewhat objective criteria for evaluating patches. I don't agree that they should be your criteria. Again, Cyan's guidelines will do fine.

Off topic, stop abusing the word "strawman" to describe our examples of what you are proposing. You have said "anything legal and stable should be accepted." I said "why not have a flight simulator" and DarK said "why not have a 2 hour Pi calculation before linking to Relto." And you said "Instead of admitting your strawman, you still think it's okay to use it as an argumentative crutch." Yes, yes I do. Because all the examples that people are throwing at you fit into your criteria. A straw man is something which is not representative of your argument, but these are -- it's not hard to find ridiculous proposals which fit your criteria because your criteria is pathetically weak. If your response to them is, "pff, well obviously we couldn't allow a 2 hour wait time. That would be silly." That is NOT a valid response given that you are saying there should be no subjectivity involved, only whether the patches correspond to the letter of your criteria. Either a) your criteria is wrong, and it must be changed to rule out our "silly strawmen". Or b) you are allowing yourself to use subjectivity in judging our ideas, and therefore you can't say it's a clear-cut decision.

Do you see that perhaps there is some need for consensus, and not just blindly following your criteria?

When someone proposes something stupid, the easiest way to prove that it is stupid is to come up with something ridiculous which is allowed by their proposal. This is called reductio ad absurdum.

Let's try some more "feature suggestions" and see if you agree:
- Ki feature which lets me immediately spawn into any player's Age instance by name (without an invite).
- A new journal in the city written by Atrus detailing how he in fact enslaved the Bahro to build the devices on his many Ages.
- An imager in the city which streams random YouTube videos to anybody who walks past.

All of these features are extremely distruptive to other player's play experience and/or their perception of the existing Cyan story. They are allowed by your rules because they don't crash the game or break the law (and thus they are not "straw men"), but they are vigorously prohibited by RAWA's rules.

I don't know why people are saying "nobody cares about canon". (See the "do you care about canon" thread.) Sure, maybe not everybody cares whether Yeesha is allowed to break rules, or whether the D'ni had touch screen technology, and so on. But I'm sure that nearly every single Myst player (both here, and in other forums) would draw the line much more conservatively than you. I dread a day, a year or two from now, when I link into the city to see people in flying cars overhead, running around the city firing laser blasts at each other, transforming into Bahro, and if I open up my Ki screen I see the front page of Yahoo with scrolling news updates. Regardless of how you feel about the finer points of the Art, we have to maintain the "feel" of Uru. That is what I mean when I say "I care about canon."

Whilyam wrote:
Cyan has asked us to come up with the criteria. Stop trying to give Cyan more work.

It is very important that you, and anyone who agrees with you goes a) back to Page 7 and reads Montgomery's quote of RAWA's rules, and b) goes back to Page 1 and reads Chogon's original post.

Cyan never asked us to come up with criteria. Cyan asked us to come up with a process for getting patches into Uru. RAWA/Cyan have already given us criteria. It has served the Guild of Writers (which I believe you are in) well. They apply to game patches just as much (if not moreso) than fan Ages.

Lastly, Whil, you are still conflating core game features with add-ons/mods. I agree that an add-on system is desirable. Once it's in place, I don't give a hoot what add-ons you come up with, as long as they are not installed by default, AND they do not impact my gameplay experience (i.e., I can't tell if you have them switched on or not; i.e., a mod which lets you fly around the city is a no-no). Add-ons are fine. Please let's limit this debate to deciding what goes into the core game engine -- i.e., things that all players will be experiencing without any customization.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 5:20 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Okay, taking a step back from that debate

There is a lot of suggestion that a) Cyan are going to manually filter all the patches, and/or b) there are going to be lots of forks because nobody will agree on things.

I don't see either of these as being the case. This is not how open source projects work. Open source projects tend to have a lot of branches but not a lot of forks. Forks are for when things get really really bad. The way an open source project works is that there is one mainline trunk, with everything that the community has decided (by consensus) to accept. Branches are for things that have not been accepted yet. Branches which are rejected are abandoned, or re-tooled by their authors until accepted.

Cyan does not want to be involved in every debate. We cannot rely on them to be. Look at the 9 pages of this discussion and note that Cyan have not posted a thing since the first post. We can't expect them to be more involved later on. We need to decide on nearly every patch by consensus. Then if Cyan wants to reject it later, they can.

If the community cannot decide what goes in, maybe in a special case, we ask Cyan, "Dear Cyan, we have a working patch which is all ready to go. If we committed this to our trunk, would you accept it?" They can say yes or no, and that will be the deciding vote. But this has to be the exception, not the rule.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 2:33 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
mszv wrote:
Let's talk about having several different versions of the client on the same server. Most of the online games I'm familiar with don't let you do that. If you don't have the right version of the client, you either get an automatic upgrade or you have to do it yourself. This is done for practical reasons, so everything works as anticipated, so nothing breaks.

It's simpler to do it this way, but by no means necessary.

Consider the situation with the web: sites are hosted on a variety of different servers, and accessed using a variety of browsers. For the most part, this isn't a problem. Where it is a problem (e.g. sites requiring specific browser versions), it's due in large part to the legacy of the browser wars, where various parties tried to obtain a degree of control over the web, resulting in them either not particularly caring about compatibility or even actively trying to prevent compatibility.

This shouldn't be an issue for "Open MOUL". I think that most people will strive to retain compatibility. Some people may be more concerned about getting their pet feature out there right now, but this tends to be self-correcting (i.e. people quickly discover that the rest of the world is less keen to abandon compatibility).

Once MOUL is fully open-source, the long-term goal would be less about specific features than with overall flexibility. E.g. allowing the client, server and communication protocol to be extended independently. The server should be able to supply code to extend the client (analogous to how JavaScript is used on the web), so that new features can be added to the game without requiring a new client.

This is something to be considered by those planning to re-work the KI: there should be portions of both the open and closed KI displays which are under the control of the server. E.g. the server should be able to add a limited number of buttons to the closed KI, with icons specified by the server, and to add tabs to the open KI whose contents and behaviour are controlled by the server.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 2:51 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
Eat_My_Shortz wrote:
Open source projects tend to have a lot of branches but not a lot of forks. Forks are for when things get really really bad. The way an open source project works is that there is one mainline trunk, with everything that the community has decided (by consensus) to accept.

OTOH, most open-source projects start off being written by one person or a closely-knit group of people who continue to take an active interest in the project as the developer community grows. Once you have a clearly-identified "official" version, everyone tends to stick with it unless there's a very good reason to make the (substantial) effort to escape from its gravity well.

But open-source projects which start off as closed-source projects which are orphaned by their creator(s) often splinter into multiple forks from the outset. Sometimes, one fork wins out and becomes the "mainstream" version. Other times, no fork achieves critical mass and the project never really progresses beyond the state in which it was orphaned.

If Cyan doesn't take the lead in managing the project, a lot of developers will just look for whichever effort looks like it's going to win out. People aren't going to want to track half a dozen repositories, forums, bug trackers etc; they'll just head for the same one which everyone else (who matters) seems to be heading for.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 3:31 pm 
Offline
Obduction Backer

Joined: Sun Jan 20, 2008 2:14 pm
Posts: 902
Eat_My_Shortz wrote:
Cyan never asked us to come up with criteria. Cyan asked us to come up with a process for getting patches into Uru. RAWA/Cyan have already given us criteria. It has served the Guild of Writers (which I believe you are in) well. They apply to game patches just as much (if not moreso) than fan Ages.


Actually, I'd recommend you do so research of your own. =)

RAWA has *SPECIFICALLY* said, that his guidelines DO NOT apply to anything other than ages.

Also, you might be interested in the fact that RAWAs guidelines have not "served the Guild of Writers well", a few select few even give a flying freckaroonie about them at all, as they primarily concern D'ni-written ages. I know I complied with them not because I felt I /had/ to, but merely because I did so in the interest of co-operation. I had no intent on horribly breaking canon, in any case. Learn something about the Writers, before you make broad statements. Nothing, really, can be said to "serve the Guild of Writers well", perhaps PyPRP for the last god knows how many years, or perhaps Drizzle, in more recent times. RAWA's guidelines are new, and merely exist. They do not necessarily serve the writers well. The writers have been writing ages for much, much longer than that.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 3:43 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
Keikoku wrote:
Eat_My_Shortz wrote:
Open source projects tend to have a lot of branches but not a lot of forks. Forks are for when things get really really bad. The way an open source project works is that there is one mainline trunk, with everything that the community has decided (by consensus) to accept.

OTOH, most open-source projects start off being written by one person or a closely-knit group of people who continue to take an active interest in the project as the developer community grows. Once you have a clearly-identified "official" version, everyone tends to stick with it unless there's a very good reason to make the (substantial) effort to escape from its gravity well.

But open-source projects which start off as closed-source projects which are orphaned by their creator(s) often splinter into multiple forks from the outset. Sometimes, one fork wins out and becomes the "mainstream" version. Other times, no fork achieves critical mass and the project never really progresses beyond the state in which it was orphaned.

If Cyan doesn't take the lead in managing the project, a lot of developers will just look for whichever effort looks like it's going to win out. People aren't going to want to track half a dozen repositories, forums, bug trackers etc; they'll just head for the same one which everyone else (who matters) seems to be heading for.


I agree with these points very much.

As an observational point with the Until Uru shards, no shard really reached a state of critical mass, where all players preferred to play. I would surmise it highly likely if code was just released with no structure behind it, forks will occur and the same situation would appear, No critical mass to win out.

If release is done in a structured form, with cyan maintaining a level of control (at the moment, this seems likely), it might be avoided, and the fork that lucks out with critical mass will be cyan’s original version.

Even with the structured release however, there is nothing to stop the no critical mass scenario from happening as well. If enough people think the original fork is too restrictive critical mass will shift to a community run fork, and submissions to cyan would stop in favour of the community project.

I see nothing to lose from placing control with cyan to begin with.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 4:24 pm 
Offline
Obduction Backer

Joined: Mon May 15, 2006 10:02 pm
Posts: 2266
Location: Tigard, OR
Although the topic continues unabated, I know that I would certainly appreciate if people would refrain from point-by-point rebuttals. Such posts are typical of an argument, not of a discussion.

The objective recommendations put forth by Whilyam are our best option at this time. I understand some people are concerned that Whil's criteria are too loose, and some people have proposed some rather outlandish examples of submissions that technically meet the criteria.

However, most of those examples ARE straw men, despite matching the criteria, because they are such incredibly unlikely scenarios. No-one that I know of in the community wants to add a spreadsheet calculator to Uru. A far better example, and one that is not a straw man, is if someone wants to patch flymode directly into the online MOUL game. That could happen. So... what if?

There's this back and forth over "are we making the criteria, or is Cyan?". This is a silly argument. Both the community and Cyan can apply filtering criteria. Just because the community approves something doesn't mean Cyan will also. And, Cyan could at any time say, "Hey folks, the point of having community criteria applied first is to cut down on the work for us... and your criteria aren't filtering out enough. Please tighten it up." And if Cyan does this, then we can try to rise to that challenge.

_________________
MOULa KI: 26838 | Prologue Videos | Visit rel.to to explore Myst, Uru, and D'ni communities!
Click here for social/game profiles


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Apr 18, 2010 4:36 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
Marten

Yes we can apply filtering both at cyan, and community level

Problem from what has been said here in this thread is that majority of the community do not care about cannon. Cyan filtering will undoubtedly favour cannon.

Cyan’s filtering will take priority over community filtering, since they have the last say what goes into their source tree.

If it is the case where the community finds cyan filtering too restrictive, forks of the code will take place and it’s up to the individual folks to write their own filtering (if any at all).


Last edited by DarK on Sun Apr 18, 2010 4:39 pm, edited 1 time in total.

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 ... 6, 7, 8, 9, 10, 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:  
cron