Join us on GitHub at
https://github.com/Approach/Approach

If you're interested, please feel free to e-mail the project lead directly via garet AT approach.im

We can use help with documenting, making basic components, web design, code review and more.

There are places you can help at any skill levels.

Also, if you're highly capable in a particular language and you'd like to see Approach reach it faster, we can help you get it started.

If you can read code, you can help document many aspects of Approach. This will help us more than we can express!

We can really use graphics and style templates. We'd like to one day provide our users with a large library of ready-to-go components.

From the smallest icons, to unique user interface ideas to full on interface layouts - graphic and designs are a tremendous help for us dev-heads. =]

Similar to graphic designs. In the background, our private contributors are expressing a strong interest in using Approach as the front-end of a new game engine. We happen to have a rendering toolchain available with which to couple it. Any contributions providing them more open material will help bring this aspect of the project into the open community faster.

We can always use new concepts for Components. In general, for web apps, Components any group of elements that come together to do some task or show some particular view of information.

Some examples of common components in web applications:
- Video Players
- Calendars
- User sign up form
- Sidebar Ads
- 'Widgets'

Approach generates control logic and interfaces for all Components natively, so not all Components need to be useful as display elements and more esoteric varieties are also welcome.

We can use ideas for web components very quickly but also welcome concepts for game, desktop, mobile and physical device interfaces.

We need a version of one of our core classes - Renderable - which works for rendering JSON objects. Such a class has been hacked up in C# but remains largely untested.

We are especially looking for this in C++ and PHP. All three languages have an XML Renderable class to go off of.

We need to make the Dataset class more flexible and support better, generalized queries. We'd like to work with anyone involved in this very directly.

Currently Dataset class has manual support for many awesome things like connecting to NoSQL and SQL databases, being a super-safe container for making generic function arguments, binding to system data, automatic de-aggregation and more, using flat or nested containers and more.

Some of this has been automated already actually, but we want this to work for more generic cases and come up with a good standard to supply tech-specific connectors. (Such as a MySQL Connector, a Redis Connector, a Postgres Connector, etc)

We've come up with a way of writing AJAX-driven applications using only HTML. (Not without JavaScript running of course)

Using the Approach Command Client library, people can learn HTML in be writing advanced data flow faster than ever before. We are exploring a method of implementing web intents through a different model than currently described on W3C.

Approach had a really neat way of creating client-side events from the server side. It is currently disabled as it's core code was written in a flurry and represents the least clean code in the project. With some cleanup this could be re-enabled allowing users to use jQuery style semantics such as:

myRenderable.on('click', someFunction)

from the server-side, which is cool.

We have also removed the usage of our template parser for most releases due to the use of eval to provide some level of logic in template code. Previously the parser was also very slow, but this has since been corrected.

We'd like to come up with a simple way of allowing basic logic into view templates, which are basically HTML blocks with bound tokens available (when writing for web).