[Kyle's list] 1 - oF goals description

_[as someone suggested this, I will open a thread for the main points Kyle brought up in this 007 megamail. First post is his original point. I could use some help with people adding the main points of what has been discussed since then.]

from contributing to OF for a while, i have a little feeling of what
it means to the community and the core team. but this feeling is
something i’ve had to learn slowly over time. without understanding
what OF means, it’s hard for people to contribute to the core in a
lasting, constructive way.

should it stay this way, where people just have to hang out long
enough in order to ‘understand’ OF? or should we write out something
more explicit that describes what OF is aiming for? something that
anyone can read, and use as a metric? by ‘metric’ i mean they would be
able to look at that description and say ‘this thing that i’m
interested in contributing really fits right in’ or ‘it doesn’t really
fit what OF is aiming for’.

if it’s not obvious why we need to make this more explicit, i’ll point
you to the pull requests. most pull requests that go unanswered for an
extended period of time are because it’s someone who is interested in
contributing, but is adding something obtuse or counter-intuitive to
the implicit ‘spirit’ of OF.

josh and i wrote a short document a while ago, with some short
statements describing how we see OF. i think that could be a good
start. (not sure where it is right now).

this question keeps coming up. e.g., http://forum.openframeworks.cc/t/determining-a-consistent-way-for-developers-to-manage-addons/6883/18

maybe a good way we can help zach/theo/arturo is by asking compiling a list of questions about things that are unclear to outsiders (and some are even unclear to insiders!):

  • is OF supposed to continue evolving organically, or do we want to adopt some basic rules and structure for development and releases?

  • is OF meant for students, amateurs, professionals, artists, programmers, or…?

  • should the OF core be readable? to what degree?

  • should you be able to learn C++ by reading OF code? how about reading the OF core?

  • what would a 1.0 release of OF look like? how about a 2.0 release?

  • how important is platform independencey?

  • what’s the difference between the core and core addons?

  • what is the metric for whether something should be in the core or not?

  • what’s the idea behind addons?

  • how closely tied to C/C++ is OF? would it ever be like processing and compile into javascript too?

  • how are decisions made in the OF community?

  • when you have to make a decision between requiring people to write simple code vs complex powerful code, which side does OF fall on?

  • is OF going to continually add new methods and functions, or will there be some kind of stasis eventually?

  • is it better to add a method in the one place you need it, or at a root level where it can be inherited? e.g., compare ofImage_::setAnchorPercent to ofBaseHasPixels::getPixels

  • what is the role of abstract types like ofBaseHasPixels in OF? what is the code design principle determining their hierarchy?

  • how is memory allocation handled in OF? should things return data, should methods act on objects instantiated by the user, or something else?

  • is OF more functional or object oriented? (using these words as shorthand for ofLoadImage vs ofImage::loadImage)

  • why is setup() used instead of the constructor functions?

  • when does OF use pointers vs references? and how are the get*Ref() functions supposed to work?

please add more everyone! what were some things that confused you about OF when you got started?

also, it’s more clear now that i wrote this out: there are some higher level things that need to be discussed (students or programmers?), and maybe another document including all the lower level things (pointers and references).