CategoryStale
I created this topic using some of the discussion from
BeijingRelease to provide a working example of an
IndexedThreadedDiscussions. Please ignore the content of the headings I (completely arbitrarily) added to peoples comments. I just wanted to illustrate how comments could have a heading and did not try to accurately reflect your comments.
--
LynnwoodBrown - 08 Aug 2002
Feedback and requests -- PeterThoeny - 04 Dec 2001
Please add below. We need to decide on the strategy, feature set and schedule.
need for better/easier systems administration -- MichaelSparks - 28 Dec 2001
Some comments on the additions I've put above:
- We tend to use the enhanced definition list format for a number of things - but
one thing it's very useful for is meeting notes - action items, topic headings etc.
- The need for better/easier systems administration can't be underestimated if
increasing corporate appeal is the goal. Twiki as it stands is too "code hands
on" for systems administration of a Twiki server. The installer I've written
simplifies this rather dramatically to the extent that simplifies the case where
someone is performing authentication using LDAP is simply a matter of answering
a few simple questions.
- People who want to put lots of attachments on a TWiki server - eg exported
powerpoint presentations - photos from a party - customer supplied archives/files
tend to find the uploading one file at a time laborious. Zip files make life
a
lot simpler - but mean you have to download stuff to read it - which slows
things down, and prevents instant access.
We also use a modified TWiki syntax for headings that's much more email like - which
simplifies pasting emails & summarising emails into a TWiki page. Specifically something
more like:
_*Centred Level 1 Heading*_
__Level 1 Heading__
_Level 2 Heading_
*Level 3 Heading*
This does overload the twiki operators
again though, and I'd prefer to put these into
a plugin - but then this'd need
EnhancedPluginHandling. (Something which is definitely a
better route to go down than continually extending the core.)
Work-flow handling -- JohnRouillard - 01 Jan 2002
I think one thing needed for broad corporate appeal is the ability
to provide some form of workflow handling. I would like to see the ability for:
- controlling access lists by changing a form (requires processing the form prior to scanning for access lists).
- ability of plugins to access changes to forms and validate
these changes
- mechanism for returning the value of a piece of field metadata.
% META% should probably be extended so that % META{"ProcessStage" type="Field"} will return the value of the ProcessStage field item.
I have a particular requirement for approval process support
under TWiki.
Fix rename bug -- JohnRouillard - 01 Jan 2002
Also it would be nice to fix the bug with rename of a page
causing all pages linked to the renamed page to be
marked as changed. This is discussed in
DevOpinionPoll.
I really would like to see
RefreshEditPage included (i.e. fixing the 'second edit in session loses first edit's changes' problem), even if as a configurable option - I ran into this issue when training a new user with IE5 (which usually doesn't have this) and it's quite disconcerting. It should really be the default, so that TWiki works correctly with browsers such as Mozilla and Opera, not just IE5/6 - currently TWiki is barely usable with Opera because you need to hit Refresh all the time when editing a page. I have tested this patch with various browsers and it works fine.
Is it possible to include
VariableForCategoryDropdown to facilitate development of more dynamic search pages?
AdrianLynch attached plugin for rewiew in
VariableForCategoryDropdown topic. Thanks!
I'm happy to take a look at
VariableForCategoryDropdown and generally at the space of making more use of the
TWikiForm system. More shortly.
John,
I'm trying to puzzle out how to display the entries in a
TWikiForm as a bulleted list instead of a table. (Not very actively, yet -- and perhaps someone has already told me that it is possible and how to do it -- I just haven't (re)found it.) If it is not possible, I would appreciate it if you could make modifications to allow it.
Thanks!
do you want to put in the changes from
DefineUserTopicBeforeRegistration and
FileSystemNameClash ?
I noticed
MichaelSparks' post from late December commenting about the need for better attachment handling. Is this a good place to plug our
MultipleAttachmentsAtOnce post, which allows you upload a .zip file full of attachments, which then get unzipped and added as individual items?
We'd love it for it to go into the main codebase. Code's all there, just need someone to tell us how best to turn it over to your guys. Thanks!
Since I now have a good fix for
BackFromPreviewLosesText, I've added it to the above 'nice to have' table - see that page for details. The fix is quite simple, it just sets some extra HTTP headers for the Edit page, solving the problem quite cleanly and thereby avoiding loss of edits. I'd appreciate it if the
CoreTeam could review this for inclusion in the
BeijingRelease. It depends on the
RefreshEditPage changes to work well, but the code is separate.
Going back to the whole
MorePluginHooks issue - I've revamped that page with a few requests, and a simple
mechanism documenting what we have, what's been proposed, and why, whether they're accepted or rejected.
Specifically also the
BackFromPreviewLosesText details a problem that's essentially solved by adding extra headers
to do with last mod/expiry - but these can be changed based on included content - which is what the extra
preIncludeHandler hook is designed to help with. The nice side effect of this though is that this enables the "core code fix" to go into a plugin. The flip side to the same thing is at:
LastModifiedFieldOfHttpHeader . I've got one
small core diff to add in though for the hook.
The other nice thing this approach allows is for debugging of the system to be done through HTTP headers - the sample plugin for example dumps the last modified header & an X-TWiki-Date header so that we can compare & contrast whether the "correct" last modified header is getting dumped.
Combined with the
TopicVarsPlugin this gives all sorts of fun possibilities...
No plugins for browser bugs! -- RichardDonkin - 05 Feb 2002
I'm all for using plugins to add extra headers not needed by most installations, but the
BackFromPreviewLosesText problem relates to IE5/IE6, which are by far the most common web browsers on intranets (even though
MozillaBrowser works well) - IMO, TWiki should not require installing a plugin to work around this common browser bug. Perhaps there could be some core code to add the headers required for Edit, while a separate plugin does something similar to improve cacheability for View etc? Given that proxy caches are quite common on large intranets and have caused problems for TWiki users in the past (see
SavePreviewTextOnServer and
BrowserAndProxyCacheControl), it would seem reasonable to add the View cacheability headers to the core code as well, but that's a judgment call really.
Any interest in any of the stuff on
SimplerTWikiDistribution this time around?
I was thinking that the testenv script, which is tres cool, could actually relock the pages, since that really is a "setup time" thing and not a "ongoing maintenance" thing.
to Add corporate appeal
Since goal of this release is to
give TWiki broad corporate appeal, let's check if we can do first something called in managerspeak
easy winner:
- excellent CommentPlugin simplifies user contribution and lowers entry barrier to 0
- we have patch for create UserWeb for users, cleaning Main (or Hone) web
So I think we have enough nice simple features, and one important bug fix to warrant new release - easy winner. I understand you guys wound like to have better Plugin features and what not, but why postpone new version for that?
One additional feature what I would like to see for
broad corporate appeal is
ApprovingRegistrations, and maybe
ScriptToCreateNewWeb. But even without that, what we already have, TWiki
deserves new release.
Do not forget we need to agree on
SimplerDefaultTemplates and then modify documentation (
WelcomeGuest etc) accordingly. So this release will need broad changes in documentation (= time), while Plugin changes are more transparent for newbie.
Can I ask (beg)
CoreTeam to add possibly some ready patches, and roll out
BeijingRelease? Pretty please?
Who is with me? We want
BeijingRelease!
Feature creep -- RichardDonkin - 27 Feb 2002
I agree about a simpler TWiki distribution and with many of the feature requested, although of course feature creep is always an issue... It does seem to be hard to get the many great
TWikiPatches into the distribution, even when they are very localised bugfixes for data loss bugs such as
RefreshEditPage and
BackFromPreviewLosesText - however I'm not on CVS so for all I know they've been fixed on the email list... Presumably the
CoreTeam are just very busy?
I've also just written the
WindowsInstallCookbook, ported
testenv
to
ActivePerl and got it to provide more info (see
CookbookActivePerlTestenv), and fixed a long standing bug with
path_info
in
CobaltRaqInstall (applies to hosted environments as well, where they use cgiwrap, and to IIS). So I'm not just complaining, honest
Would it help if I volunteer to work on some of these bugs, and on putting
WindowsInstallCookbook into the documentation set under the TWiki web? Or would I need to be a
CoreTeam person?
I've added
WindowsInstallCookbook to the above since it's been tested successfully by three people and works well. Note that it also includes a patch to
register
that should be applied to
BeijingRelease, since register currently doesn't work on Windows (as mentioned near end of
AuthenticationProblem) - see step 5 within
WindowsInstallCookbook#Editing_the_CGI_scripts.
I've also added:
- CookbookActivePerlTestenv - the attached
testenv
now works well on Windows (ActivePerl and CygWin) and Linux/Unix, across various Perl versions. It also tests for path_info problems, checks whether ModPerl is being used, provides better Perl version info, checks the RCS version on Cygwin, and correctly tests for ci.exe
etc on Windows.
- CobaltRaqInstall - the fix here will help in various hosted environments that use
cgiwrap
, as well as in IIS where the path_info is messed up.
It would also be good to review
TWikiPatches for relevant bug fixes - some are very simple to include.
corporate appeal__ but without compromising the stability -- PeterThoeny - 08 Mar 2002
Sorry, very busy lately, could not spend as much time as I wanted on TWiki.
Schedule is not fixed yet, but we have around two releases per year. We could shorten the schedule with less features, or put in more enhancements with longer schedule. Opinions?
This release should
give broad corporate appeal but
without compromising the stability. So, we should not make major code changes unless tested extensively. The only major code change is
RcsLite. John, shall we include it / drop it from this release, or decide later?
Release schedule and frequency -- DavidLeBlanc - 08 Mar 2002
Re: Release frequency. I think it would be nice to have a "2 major, 2 minor" annual release cycle. Sometimes it's hard to find intrim patches or to know if they're necessary or what. My idea would be to have the spring and fall releases be major (and fall more major then spring - see below) and the summer and winter releases be minor. The reason for having the fall release more major then the spring major release is in consideration of how people work: they're settling down in front of their computers for the cold months (ok, N. Hemisphere-centric), and have/will want to spend more time doing TWiki things.
I would also suggest naming them as "TwikiSummer2002", "TwikiFall2002" (for example) and using the solistics and equinoxes as target dates so one doesn't have the weird situation of the 1 Dec 2001 release coming on the 12th or whatever it actually was
Agreed: more releases -- VitoMiliano - 08 Mar 2002
Yeah, more releases would be nice. Also, I tidied up the table a bit. Someone broke it.
Core team overstretched? -- MartinCleaver - 09 Jul 2002
On 27 Feb 2002,
PeterMasiar said:
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?
We want
BeijingRelease too!
CoreTeam, where are you?
We're here! -- PeterThoeny - 12 Jul 2002
Don't worry, we are here
, just very busy and can't spend hours a day on TWiki
I am currently certainly very busy with other stuff, but try to keep up as good as I can.
Best chance to get enhancement requests included in the code is by submitting tested code. TWiki has a high quality standard, the core team cannot take any code just like that into the core.
Yes, it is time for the
BeijingRelease. We might need to skip some features to speed up the process. What needs to be in is
SimplerDefaultTemplates,
EnhancedSkinHandling and a a little
EnhancedPluginHandling.
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?
Release soon, drop features -- DarrylGreen - 17 Jul 2002
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.
How about a Beta release? -- JohnRouillard - 29 Jul 2002
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,
ConfigurableLogo
add 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?
Sounds good -- MartinCleaver - 1 Aug 2002
We need to name the next two releases and push back any features that we know for definite are not going to be in
BeijingRelease. It's August here in Kuala Lumpur.
Code name for upcoming releases -- PeterThoeny - 02 Aug 2002
OK, lets decide on the code name for the upcoming releases: See Vote in
CoffeeBreak.
Also, it is time for the next Beta release.
RichardDonkin, do you have time to finish up
SettingLibPath before I create the next Beta?
How soon next beta release? -- ZeljkoBlace - 03 Aug 2002
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 ...