This document fixes the feature set of what we can accomplish in this time. After Beijing the CairoRelease is scheduled to arrive in mid 2003.

Lesser wanted features (i.e. feature requests where code changes are difficult and the requester has not contributed code) are less likely to be implemented in the near future. Moral: get someone to code your change and make it available in a way that is easily incorporated by the CoreTeam.

Strategy

TWiki is already a well advanced collaboration platform. New releases should be in line with the TWikiMission as outlined in ReadmeFirst. The Beijing Release should focus on pushing the envelop in giving broad corporate appeal, without sacrificing the guidelines. Important key areas are the plugins and skins.

Focus for Beijing Release:

Evolutionaly add smaller features and fix defects while keeping the product on a stable level.

"Nice to Have" List

All: Please add other features you would like to see in the Beijing Release. The CoreTeam will evaluate what is possible. Also see category topics DocsToDo and FeatureToDo for potential items of interest.

But even without that, what we already have, TWiki deserves new release.Can I ask (beg) CoreTeam to add possibly some ready patches, and roll out BeijingRelease?Pretty please? Who is with me? We want BeijingRelease!

At two releases per year, we are going to make the other one hard work at this rate.

Perhaps the core team is overstretched? Maybe it is time to introduce a shared responsibility for releases? CoreTeam - if people offered to take this responsibility, would you accept? What would the work entail, is the process documented and how much effort would you reckon for this release?

To have SimplerDefaultTemplates will be excellent! Many newcomers (like me ) also complain that topic should be renamed to page and web to anything, like maybe zone (RenameWebToZone). IMHO it may increase appeal and help to get buy-in. It might be good time to settle page/topic and web/zone issue now, because we (I can volunteer time for it now) will need to review all docs and refer to action links on new, simpler templates. It looks to me that CoreTeam is reluctant to get involved into this discussion?

All this focus on appearance (SimplerDefaultTemplates, EnhancedSkinHandling) doesn't seem (that) important to at least 1 user. I'm having problems getting serious uptake of twiki as a part of our systems (more than getting users to enter content) by being able to confidently say - yep, I can do that on the wiki. "Do that" usually means to do something a bit more sophisticated re. content organisation that a free-form wiki. To do this SearchWithAnd and FormattedSearchWithNesting are essential. Treat this as a (completely selfish )vote for release soon - drop features.

Rather than getting BeijingRelease out the door, maybe a new Beta could be released. The reason
I am asking is that there have been changes (well at least one change, ConfigurableLogoadd RenameTestWebToSandboxWeb to the list --JohnRouillard 30Jul2002)
to TWiki in TWikiAlphaRelease
that needs corresponding changes in the TWiki web and pub files. I have been trying to track
all the changes and pull them from twiki.org, but my new twiki still isn't configured quite right.

Alternatively, is there someway to get the files in pub and TWiki web that correspond
to the current TWikiAlphaRelease?

How far is to to next BETA? I would like to install TWiki on my mm-void.sf.net tommorow
(including some of the plugins for DMOZ and discussions),
but I can wait an extra week if this would give me some of the new features.
Peter any esstimates???

SettingLibPath is now in CVS - seems to work for the testing that I've done, but since the code is the same for all scripts it shouldn't cause problems. The view script on donkin.org has been using it for months anyway ...

Agree with MartinCleaver. It is better to have a less feature-rich release with more regularity than getting all the features in. There is no harm in deferring features if we can agree to make releases more regularly. Every half year seems to be a good interval, given the rate of change I have observed.

Hi all, sorry for being late on this one, I am in Indonesia where the Internet Cafes are few and far between, the connections often bad and the cost expensive It's a nice place though and well worth a visit.

As promised, I have cut out any item that I'd previously marked as a DeferToCairoCandidate. I know that this will disappoint some and possibly annoy others but several changes have been made to the alpha and have been proven on TWiki.org that would benefit many and there doesn't seem a lot of point holding back this release just because the other objectives were not met.

It does seem a shame that Beijing Release didn't fulfil on its main objectives, which were:

EnhancedSkinHandling where installed skins can be listed; and where we offer a few skins (bare bone, c2, graphical...)

Please take a look at the completion stats for tables above showing the cut-back feature set and comment if you think there is anything else that can be usefully delayed. If we are all set then it will be down to the CoreTeam to create a beta for widespread testing.

Also, we say we are adding the CommentPlugin to the core, I presume and hope this doesn't mean stopping making it a plugin? I think it would be clearer to talk about the 'standard distribution' or standard bundle, I recall seeing this mentioned elsewhere.

TWikiBetaRelease: All users who signed up for the twiki-dev mailing list are informed where to get the latest beta, currently 03 Aug 2002 as indicated in the DevelopersNews. People not on the list can request the Beta as usual using the download form.

Cut features: Martin, I appreciate your enthusiasm and your help in expediating the release, but directions should be agreed on with the CoreTeam. I agree that we should cut features in order to speed up the release. However, the docs are currently way back. While the docs are being updated we can bring in some high priority feature enhancements. The one we should work on in a limited way is EnhancedPluginHandling. We should defer all other major ones like EnhancedSkinHandling.

Adding the CommentPlugin to the core: Once the Plugin is stabilized we can add the Plugin to the core (not BeijingRelease). It will remain a Plugin but will be included in the release, same as the InterwikiPlugin.

WRT Adding the CommentPlugin to the core: My comment was about the use of the terminology 'Core'. I think 'Core' should be distinct from 'standard bundle' where 'standard bundle' refers to core + plugins et al that is released in each TWikiRelease. Such a definition of Core thus excludes standard plugins such as InterwikiPlugin and CommentPlugin

Not sure if it is too late for new requests for inclusion now - probably, if the aim is to release by the end of Q3 - but I'd like to see the OmittingEmailInWebNotify patch added so users can just add their username to WebNotify rather than having to add name + email address. I've been running with this patch for a couple of weeks and it works well.

As an aside, not entering the email addresses is also a useful (if minor) anti-spam protection on public sites as you don't want a lot of email addresses on a single web page - the current Codev.WebNotify page here for example would be very easy to harvest for addresses.

Not sure if it is too late for new requests for inclusion now... there have been many complaints about the placement of the form change button, see ChooseFormButtonIssues and FormChooserPosition. I have made some minor modifications that move that button next to the "Preview Changes" button, and serve as either "Change form" or "Add form" button, depending on whether a form is not present or not, see MoveFormButton. I believe this is cleaner from a user interface point of view (button in the same place in both situations), and leads to less likelihood that a user mistakes that button for the preview button...

I'd be willing to produce the patch (now done against verison on SourceForge as of 10 Nov 2002, see MoveFormButton) and do the necessary testing if instructed as to what the threshold of acceptability is. This is installed at our internal TWiki.... There are no backwards compatability issues...

I don't know who you are (and I guess you don't want to be known), but a comment like the above is not appropriate. The developers (and I am not one -- a wannabee, maybe, after I learn Perl) are all volunteers, and do this work in their spare time, with various motivations.

If you want releases more often, help in some way. Learn to program, or, there are ways to help if you can't / don't want to program. I don't know all those ways, the developers can surely suggest some -- maybe test some of the alpha or beta releases.

Here's a suggestion -- offer a cash reward for the next release, or for some specific feature (or start a reward pool).

Well, on balance, TWiki's aims include having two releases a year, and the last 12 months have yielded none; the AthensRelease was Dec 2001, BeijingRelease is scheduled Jan2003. So, ironically, the anonymous comment above is wrong.

Why the lag? The aim I stated in July to get a release out mid-year was not agreed by the core team and enough people seem happy with that to not make it a major issue (though there were some voices from people agreeing that a new release would have been nice). In the last few months, a process to make the TWikiBetaReleases more widely available has been put in place, I guess this addresses most peoples' wants.

My main concern now concurs with JohnCavanaugh's comment on EnhancedPluginHandling, that the spec for that feature is not properly discussed, let alone settled, coded or documented. I'd like to see progress on that to be comfortable that the 2003 release is going to meet its schedule.

I agree with Randy - the CoreTeam is only a few people, all of whom are quite busy in other ways. If there were more and higher quality patches (see PatchGuidelines) to the core code, following the core code style and providing general solutions not just quick hacks, the development could well go a lot faster. Also, submitting a lot of good patches is a sure way to risk getting invited onto the CoreTeam ...

Working on documentation is very useful and will help get releases out more quickly - if you can understand a new feature by reading the discussion page and testing it in TWikiAlphaRelease, why not head over to TWiki:TWiki and add its documentation in the appropriate place? If you aren't sure where to do this, comment on the doc page itself or on the feature page.

Testing is also very useful - particularly when BugReports are well written and easily reproduced, and ideally come with a good-quality patch ... TWikiAlphaReleases are now freely downloadable, and you can get a TWikiBetaRelease very easily by submitting the download form (link on TWikiBetaRelease) and saying you want to test betas.

As Randy said, not being able to code is no excuse for not contributing!

As (quoting Peter) only safe code changes should be done, why not just drop it and get BeijingRelease out the door?

I see nothing wrong with not finishing all that we intended. If we can move on we can celebrate getting the internationalisation changes out, everyone's production systems onto a new version and start afresh at features we are not ready to complete yet.

I've said ScriptToCreateNewWeb is 50% complete. There are instructions but they are not consistant as how to create a new web appears multiple times in different places. It would be helpful if someone could turn AddingANewWeb into a page of its own and update the references.

I noticed that Plugins points to a TWiki web topic TWiki.TWikiAddOns that doesn't exist. I added it to the "Nice To Have" set. Since it's a document I didn't know whether to put the CVS at 100% or not.

Why I am asking for this? We all know that Twiki is not as easy to install as it should. And we can see many would-be admins struggling with Twiki nstallation. So why in this struggle not install them many nice features they might want to install later anyway? Plugins might be copied in proper places, ready to be activated. Maybe disabled - but easy to enable if needed.

The TWiki production release currently has three Plugins preinstalled: EmptyPlugin, DefaultPlugin and InterwikiPlugin. Over time we can add additional Plugins. However, I do not see the value of adding many Plugins, since (1) Plugin installation is simple, (2) each installed Plugin degrades the performance by a few percent, and (3) preinstalled Plugins will be outdated by the time a release comes out because Plugins evolve quickly.

I think it's a great idea to include some of the common plugins by default, pre-configured and ready to go. (1) I think you over-estimate the skills and/or the "percieved ease of install" of many folks installing TWiki!, (2) I suspect the percieved value will be incredibly high compared to performance changes, and (3) having functionality (even if upgrades are needed) is WAY better then not having them, especially in the beginning when people don't know what a plugin, skin or addon is. I commonly hear that TWiki is tough to install, but I rarely if ever hear that installers need more flexibility.

I can imagine different plugins would be included for different reasons. Perhaps this would be a good discussion to begin evolving on the Plugins web unless you just want to decide right now for Beijing and not worry about designing a feedback process. Now that I write this, I think we just need to get a release out ASAP. I look forward to seeing a best-practice for voting!

Please note that I am aware about possible performance impact of plugins. I asked plugins be packed into distribution (so all pieces will be placed in proper places when installing), but disabled it TWikiPreferences page. Then admin can enable what she needs, without all the pain. If old stable version is enough, no additional effort is needed. Or, if she decides to upgrade, at least there are files in place to guide what needs replacement.

Please do not underestimate anxiety of a windows person typing first time tar -xvf. I know what I am talking about. Deleting plugin name in list of disabled plugins is much simpler - trust me.

JohnT and PeterT - can you please confirm for me that RcsLite is ready for this release? It looks like I have to use it for the TWikiOnDebian package for security reasons (twiki files should be owned consistently by twikidat not apache user)

The latest ETA from PeterThoeny for a release is still (very) late January! If you have the time an inclination (and know English pretty well ), please take a look at the status above and help out with documentation for the remaining items this week.

I am declaring InternationalisationEnhancements complete - the only missing parts are quite esoteric and can be fixed at a later date if anyone actually notices them. This code has been running for some time at http://donkin.org/ with I18N enabled, and at TWiki.org without I18N, so it is reasonably stable IMO.

As for the docs for the remaining bits, I am unlikely to get any time at all for these in the next week or two, due to change of role at work and integration with another company, resulting in very long working days - so I would like to invite anyone interested to start writing the docs for this, RefreshEditPage and BackFromPreviewLosesText There is already a lot of documentation for these issues in the relevant pages and TWiki.cfg, it's mainly editing into TWiki:TWiki docs - I suggest: