this is law!

[Christian]

As Charl put it, we need a few laws.

Charl suggested these 2:

1) every designer has to commit the source files

While I think that would be fantastic, I prefer that this isn't law, but rather strongly encouraged. I understand that it's quite a generous gift to donate your years work to an open project, and if you want to keep your source files that's fair enough. I'd rather have someone donate their finished files with source files than nothing at all.

2) once committed always commited

This indeed will be law, and there's little discussion around that. The project simply can't function is a designer donates their scenery and a year later wants it back. We're going to save ourselves that headache by making it a law that all commited scenery is commited with no strings attached. You transfer copyright to the group by commiting and have no right to revoke that

Ok, here are a few more laws that I suggest:

3) copyright is shared

This project and the individual owners own the copyright to the scenery. This means if I were to donate scenery, this project can do with it as it pleases as long my name is listed. On the other hand, I still am able to do with my files what I want. To clarify: I'm using some of my freeware to drive traffic to my commercial site. By donating it to this project (which I'll do) I can still use the scenery as standalone on my sites. This is only a bonus as in the end I'll also advertise this project. What I can't do however, is take a creation from someone else and rebrand it as my own. Copyright retains with the project itself and the original author, but does not transfer to other project members (if that makes sense).

4) freeware vs payware

I suggest that as this stage the project is freeware with the option to also distribute the whole thing or parts as payware at a later stage. How would that work? a) we need agreement from all contributors, or maybe a 3/4 majority agreement. b) as all scenery belongs to this project it can only be sold through the project, not individual members. To make it clear, I have no intention at this stage to make this payware nor do I exactly know how that would even work. I just don't want to discard the option if everyone here agreees we have a great opportunity whatever that may be...


Ok, that's what I can think of at the moment. Comments? Ideas? As with everything, I'd like to get a 'set of laws' we can all agree to.

[greaneyr]

I agree with all you've posted, Christian.

I also think it's important to record, for each scenery developer, a date of last contact; the time when the project team last heard from them. Maybe have a rule that states that any developer we haven't heard from in the last X months/years is considered to have abandoned 'employment' as it were, and someone else may take over their work. Like most aviation laws, this one is based on previous experience. Anyone remember Pro Controller? Written by Jason Grooms? Who just disappeared and left us with his creation for an indefinite length of time until someone else wrote ASRC?

In any freeware project where people are donating their time, it's inevitable there will be changes in the makeup of the team as time goes on. I just think it's important that we manage this.

[creator2003]

All of the above is just fine with me ,ive seen the worst in people due to this inclueding myself ,once its in its in ..
You cant take back what you have given ,they use to call it "Indian giving "
If you are a designer freeware or payware ,we are all in for the same reasons at the end of the day ,making NZ the best little bit of the world to Sim in ..

[Snowman]

For what my simple talents are worth,...................... im in,..................
Ive had the "Indian Giver" thing done to myself and a team-mate in another NZ FS project i was involved in, and it left a very "bitter taste in my mouth"...................

Lawrie.

[Christian]

One thing I should mention, the heading 'this is law!' was a bit tongue in cheek in response to Charl's post. Not that people think I want to establish some form of mind controlling totalitarian system here

If you have any worries or suggestions about what should be in our base set of 'rules', please post here.

Christian

[greaneyr]

I just thought of another 'law'.

At this stage, it feels as though everyone is in agreement with each other over the philosophical motivations behind this project. This is a really good thing and is going to be a reason why this is successful. However, as we all know from our years of experience on NZ flight simming forums (and I'm not referring to this one at all here) things aren't always so rosy. As I see it, developers will work largely using their own methods, and provided they produce work that complies with the standards at the end of the day this is fine. I think we need to nurture people's individual ways of working to a certain degree. However, there will need to be unity over certain issues and there are bound to be disagreements at times. When this happens, this rule would come into effect:

Please bear in mind that the decisions made by the team leader are final and have been chosen because this is the way the team feel is the best for all involved (developers and end-users - the reason we are doing this after all). If a decision is made that you disagree with, it is probably a minor issue in the overall scheme of this project so get over it and move on.

This is a very wordy rule I know, but it's a sensitive topic and I didn't want people to get the wrong idea. Basically, the rule would be "Pick your battles and don't let a small dispute ruin your involvement in thie project"

[Christian]

QUOTE (greaneyr @ Jan 16 2008, 05:35 AM) <{POST_SNAPBACK}>

I just thought of another 'law'.

At this stage, it feels as though everyone is in agreement with each other over the philosophical motivations behind this project. This is a really good thing and is going to be a reason why this is successful. However, as we all know from our years of experience on NZ flight simming forums (and I'm not referring to this one at all here) things aren't always so rosy. As I see it, developers will work largely using their own methods, and provided they produce work that complies with the standards at the end of the day this is fine. I think we need to nurture people's individual ways of working to a certain degree. However, there will need to be unity over certain issues and there are bound to be disagreements at times. When this happens, this rule would come into effect:

Please bear in mind that the decisions made by the team leader are final and have been chosen because this is the way the team feel is the best for all involved (developers and end-users - the reason we are doing this after all). If a decision is made that you disagree with, it is probably a minor issue in the overall scheme of this project so get over it and move on.

This is a very wordy rule I know, but it's a sensitive topic and I didn't want people to get the wrong idea. Basically, the rule would be "Pick your battles and don't let a small dispute ruin your involvement in thie project"

good point Richard. Or the rule could read: "This is a hobby, not cure for cancer research! Go take a walk and have a cool beer.".

If there are serious disagreements we can always hold a poll.

[Ian Warren]

It is quite funny, read this thread again , as dated ... Funny! ... the ones then that did the work then are still here now, and some new ones, the rule and laws trying to create something that already was in place but only a few doing ..... the rule makers fizzled like a 2015 .. not 16 yet wet fire cracker.