Suggestions about the future of Wikka
Some background
I first came to WikkaWiki before quite some years looking for a wiki solution for the PtokaX Direct Connect Hub. I witnessed a good amount of activity, large enough to make me want to contribute.
My need to contribute to this newly-found coding community drove me enough to start learn PHP to the point I got some actions contributed.
Then after a summer of contributions my life undertook some changes and I did not feel like using a wiki, whenever Wikka crossed my mind I always checked the site to see how it is developing.
Lately I needed a wiki solution for a community of Greek professionals. First on my mind was WikkaWiki I downloaded, saw that things were basically more or less the same since 1.12 (ok, excuse me I know some stuff where better).
I gave MediaWiki a try and I (still find) found it too cumbersome and requiring too much activity and moderation for a community to have a proper wiki with it.
While I found WikkaWiki a bit stale, I did want to see some code and read through it. I saw the issue tracker site, I noticed some directions (for example for the 1.3 milestone) and some efforts for doing i18n, implementing utf8, user groups, templates, etc. What made sad was that there was no change on the way that WikkaWiki was doing things as far as code is concerned. Having meddled with some PHP projects ever since and read / practiced / experimented with a lot of things PHP last two years I find that the code is a filthy place. It is obvious that there hasn't been a code review for ages, which leads to fragmented and non uniform nor unified approaches to regular web application problems.
The website
The separation of the wikkawiki content and the documentation is a good move, done in a bad way.
In general there needs to be a good way to clean up all the information of the wikkawiki site and just keep what is valid and up to date.
In my opinion:
- www.wikkawiki.org should give wikka related information (history, markup, requirements,...),
- docs.wikkawiki.org should give the wikka how to information
- code.wikkawiki.org should give the developers information,
- dev.wikkawiki.org should point to the development site.
The proposal
I want to stir things up a bit by talking about a WikkaWiki Code revamp. Basically a rewrite, tearing all ties with the history, making the Wikka name comparable and an active player in the Wiki scene all over the internet.
The development team should
- Move to Git (gitorious.org, github.com, sourceforge.com)
- Use that infrastructure to manage issues and track development
- Clean the current source and release a stable frozen 1.2.x release
- Decide on the code structure and the program flow start rewriting Wikka2
- At first Wikka2 release start writing importers from other wikis, older WikkaWiki versions and other input.
The code needs to start using
- Models,
- Controllers,
- Views,
- Templates,
- I18n,
- OAuth
- Unicode,
- Input validation,
- Storage system (PDO, flat-file),
- Alternative parsers (markdown, mediawiki, texitle),
- Plugins
In addition:
- remove the WikiName limitation
- use a Javascript code highlighter,
- implement WikiCreole wiki syntax as the default wiki syntax (with minor additions for custom needs),
- scrap the Freemind action and provide it as an extra Plugin,
- strive to be more standards compliant by filtering the XHTML output with a XHMTL filter class, provided as extra plugin,
- join the jQuery bandwagon for indulging the wonderful jquery plugins, provided as extra plugin,
- use Minify to save bandwidth, provided as extra plugin,
I know this is all too much. But without those decisions and directions, the WikkaWiki is destined to grow dead unmaintained and behind of the times.
Give your input, lets discuss about this.
After notes
I noticed that a sourceforge project already exists, good, although crippled badly.Appearing active from within sourceforge can help push the exposure to potential developers and users.
Lets make sure that Wikka gets the most out of it.
Move the SVN there, move the bug tracker there (they can too host a Trac), setup the webhosting facility, so that can be done.
Please do check WikkaFutureCoreInteractions
CategoryDevelopmentSuggestions
Perhaps it might be more time-efficient on your part to fork WikkaWiki. You seem to have many ideas that aren't exactly aligned with the history or future plans for WikkaWiki. For instance, in keeping with WikkaWiki philosophy, we chose to remove JS from the codebase. Yet, you suggest many ideas that would bring JS back into the codebase.
I find this comment interesting:
"I gave MediaWiki a try and I (still find) found it too cumbersome and requiring too much activity and moderation for a community to have a proper wiki with it."
Precisely the reason why we strive to keep WikkaWiki accessible and free from unnecessary clutter in the core.
I might suggest a more thorough review of the history of WikkaWiki and re-evaluate some of your goals in terms of the WikkaWiki philosophy.
BTW, I do not speak on behalf of the other Wikka devs. This is my opinion; I'm sure the other devs will chime in with their own.
Object Oriented Programming in PHP is hardly a 'clutter in the core'.
It is being used to manage code effectively.
Not only that. It also enhances and focuses teamwork.
It gives ground for the recruitment of new developers with specific skills since the separation of concerns principle is set to effect throughout the code.
In specific the MVC design pattern has grown mature and proven for web applications. Check WikkaFutureCoreInteractions.
Maybe I am wrong about the Javascript part, but let me defend it.
Javascript is a great user-experience enhancer if used correctly. WikkaWiki needs more acceptance == new users. In order to make it better for them it should make the user experience as good as possible. Usability doesn't come only with the page layout and design, it comes from a clear design for the whole user experience.
It comes from setting up user cases for the various functionality of the WikkaWiki and analyze them, find ways to make them better.
Do not get me wrong for being defensive on your opinion, I am here writing this because I know that the community has potential. I do not want to "take over" or "run things my way", I want to contribute to the best WikkaWiki there can be.
The history of the WikkaWiki is a sympathetic one, 2002 - 2010 = 8 yrs. Look at what the web was 8 years ago and what it is now. WikkaWiki still has a dim chance to get good on this new setting only if it changes and evolves both in philosophy and goals. Forking out a new wiki that has just a typical ancenstry relation to some wiki engine is no news to todays internet. Evolving an open source wiki project that has 6+ years under its belt can mount some good publicity. Thanks for the time you took to write this comment, please consider my arguments before you dismiss them.
There are people out there who use Wikka as an in-game wiki engine or (as I discovered recently) as a wiki engine embedded in a tool for 3D surgical simulation (!): making core functionality depend on JS will make most of these uses impossible. Also, no matter where you position yourself in the SVN vs Git debate, moving several people to another RCS is a lot of work as DotMG noted, no matter how easy the migration of a repository is. I wish I were more involved myself with Wikka at the moment to be able to give some substantial feedback on the points discussed above. However my general feeling is that you would do a better job by tackling these issues on an individual basis and by discussing their pros and cons rather than presenting your proposal as a package that the dev team should buy as a whole and unconditionally to save Wikka from "growing dead". We have seen attempts in the past at building single-handedly a whole new codebase without discussing pros and cons with the other devs, with the result that the code in trunk is even messier than it was before. That's one of the reasons why the main development line is derived from 1.2 and not from trunk.
My 2 cents.