ooc-dev team mailing list archive

[Friedrich Weber <fred.reichbier@xxxxxxxxxxxxxx>]

Hi There,

> ORCs should be stored in a versioned repository (preferably git), so
> that any new members to the ooc community may see the history of ORCs.

Yay. I think using GitHub is a good idea (we have no alternative anyway
=D), since people can also use their revision commenting feature.

... and I have some questions. ;-)

>    1. Guideline - A guideline dictates a way in which ooc workflow is
> to be performed, from code generation, to compiler implementation, as
> well as any other role that would require a rule of some sort.

Does this also include code style guidelines?

>    3. Extension - An extension is any additional library. This could
> be anything from a language bridge (e.g. ooc to Python), to a platform
> specific feature (e.g. DirectX or Cocoa bindings). As these are not
> part of the core ooc language, they are not required to be implemented
> by implementations other than the core ooc implementation (i.e. rock).

Does this only affect additions to the standard library?

> After 1 year, the Author of a rejected ORC may make a case to move
> their ORC from rejected to accepted. At this point the ORC will be
> placed in draft status, and the community will once again be allowed
> to voice their opinions. There is no limit as to how many times an ORC
> may be tasked for re-evaluation.

Hm, I find 1 year a bit too long, compared to the age of ooc ;-) Maybe
change this to 6 months?

> License:
>
> All ORCs are released in the public domain, and as such are not
> required to state any license agreement.

Don't want to be nitpicky here, but can we use a free documentation or
creative commons license here? I'm not sure, but AFAIK there is no such
thing like "public domain" in some European countries (at least Germany).

I like the idea of ORCs, also I like this acronym. So thanks for this
ORC ORC ;-)