Whilyam wrote:

Bellerophon wrote:

I mean, think about what you're asking with your turn on/off source code thing here. You're basically asking that when someone wants to download MOUL that they'll download a massive amount of code with thousands of different patches to the same files, go through a codebase assembling a completed version, run a compiler and compile, and then connect to the server. Which promptly crashes because there are dozens of different codesets connecting to it. Mister Blue, you see, decided he liked kicking to be less strong than Mister Red, and now they have incompatable physics engines.

No, that is not what I'm suggesting. You're extrapolating that out beyond what I explained. Firefox, again:
When you install Firefox, do you download every add-on ever made? No. Same with Uru. Understood?
As for your crashing strawman, that isn't stable, that thus is not allowed. Still with me here?

Quote:

Quote:

No, there needs to be a primary trunk and compiled version that is peer-reviewed with a coherent view to the future and engine development, and a server based on that reviewed version.

No, there needs to be the base game with code that players can install on their own.

You are talking about something entirely different to the rest of the thread. You're talking about add-ons, or as they're called in the game community, mods. We're talking about the base game here. Modifying, upgrading and expanding the base game before it ever gets compiled into an executable. What players do beyond that is their own business we can't really control now that it's open source. If we added in a mod system to allow WoW or Firefox style add ins, that'd be fantastic. I'd love to have that. We're not there, and it's not what this thread is about. This thread is about universal everybody-has-a-game-based-on-it source.

And stop absuing the word strawman, the main reason you and everyone else isn't seeing eye-to-eye in terms of scope is we're talking about different things.

I agree ... it is very important that we make the distinction between the game and add-ons.

Whilyam wrote:

Take Firefox Add-ons, for example. No one asks whether an add-on is necessary because people universally understand that's a stupid thing to ask someone. Again, there are numerous examples I won't subject you to.
In short, YES everything that meets those two criteria must be allowed. Don't enable it if you don't like it and stop trying to dictate what people do.

So Whil, you are advocating that we write a bunch of add-ons for Uru, in a Python script or something? (e.g., a Twitter client in the Ki, which can be installed via a custom Python script?)

Fine ... well, Uru doesn't currently support add-on infrastructure at all, it would seem. But eventually, perhaps we could write one. At that point, we can set up a Mozilla-like addons site where users can browse and install Uru plugins.

When you say "crashing will not be a problem because stability is a criteria of each addon" -- yes, but when you put a huge number of these add-ons together, suddenly you'll get crashing (due to conflicts between addons) or at least major slowdown. Try installing 20-30 Firefox plugins and see how you go.

But I would argue that the majority of Uru players won't be interested in Uru addons, just the core game. We need to make that as stable as possible. Not just stable, as you say, but it needs to make sense in the game world (Twitter plugin for Ki by default is a huge NO). And needs to be a manageable codebase. Remember, we need to maintain this!

Whilyam wrote:

If someone can do something like [turning Uru into an operating system], more power to them. The fact is, it's practically impossible.

So if I could integrate a web browser, word processor, and flight simulator into Uru, you'd be cool with that?

If you're talking about those 2 conditions being the only conditions for adding features into the game engine itself, then you are completely reckless. NO software project allows universal feature addition as long as it's optional and doesn't break things.

Because uru is online, that will limit the add-on idea.
Ages can be considered an add (you don't have it, don't go there).

But clothes for exemple, what happens if a user a clothes you don't have ? More generally, using an add-on you don't have ?

_________________
MOUL ki : Ewilan : #07497427
MOULagain ki : Will tell if i manage to get in someday.

Yeah that's a good point Eowyn.

I'm thinking that user-customizable (ie., client) addons will be limited to two things:
1. Custom Ages. It's plausible (and probably desirable) that we let people install their own Ages (or at least, Ages are on the server but it's up to the clients to add them -- this would be for all fan ages that aren't officially "blessed" into canon). These Ages wouldn't appear on everyone's shelf, only if you add it using out-of-game UI.
2. UI mods, similar to World of Warcraft. If people want Facebook/Twitter integration, that's how they'd get it. Such a mod has nothing to do with the server at all.

Other changes, such as clothing, running speed, new relto pages, etc, would need to be approved in the server.

Mark 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!

Regardless of what many people say, in my opinion it’s a question that hasn’t been really settled: what will be the degree of involvement Cyan? They may not have the staff to look at ‘tons’ of changes, but this is their shard, the official shard, and I don’t see them going totally hands-off with it. Unless they are whiling to merge in any piece of code/assets as long as it is bug-free; but that seems doubtful.
So, unless Mark/Rawa/Rand says otherwise it seems safe to assume that one way or another, they will want to approve (or at least have an overview of) what is submitted. Please contradict me if you think I’m wrong.

With that in mind:

- - -

There’s a lot of debate around the code review/submission/integration issues; and while they are important on their own we still have to solve the more pressing core question: How to decide what to submit. And as long as this isn’t solved any debate or ideas put forward might be moot.

There are two kinds of changes that we will want to do: 1) Bug fixes, and 2) New features & big changes. The Ki is the perfect example of that.

The second category is problematic. Fixing bugs and adding ‘obviously’ lacking features (scroll bars, network performance enhancement, Unicode support, etc) are easy enough to reach a consensus on. I don’t think there’s a debate about that. New features or fundamental game redesigns are a whole different thing. (For instance: a patch that totally redesigns the Ki.) And that’s the most problematic hurdle to overcome because people will want to make those new features and changes; that’s what will (and already do) lead to the most vocal debates.

To me those big additions and changes are the core of this whole open-sourcing initiative. This is the most important and most problematic aspect; because we touch the core of the game here. We are not merely adding our own stuff we are changing fundamental existing Cyan decisions.

And as such, as I mentioned earlier I’ll assume Cyan will want to review and approve changes. They may even have to review/approve mere ideas. (in order to avoid tons of community work potentially going to waste). This means we need to filter out stuff before it gets to them and present it in a lightweight format. But before we even get to that point we need to agree ourselves on what we submit to Cyan…

For example: The Ki. – Many people want to redesign it or change it; some of those changes will conflict with each other; some will be better than others etc. How do we agree on a single idea/proposal? Do we vote? And even then, once it has been agreed on, and submitted to Cyan how do we ‘prevent’ another later proposal from reverting it? This is an endless problem. Where do we draw the line? Where does Cyan draw the line?
Just as important: When do we submit proposal to Cyan? Every time we have a new piece of code or idea? Periodically? (“the Ki redesign of the month”?)

Unfortunately at this point I don’t have any solution to those problems, I just raise what seem like important questions…

Quote:

For example: The Ki. – Many people want to redesign it or change it; some of those changes will conflict with each other; some will be better than others etc. How do we agree on a single idea/proposal? Do we vote? And even then, once it has been agreed on, and submitted to Cyan how do we ‘prevent’ another later proposal from reverting it? This is an endless problem. Where do we draw the line? Where does Cyan draw the line?

Yup, vote. At least on big issues, that seam the best.
And we also need to learn to live with each other. Think in other way than "I want things that way, so this is the one and only way."
Learn to compromise, too. We can't make everyone happy with every single change, but try to make the majority happy.

_________________
MOUL ki : Ewilan : #07497427
MOULagain ki : Will tell if i manage to get in someday.

Eat_My_Shortz wrote:

So if I could integrate a web browser, word processor, and flight simulator into Uru, you'd be cool with that?

Integrating a flight simulator seems a bit pointless. The other two seem reasonable enough.

At least, at would be useful to be able to have in-game help, and that should probably support images and hyperlinks. And the text entry feature could probably use some enhancements (okay, not exactly a word-processor, but it the line between a text editor and a word processor is far from clear).

So, I'm definitely in favour of some form of "web" browser integrated into the KI. Now, we could construct something Uru-specific, but if you need a "rich text" format, HTML is as good as any other. So I'd definitely consider just embedding Gecko/MSHTML/whatever rather than writing a renderer from scratch. At which point, why not just go the whole hog and use it for actual web browsing?

aloys wrote:

Regardless of what many people say, in my opinion it’s a question that hasn’t been really settled: what will be the degree of involvement Cyan? They may not have the staff to look at ‘tons’ of changes, but this is their shard, the official shard, and I don’t see them going totally hands-off with it. Unless they are whiling to merge in any piece of code/assets as long as it is bug-free; but that seems doubtful.

What they accept and what they run on their server aren't necessarily the same thing.
I would expect new server-side features to be implemented in such a way that they can be disabled either at compile time via e.g. #ifdef and/or at run-time via a configuration file. So there are three separate issues here: which features are accepted into the source code, which features are included in any binaries which Cyan (or anyone else, for that matter) release, and which features are actually enabled on a given server.

aloys wrote:

For example: The Ki. – Many people want to redesign it or change it; some of those changes will conflict with each other; some will be better than others etc. How do we agree on a single idea/proposal? Do we vote? And even then, once it has been agreed on, and submitted to Cyan how do we ‘prevent’ another later proposal from reverting it? This is an endless problem. Where do we draw the line? Where does Cyan draw the line?

Any changes which only affect the client can be accepted or rejected by each individual user. I haven't looked at the KI source in detail yet, but AFAICT the entire UI is just data: GUI.age plus GUI_District_*.prp. Once the anti-tamper features are removed (or at least, an exemption added for the UI), users can just replace those files to change the interface. Beyond that, if there's any part of it which needs to be implemented as native code, that should be moved into a separate DLL so that it can be replaced as well.

Keikoku wrote:

Eat_My_Shortz wrote:

So if I could integrate a web browser, word processor, and flight simulator into Uru, you'd be cool with that?

Integrating a flight simulator seems a bit pointless. The other two seem reasonable enough.

At least, at would be useful to be able to have in-game help, and that should probably support images and hyperlinks. And the text entry feature could probably use some enhancements (okay, not exactly a word-processor, but it the line between a text editor and a word processor is far from clear).

So, I'm definitely in favour of some form of "web" browser integrated into the KI. Now, we could construct something Uru-specific, but if you need a "rich text" format, HTML is as good as any other. So I'd definitely consider just embedding Gecko/MSHTML/whatever rather than writing a renderer from scratch. At which point, why not just go the whole hog and use it for actual web browsing?

People have literally already spent hundreds of man hours developing the browsers we have on our desktops today, and we want to add one to Uru?

A better idea would be, yes intergrate HTML/XML what ever for display purposes in the KI (There is already a basic mark up language for books and journals in the game)

But can we just not improve Alt+Tab, window, and dual screen support in Uru to make it easier to actually get to a real browser?

How long before we have to include flash support ?

Bad I will respond to your PM here ... as you do not seem be the only person who is having issues understanding what I am saying about guilds?!

Again guilds are in no way a bad thing, people are saying they are just a name, and I agree they are.

But as we have seen in the past. Structuring guilds (giving them back a governing council, rules, regulations and responsibility), you are essentially creating a social stucture that blocks out people from development.

Going further back than the guilds, lets talk about the guild of admins. Until Uru Shard Admins and closely connected developers.

I wanted to submit code during Until Uru, the amount of social hops I needed to jump through just to get to talk to someone was rediculous. I had to find out who was in the circle, how to contact them. Could I trust them with my code not to run off with it etc?

Addtionally at every stage I had to becareful not to release my code to the admins, or I would have be putting my ownership at risk.

These are two things open source developers like to have. Ownership, and the ability to contribute freely on their own.

The current flat structure in the guilds with no one really in control of what happens works for me.

If we do place submission and code with the guilds however, and then suddenly people start self electing themselves into possitions that makes them have more control. This does not work for me and I would be sure a lot of other people would have something to say as well.

Frisky Badger put it best I think

Frisky Badger wrote:

You are trying to protect everyone's opportunity to help with Uru.

So under my explanation, I would not exclude the guilds in anyway. Even if they had suddenly had a structual organsiation the guilds can still contribute to Uru.

What I am saying is that if the key elements for submission to cyan is placed in a location where a structual organsiation exsists (Such as the guilds ONCE had), it would be placing a barrier to developers. (Giving the previous issues I had in Until Uru).

I really can’t make it any more clear than above ...

Moving back on topic:

Cyan controlled tracker and Cyan controlled testing branch, with tracker moderation done by people cyan choose.

This gives open ended submissions for eveything (Including the KI Browser if you must ) with cyan pushing the buttons as to what gets included via the moderators?

Anyone any other ideas to be included and put forward?

Whilyam wrote:

Montgomery wrote:

One must also consider canon. This is huge, becuase it is the depth, subtlety and internal consistancey of the canon that makes Uru (and all of Myst) the place the community enjoys exlporing.

Drama or not, I personally feel there needs to be some kind of filter to avoid material that simply does not belong in the Uru universe. There should be strict guidelines for how the process is handled, and the pool of individuals who make those decisions should be open to any who want to vote. The Guild of Maintainers may be the natural choice for this.

Stop with the scary "material that doesn't belong in Uru" nonsense. There are two instances of material that doesn't belong in Uru and only two. 1: Material that is illegal/forbidden by the ToS (this covers pornography, malware, impersonation, and other areas). 2: Material that crashes users who meet the system requirements (this covers material that conflicts with other material, incomplete material, material that triggers another action that crashes the game, etc.).

With all due respect, my friend, I believe you will find the majority of the explorer community disagrees with you, here. After all, the point of developing user-created content is to make the GAME (and therefore the Uru universe) better for the players, yes? Not for the sake of the developer. Just because you can implement a really terrific Pong game into the KI doesn't mean you should, BECAUSE the KI is a D'ni artifact with an established history. When Cyan handed the game to the fans they handed the game to all of the fans, not just that minority of fans with the capacity to alter it.

For a real-world example, think of Star Trek or Star Wars. There have been literally hundreds of fan novels published. What do you think would have happened if any of these books had, say, put a lush jungle on Tatooine, just because they were really good at describing jungles? Or decided the Enterprise was actually made of chocolate, because they had a really good plot device involving flying too close to the sun? It would have f*ked with the established canon, and caused an uproar. Now, I realize neither Lucas nor Paramount ever tried to set up a fan-based structure for voting on the content of fan novels, but then Lucas and Paramount never turned their universes over to the fans due to lack of resources.

Whilyam wrote:

Canon is subjective, open to interpretation, and able to be disregarded by anyone, including Cyan. It is a useless criteria, plain and simple and it has no place in a workable code/content approval process.

No, sir:

RAWA wrote:

A FEW DISCLAIMERS:

- These guidelines are a work in progress. While attempts have been made to have them be as complete and accurate as possible, we reserve the right to alter, amend, change, update, fold, spindle, and/or mutilate them at any time. We also reserve the right to add other verbs to that list at our sole discretion.

- You (collectively) are now part of the creation process, and I have it on good authority that "with great power comes great responsibility." Specifically, in this case, that means that since we're going to be working out these kinds of details as we go along, even more patience, flexibility, and understanding is going to be needed on all levels from everyone involved.

- Past performance is no guarantee of future results.

- Void where prohibited.

- Objects in mirror may be closer than they appear.

[End of Disclaimers]
---------

Without further ado...

----------

The Five Rules of Writing, in their most basic form:

1 - Writers must live within the D'ni limitations of Writing.

2 - Writers must not break continuity with previously released D'ni information.

3 - Writers must not reveal "new" information about characters, places, groups, etc. used by Cyan.

4 - Writers must limit "new" information about D'ni society to specific, smaller groups within D'ni.

5 - Writers must not use the intellectual property of others.


Notes:

1) Except for Rule #5, these rules mainly focus on attempting to minimize continuity issues, so, when an Age is submitted for approval, enforcing these rules will primarily be the responsibility of the Guild of Archivists. You can think of theses duties of the Guild of Archivists as providing "information quality control" for the Ages.

2) Duties for the other Guilds will be spelled out as we move forward.

3) These rules are specifically intended to be guidelines for Ages and/or Storylines which are intended to be considered "official" (i.e. "canon"), where continuity is a prime concern. We also intend to provide separate guidelines for Ages and/or Storylines that which are intended to be considered "fictional" within the context of the Cavern. Those guidelines will be much less restrictive because continuity in those cases will be less of a concern. So if you want to tell a story that these rules do not allow (e.g. the story of Ti'ana between the Book of Ti'ana and the Book of Atrus), you'll need to abide by those guidelines when they become available.

-----------------
The Five Rules of Writing, further details.

1 – The Writers do not have Yeesha's special, innate abilities. They have to live within the limitations of the traditional D'ni Writers.


2 – The members of the Guild of Archivists need to have a decent grasp of released D'ni information, so that they can have working knowledge of what will contradict established D'ni information.

Note: Also included under "contradictions" are issues that have been intentionally left open for debate by Cyan. A Writer's storyline must not attempt to definitively confirm one side or the other of those issues.


3 – Characters, places, groups, etc. that have appeared in Cyan's games, novels, etc. can be mentioned or used, but Writers must not reveal any new information about those characters, places, groups, etc., where "new information" is defined as information that would in some way change what is known about the character, place, or group.

For example, one can "find" an old D'ni Age that was once visited by Veovis (the fact that Veovis may have visited that Age doesn't constitute any significant "new" information about Veovis, since it is very likely that he visited countless Ages, but they can't "find" an Age that was owned by Veovis or Written by Veovis (those kinds of things would be releasing new information about Veovis.)

The main City in the Cavern is also included in this. Areas that have been in Cyan's games or novels can not be changed. If one wants to reveal ("restore") a new area in the Cavern, it must be self-contained and only accessible via the Nexus (e.g. the Great Tree Pub) or via another Age (e.g. the Uran Silo linked to from Er'cana).

An exception of a place that was used by Cyan but can have "new" information revealed: specific D'ni neighborhoods. They can be considered as self-contained places. New information can be revealed about a Writer's neighborhood as long as it doesn't affect other neighborhoods or the main Cavern as a whole.

In short, the rule of thumb for determining what should be allowed is, "How likely is it that this new information will cause a contradiction with information released by Cyan or other Writers in the future?" If it's likely to cause a contradiction, then it is not allowed.


4 – The Writers should come at this with the mindset that they're expanding knowledge of the D'ni Universe by revealing new facets of a multi-faceted civilization, rather than revealing new information about the D'ni society as a whole. That is to say that any new information one reveals about the D'ni or its history should be specific to a particular (previously unknown) group within D'ni, so that the likelihood of future contradictions by Cyan (or other Writers for that matter) is minimized as much as possible.

For example, one could reveal that there was a group within D'ni that only ate a certain broccoli-like vegetable found in one of their Ages. Since this "revelation" is limited to one group, it doesn't affect the whole of D'ni society and is therefore unlikely to be contradicted by other stories in the future. Saying that all of the D'ni only ate certain broccoli-like vegetables is not allowed, as it is something that is very likely to be contradicted (in this specific example, of course, it already has been).


5 – This includes references to trademarks, copyrights, etc. Writers cannot write an Age where their character meets Captain Kirk, their Age cannot contain a Coca-Cola machine, etc. Everything in their Age or mentioned in their storyline must be their own work.

----------------

Examples:

- Writer wants to create a storyline where Gehn escaped his prison.

Verdict: Denied. This would violate Rule #2 (continuity issue: as far as has been revealed by Cyan, Gehn never escaped his prison) and Rule #3 (attempts to reveal "new" information about a character used in Cyan games and novels.)


- Writer wants to "find" an Age that Gehn had visited prior to the events of Riven.

Verdict: Approved. Does not reveal "new" information about Gehn, or contradict previously released information about Gehn.


- Writer wants to "Write" a link to a specific instance of Myst Island.

Verdict: Denied. This would violate Rule #1 (player Writers do not have Yeesha's special abilities to be able to write to specific instances of an Age.)


- Writer wants to "find" a link to another instance of Myst Island.

Verdict: Denied. This would violate Rule #2 (continuity issue: there are no known links to other instances of Myst Island) and Rule #3 (by revealing "new" information about a place used in Cyan games and novels).


- Writer wants to "find" more information about the Guild of Illusionists.

Verdict: Denied. This would violate Rule #3 (by revealing "new" information about a group used in Cyan games and novels).


- Writer wants to "find" information about the Guild of Reptile Trainers.

Verdict: Approved. This does not reveal new information about a group used in the Cyan games and novels.

Note: only "minor" guilds are allowed. It cannot be claimed that the Guild of Reptile Trainers was one of the 18 Major Guilds at any point in D'ni history, as the 18 Major Guilds are covered under the groups that have been used in Cyan games and novels. It is also something that would likely be contradicted in the future.


- Writer wants to "restore" a new area in the D'ni city itself.

Verdict: Denied. This would violate Rule #3 (by revealing "new" information about a place used in Cyan games and novels).


- Writer wants to "restore" a new area in the D'ni city, but it is self-contained and only available via the Nexus.

Verdict: Approved. The key to this being "self-contained," so it doesn't cause any continuity problems with the City, neighborhoods, etc. as it has been shown in Uru.

While the above is about storylines, it does make pretty clear Cyan's stance on canon. The KI is a D'ni artifact, and a fan can't add a screw-driver and a pair tweezers to it just because they want to. If you wish to create an Age full of flying bunnies and floating hearts there will be no objections, but you may find the fan-base "votes with their feet" when nobody visits it. However, if you want to "modify" existing Uru canon, it will be the function (according to Cyan's earlier-published intentions) of an established fan-based organization to reject such proposals that violate canon according to the rules provided by Cyan. It may be that Cyan will allow explorer "engineers" to tinker with the lattice and the KI dispenser hardware to the extent that certain additional features are added or revealed in future KIs. "May" be. That is up to them. But there will be a process for fans to submit such proposals to Cyan to accept or reject, and if Cyan carries through with their earlier ideas about the Guilds, the GoMa will be their clerks in that paper chase.

Nobody is trying to stifle creativity, create drama, or weild phenomenal cosmic power (least of all the GoMa). But the foundation of the Guild of Maintainers is to make the Uru experience as safe and enjoyable for those who visit it as it is in our power (granted by Cyan) to make it. And we're pretty passionate about that.

Thanks for reading.

_________________

Montgomery - Maintainer Grand Master of Inspections (ret.)

Bellerophon wrote:

And stop absuing the word strawman, the main reason you and everyone else isn't seeing eye-to-eye in terms of scope is we're talking about different things.

Right. Because claiming that not allowing useless, subjective criteria obviously means someone's going to make a star-transition in the KI page. People are using hyperbolic strawmen to further a harmful, restrictive set of criteria. We cannot successfully dictate how people enjoy Uru because we enjoy the game for different reasons.

Montgomery wrote:

With all due respect, my friend, I believe you will find the majority of the explorer community disagrees with you, here.

No, you will find the majority of the community doesn't give two hoots about canon. The small section of the community which remains here is the only section really concerned about canon.

Quote:

Whilyam wrote:

Canon is subjective, open to interpretation, and able to be disregarded by anyone, including Cyan. It is a useless criteria, plain and simple and it has no place in a workable code/content approval process.

No, sir:

RAWA wrote:

A FEW DISCLAIMERS: -snip

Yes, sir. All I have to say is "trap books," "Myst comics," or "Yeesha" and canon vaporizes. As I have said elsewhere, Cyan is the greatest enemy to the canon everyone gets their panties in a knot over. Canon needs to be one of a spectrum of interests Open Uru caters to on an individual basis. Just as I choose which Ages I see, I choose add-ons (oh, I'm sorry, "mods" *sips his champagne*).

Eat_My_Shortz wrote:

When you say "crashing will not be a problem because stability is a criteria of each addon" -- yes, but when you put a huge number of these add-ons together, suddenly you'll get crashing (due to conflicts between addons) or at least major slowdown. Try installing 20-30 Firefox plugins and see how you go.

Just as most people don't install 20-30 add-ons, most won't try (or need) to install 20-30 Uru add-ons.

Quote:

But I would argue that the majority of Uru players won't be interested in Uru addons, just the core game.

Here's that "I speak for the majority" nonsense again. Unless you have some credible statistics for that, you are just creating the false sense that your view is in the majority. Every person I have talked to about this has said they would love to have an Add-on system and think it would vastly improve the game and open it up to more people. I don't say "the majority of Uru players want Uru add-ons."

Quote:

Whilyam wrote:

If someone can do something like [turning Uru into an operating system], more power to them. The fact is, it's practically impossible.

So if I could integrate a web browser, word processor, and flight simulator into Uru, you'd be cool with that?

If you could do it without breaking the game and people (myself included) could avoid it by not installing it, sure. You know you can't, though, without a substantial amount of effort. Instead of admitting your strawman, you still think it's okay to use it as an argumentative crutch.

Quote:

If you're talking about those 2 conditions being the only conditions for adding features into the game engine itself, then you are completely reckless. NO software project allows universal feature addition as long as it's optional and doesn't break things.

NO popular game was put on a CD in 1993. Unless we are willing to try out new things, Uru will not survive. We are literally watching our community grow old and die. We need to allow people the ability to experiment and introduce features freely, NOT introduce subjective criteria to be abused by the small-minded and the power-hungry.

_________________
-Whilyam

Whilyam wrote:

We are literally watching our community grow old and die

I find your comment to be in bad taste sir.

Additionally we are talking about how to get patches to cyan and how cyan should distribute code.

You seem to be talking about something that would not actually happen. You would not be stopped from working on what ever you see fit.

Anything conserning code distribution has been suggested to be open to all to work from, however what seems to be at an impass is how to get patches in one place to send to cyan and who/how it will be decided what to submit.

So far the consensus seems to be that cyan selects people from the community, who it feels will best carry out cyans wishes

Do you have anything to add to this particular discussion?

DarK wrote:

Whilyam wrote:

We are literally watching our community grow old and die

I find your comment to be in bad taste sir.

Additionally we are talking about how to get patches to cyan and how cyan should distribute code.

You seem to be talking about something that would not actually happen. You would not be stopped from working on what ever you see fit.

Anything conserning code distribution has been suggested to be open to all to work from, however what seems to be at an impass is how to get patches in one place to send to cyan and who/how it will be decided what to submit.

So far the consensus seems to be that cyan selects people from the community, who it feels will best carry out cyans wishes

Do you have anything to add to this particular discussion?

The only thing I have to add is the last time Cyan tried selecting community members to carry out its wishes, there was a lot of mistrust and it was sort of a disaster, from a community management standpoint.

But I don't see a better way to do it.

DarK wrote:

Whilyam wrote:

We are literally watching our community grow old and die

I find your comment to be in bad taste sir.

Yeah but it's true though.

Any-whom, I would like to offer up the term Plasmuru for those who want to use Plasma to build anything (KIpong for example), half of the hissy fitting it down to the fact people cannot differentiate between Uru (thus Urulore staying true to the game etc) and Plasmuru (Secondlife uru, building whatever, blue skin, upside down arches, akin to UU I guess, not staying true to the game).

Because regardless of how people feel about it, there will be both.

And Whil is correct, those who really care about canon and lore can more or less be counted on one hand these days.

_________________
Beneath - Journey of an explorer in D'ni
UruBlogs - Blogs from Uru Explorers
Tweek@Guild of Writers - Age development Blog.

PaladinOfKaos wrote:

The only thing I have to add is the last time Cyan tried selecting community members to carry out its wishes, there was a lot of mistrust and it was sort of a disaster, from a community management standpoint.

But I don't see a better way to do it.

It’s quite easy; you create a circle of anonymous people, who don’t know each other by actual handles, but as something generic like PatchAdmin1, PatchAdmin2 etc....

This way people can’t actually turn around and single out a particular handle for harrasment, and if a PatchAdmin reveals their actual Uru Handle, they are well ... a bit daft really.

Additionally because everyone else is known as PatchAdmin#, they can’t reveal who everyone else is if they decide to leave the circle or is ejected from the circle.

If certain PatchAdmin’s decide to actually swap their real Uru handles, they understand that they are giving up part of the security put in place to protect them.

Normal rules apply, until issues arise, then that person is ejected from the circle if seen to be compromised or acting inappropriately and a replacement comes in.

It’s almost similar to Beta testing, apart from no NDA, and it’s fully renewable.

The system will not fall down either, because even if an entire circle is replaced, the community will again be back at ground zero, having to figure out who is approving patches.

Basically the “I’m Spartacus” principle!