Would you consider to make a XenForo version? (Kier Darby's new forum software)

**pegasus** · October 12, 2010

I believe it was at 83% while the VaultWiki 4 stuff didn't have its own milestone. So combined with all the thousands of completed VaultWiki 3 items, it was up to 83%.

It's my belief that the first ~30% will take the longest time and will account for ~80% of the workload, just because they are the foundation that needs to be rock solid.

For those who aren't aware, I'm sure there are other links in other threads, but this is the progress bar we're all discussing: http://www.vaultwiki.org/milestones/9/

The list isn't necessarily complete. It's likely that many large items will be broken up into multiple tasks as we address them.

**sKippah** · November 28, 2010

Ya. now its "just" 29% Completed

**InformationNirvana** · December 17, 2010

A good wiki for xenforo has a bright future.
A simplified version of vaultwiki would be ideal.
Very simplified.

**Alfa1** · December 18, 2010

Simplified in what sense? Less features? (i.e. more difficult to the end user) Or making the User Interface simpler to use to the end user? (i.e. expanding the UI in this sense)

**pegasus** · December 18, 2010

Whenever he brings up this point, he tends to imply the "less features" part. Personally I feel:
more features + better UI = easier to use + less confusing

Historically we had some problems getting the UI right and I think we just started to this year:

"Add new chapter" button in books
comments below the article
settings to change forum header locations, rather than basing it on naming conventions

There's still a lot of work to do, like:

reducing the number of steps to add reusable images
making the admincp feel like it all works together

But these are issues we're already addressing in VaultWiki 4. Work is slow, because we have to rewrite EVERYTHING, but it's coming along.

**InformationNirvana** · December 28, 2010

inline editing would be a smart move.
adminCP ? Only as a last resort where inline editing wouldn't work.

I just read a new poster that was confused about Books.
They are oddly confusing.

vaultwiki targets the hard core wiki needs. That's a small market vs. the "We need a few documents and a Manual" market.

To make a good forum documentation Tool (wiki) you can't start with Mediawiki in mind, you have to start with the Forum. Porting the current mediawiki-like vaultwiki to xenforo will be met with the same end user confusion.

The wiki demo page here - http://www.vaultwiki.org/demo/ is not what people want or need.
When I look at that demo, it doesn't jump out at me and say ... I want that on my site !
It looks like a mess that I don't want.

Why isn't this the demo page ? http://www.vaultwiki.org/demo/Main-Page

I have heard of some progress like getting rid of NameSpaces.
I also like the new Vaultwiki Manual.
I hope it's easy to create the same effect.

Here's a Mockup of what I suggested.

thread - http://www.vaultwiki.org/threads/2393/

The point of the wiki is to make it easy for users to create content.
That should be the starting point.
Very few users can edit Mediawiki.
Vaultwiki is too hard to administer and edit.

**Moses** · December 29, 2010

Originally Posted by pegasus

For those who aren't aware, I'm sure there are other links in other threads, but this is the progress bar we're all discussing: http://www.vaultwiki.org/milestones/9/

The list isn't necessarily complete. It's likely that many large items will be broken up into multiple tasks as we address them.

Hi Pegasus,
What is the anticipated date for 4? I notice the milestone is 25/12 but expect this has slipped.

**pegasus** · January 1, 2011

We are working diligently in making a new release that performs better, is easier to use, and contains at least the same features while at the same time making the code abstract enough that it works under different platforms and coding styles. This is an unprecedented undertaking for us so it is nearly impossible to make an estimate based on previous major release development experience.

We wrote VaultWiki from scratch with version 2. It took less than 3 months (March - Jun 2008) but the feature set was still very small at the time and we only had 1 platform to code for (vBulletin 3.7).

Probably more relevant is the release of version 3. This release was for multiple platforms (vBulletin 3.6,7,8 and vBulletin 4) but the code between these were very similar. We originally intended to release version 3 in July 2009, but Beta 1 wasn't released until December 2009. Most of our delay was a result of vBulletin 4 being delayed 4 months.

In the case of VaultWiki 4, we aren't waiting on any new product to be released, so an estimate of 6 months after our first target (12/15) for a beta is probably extremely lax. Most of the delay this time has been simply that there are fewer working days between Thanksgiving and New Years compared to normal months, and due to the large amounts of restructuring the company has been doing since September.

We have to keep in mind that 4 is a complete rewrite, not a gradual refactoring over time. It's simply not possible to do part of a conversion in the interest of time and release it. The software just wouldn't work. That said, I think that if we try to refrain from adding too many new features into the first beta and just focus on perfecting the core and converting most existing features, then we should be able to have beta 1 in February.

XenForo support would be added as part of Beta 2 along with some User Experience improvements.
In Beta 3, we'll be adding IP.Board support and starting on the new features.

We do intend to have the current Feature Request list cleared out by the time version 4 goes Gold. We expect to keep up our normal release schedule of ~3 weeks once we get a beta finished.

**Moses** · January 2, 2011

Thanks for the update pegasus,
I'm not impatient or putting any pressure to rush a release, and realise all to well the impact of corporate restructure on projects.
I am just interested in which date you are tracking to so I can roughly outline my own roadmap.