Community and *.tiki.org site organization

Community and *.tiki.org site organization

Uhm, Devel Guys!

posts: 8 United States

Okay, I'm not telling anyone how to do things, this is just a friendly suggestion...

Just so everyone knows a little background on me, I've been involved with the BitchX project virtually since it started (I'm novalogic), I started Slashdot.org's Slashnet ircd, and I've been on a few other large projects.

I understand the pressure to release a new version, and put out new features so the project seems "alive and well", but there is a trade off with doing that, and Tikiwiki is suffering that trade off, bugs, and lots of them.

I'm not going to list them here, I will submit them to SF after I scroll through the list of 700 some odd ones that are listed in the tracker forum (perhaps they should be pruned when done, and listed as completed), at BitchX we actually created our own bug tracker which color codes submitted bugs, and lets people take the assignments. Red for undone, yellow for being worked on, green for finished, blue for unconfirmed.

But, if it was me, I would hold off on the release of 1.8 until everything was for sure done and fixed in the 1.7 releases. I actually rolled back from to 1.7 due to annoying highly visible bugs on a site that I'm working with. One is the forum bug which is very annoying (see other posts in.this forum)

Now, I've implemented major releases (x.N) that contained minor release fixes (i.e. bugs) but the fact that broke allot of things that worked fine in 1.7.1 says that much more pre-release testing is needed.

Tikiwiki is a wonderful project! There is no doubt that it’s the best thing out there for what it dose! But slow down a little, use the limited resources that you have to improve the quality control, and spend less time on adding new features. Everyone is going to ask for a new feature, and people will use your software even if it’s lacking a bell or whistle here or there...

However, they will not deploy a product that has allot of bugs, most of all visible ones. Its hard for a site admin to deal with back-end bugs, but theme errors which end users can see, and do complain about, is just embarrassing.

And test everything that has anything to do with something you change. If the shoutbox is changed, test the live support too, they are both modules that use the side menus. never know, a missing can cause problems in very weird places.

I hope noone takes this the wrong way, it’s just based on the impression I get from the way things have been progressing, and from past experience... I'm really looking forward to 1.8!

Thomas J. Burnham

posts: 224 Ireland

Hi Thomas,

You have a valid point which I very much support. I have suggested the same thing in the past on the development mailing list. I really believe Tiki 1.8 should contain no new features but plenty of bug fixes and performance enhancements. I agree that the rush of getting a new release out very often and stuffing the product with new features all the time is getting a little bit out of hand. Especially, the somewhat uncontrolled manner of integrating 3rd party products into Tiki (HawHaw, Jgraphpad, PhpOpenTracker) etc comes with potential dangers. Co-operation between open-source projects is great but only when it has really been thought through properly.

In the end I would vote for a release mode like the Linux kernel has with an alternating experimental and stable release.



posts: 7 Australia

I agree too .. starting to get into doing some code with Tiki but it is too much of a moving target.

A number of things are missing in the features that have been made available. I switched from phpBB + add-ons because I liked the integration but missing forum features like;

  1. Read New Messages
  2. Mark All Read

Are major disappointments, do not get me wrong I love Tiki and I am going to try and help make it better too!

What is necessary is that the existing stuff be done, the bugs be done and new stuff be done .. we all have 40 hours dayz don't we eek seriously though adding stuff is only one of the things that need to be done.

As for bugs, I have fixed a couple but looking at that bug list I generally go do something else every time I look at it.

Mose, how about this .. I use Mantis for my bug tracking, should 'we' developers have a task/bug tracker that 'we' move stuff from the main areas, non-developers can see the thing but not mangle it and as things are added to the 'official' list they are removed (or noted prefer ####) on the sourceforge one?

Cheers Larry