Along with the Issue Tracker, we have a wiki. I made a start on the main page by creating a table of contents with pages that I thought might be useful. I haven’t created any of those pages as yet, though.
It’s a wiki, so edit and add stuff. I recommend that major changes be logged in the forum here (if the wiki takes off, maybe we should have a wiki-specific category).
I added an “OtherResources” page, and copied the FAQ over.
I am also thinking of adding a “projects” page, where people can put a link in to their projects that they’re sharing - the forum here is getting difficult to find things in.
At first there will be a flurry of updates as we get the structure down and add the intial content together. As far as my default personal style, I tend towards frequent small updates with small (expect for lists) which means many pages. Whatever styles or recommendations are made here, I’ll follow. For instance I’ll stick with the TOC mentioned above. However, I think I will add some kind of “how to contribute” link to the TOC. It wasn’t obvious that one had to join to be able to edit. I’ll keep the forum updated what I’m up to. As you say, after a time, we won’t need the forum for day to day coordination.
If I understand correctly, this is a limited wiki. I can’t appear to access updated that I’ve made that we’re removed by others at my level of access.
I’ve gotten as far as I want to go without things being discussed…
Questions mainly for TwoLivesLeft…
Will "changeset"s be visible to link to from the wiki?
Do you have access to restore old wiki pages?
Would you prefer the forum be scrapped for improvements from the past (many of which have been fixed) {it would help to link to the single character project name from where it is mentioned in the FAQ} [as a side note, would you be opposed to an #occupyapple to get your release pushed though? :!! ]
Questions mainly for everyone…
Should the voice of the FAQ be changed from we (twolivesleft) to twolivesleft?
Should the FAQ be split across the TOC, some TOC items removed that are in the FAQ, or double link to details from both?
Should all the user examples from the forums have a place in the wiki (as a link)?
Are we ready to create a ToDo?
My two cents is that the more we get into the wiki, the better well be, especially at first. As the active user base grows, things like voice will bug some more than others, and they’ll fix it.
I would like to see a page there with the devs future intent - no guarantees, of course, but a list of requested features as they understand them, along with “upcoming” or “planned” or “will not do”, and perhaps reasons, would help eliminate some churn in the forums. Perhaps that’s in the issue tracker, dunno.
I do plan on putting my own stuff up in the wiki, both in some sort of project list, and on a “personal page”. Knowing something about the others here humanizes them and may reduce friction.
I made a start on the “Getting Started” with a short program. I couldn’t get the hang of the formatting (particularly putting code inside a list), and I need to add screenshots once I get them off my iPad.
My intention was then to have a bit on how Codea builds up an animation, I started it, but then I was going to put something about the frame buffering only I couldn’t get it straight with some simple examples! So I (or someone) needs to figure out some straightforward examples that show the frame buffering in action and how to get round it.
The frame buffering will be much easier to fix in the update after next, there is a call which will turn it into something like single buffering. It slows the iPad 1 down a lot though.
I like the idea of putting our plans, and general philosophy when it comes to feature requests up on the wiki.
@ipda
Im not sure what you mean by “changesets”. If you mean the git commits, we intend to keep that closed for now, with a plan to open up the backend and release a demo game with source code that uses it. This could be a while though.
Its probably a good idea to put any interesting nuggets you find on the forums into the wiki. I’m not sure what you mean by #occupyapple.
changesets - are something referred to in the bitbucket wiki that can be linked to, I assumed that they mean builds or releases but am not familiar with bitbucket.
(#occupyapple - a puerile reference to #ows to get apple to approve the next codea release 
)
Ah, I thought you were referring to #ows, but didnt know how it related 
Changesets would refer to git commits, which we aren’t exposing publicly for now, so they probably won’t be too useful.
The wiki syntax is extremely restrictive as far as I can see; in particular, I can’t see how to have more than one paragraph in a list (<br/> just ain’t the same). Making a virtue out of a necessity, I’ve put the initial tutorial on its own page and used headers instead of list elements.
I’ve also listed a load of other tutorials that I think would be good to have.
Relinked parameters back into the new structure
I’ve added screenshots to the first tutorial, and the “full code” (not that there was a lot!).
NB I just uploaded the screenshots to picassa and then linked them. I’m not sure what the best solution is for having screenshots to ensure that they persist.
Second tutorial https://bitbucket.org/TwoLivesLeft/codea/wiki/AnimationTutorial
Very nice tutorials! With regards to the images, I will look at re-hosting them on twolivesleft.com and re-linking them in the wiki.
I’ve added a page for user libraries https://bitbucket.org/TwoLivesLeft/codea/wiki/Libraries
@Andrew looks great
The last code snippet has the same as the prior one
ellipse(WIDTH/2,HEIGHT/2,100) should be ellipse(x,y,100) from earlier, yes?
Didn’t know if you wanted me to change it.
I think with https://bitbucket.org/TwoLivesLeft/codea/wiki/Parameter and https://bitbucket.org/TwoLivesLeft/codea/wiki/AnimationTutorial they are set up to understand the ellispe modes, parameters, and line examples in the application.
Should we submit a version of the lines example with comments?
Should we just point them back to the examples from the wiki?
I would be happy to include an improved example in the next version.
@Ipda41001: cut-and-paste error. You should feel free to change things, especially when they’re obvious like that.