This is a TODO list of improvements I’d like to see in this branch of Instiki. You might also want to look at the Known Bugs page. They need work, too.
If you’re interested in working on any of these topics, set yourself up with BZR, do a
% bzr pull http://golem.ph.utexas.edu/~distler/code/instiki/svn/and start hacking away. Send me an email, when you’ve gotten somewhere, and I’ll pull the changes from your BZR repository.
Rails 3 was released a year ago. There are a lot of changes in Rails 3, so it’s a nontrivial task to port Instiki to it.
On the other hand, implementing Themes-support looks quite easy for a Rails3 application. That would be a very nice payoff for a Rails3 Port.
Rails 3.1 is nearing completion. Among its many cool features is revamped support for engines. Previously, that seemed pretty awkward. But now, embedding Heterotic Beast in Instiki, and getting real discussion pages seems quite doable.
There are a few remaining LaTeX macros which would need to be defined to support the various itex commands that are not part of standard LaTeX. See the the preamble in the LaTeX template, app/views/wiki/tex.rhtml.
The LaTeX export is a (Markdown+itex)→LaTeX conversion. It does not know anything about Wiki syntax. Changing this would be a nontrivial task.
The Instiki Sanitizer is very thorough but it, too, is no speed-champ. Borrowing the tokenizer from libxml2 (say) would speed it up a lot.
Currently, Instiki’s access controls are quite primitive. It uses plaintext passwords to protect entire Webs. It doesn’t have any notion of “users”, nor any sort of more fine-grained access-control that might be afforded to authenticated users.
Of course, you can always use Passenger or proxy Instiki through Apache. Then you could avail yourself of Apache’s authentication and access-controls. But that’s not nearly so user-friendly.
Perhaps some combination of restful_authentication and openid_authentication might be helpful (though I prefer digest authentication to using passwords).
Sometimes, when you have more than one wiki-webs, you start a page on one wiki-web, and end up with wishing you had put it in another wiki-web? Now imagine at the footer of every page there was a move action, to move the page to another wiki while maintaining page history. If there is a conflict (page name collision) refuse.
An option to search all wiki-webs (eg: with a keyword IN:ALL?)