--> You are now talking on #twiki_release
 krk_ (n=krk@adsl-66-218-47-115.dslextreme.com) has joined #twiki_release
 PeterJones (n=peterjon@165-69.107-92.cust.bluewin.ch) has joined #twiki_release
<PeterJones> Is anyone there
* krk_ is not quite here (plowing thru something else) -- but should be mostly here for the 10 o'clock...
* qhartman is here, but planning on just lurking
--> Mowgli (n=Mowgli@home.ethgen.de) has joined #twiki_release
<Mowgli> Hi
--> max (n=max@adsl-ull-13-65.47-151.net24.it) has joined #twiki_release
--- max is now known as Guest66587
<Guest66587> exit
 quit
<PeterJones> Are Peter and Sopan here
 I think that the meeting is at 17.00 GMT, so in 12 minutes
--> peterthoeny (n=PeterTho@dsl092-019-099.sfo1.dsl.speakeasy.net) has joined #twiki_release
<-- peterthoeny has quit (Remote closed the connection)
--> peterthoeny (n=PeterTho@dsl092-019-099.sfo1.dsl.speakeasy.net) has joined #twiki_release
<-- Guest66587 has quit (Remote closed the connection)
--> ctrace (i=chris@pool-98-117-41-208.bltmmd.fios.verizon.net) has joined #twiki_release
 PaulReiber (n=Paul@adsl-75-63-19-58.dsl.pltn13.sbcglobal.net) has joined #twiki_release
<PaulReiber> ...ah, much better; it's #twiki_release not #twiki-release (still waking up...)
<-- KiltBear (n=aj@65.91.82.62) has left #twiki_release
--> KiltBear (n=aj@65.91.82.62) has joined #twiki_release
<Mowgli> Jea, its very early... ;)
--> SopanShewale (n=chatzill@123.252.229.19) has joined #twiki_release
<peterthoeny> hi KiltBear, krk_ Mowgli, PaulReiber, PeterJones, qhartman, SopanShewale!
<peterthoeny> good morning/afternoon/evening
<SopanShewale> Hi Peter - good morning everyone
--> pnixon (n=pnixon@nat/sun/x-559019182bb8f2b7) has joined #twiki_release
<Mowgli> And with the current summertime it is even worse.
<PaulReiber> :-) ...ready to get started, or waiting for a few more people?
<Mowgli> Hi Peter
<pnixon> Hi guys
<ctrace> hi there
<pnixon> I'll mostly be listening in, I'm actually on a con-call at the moment.
--> CraigMeyer (i=c09a5be1@gateway/web/ajax/mibbit.com/x-d1e06656e4bc7567) has joined #twiki_release
 procopio (n=chatzill@212.13.49.67) has joined #twiki_release
<CraigMeyer> Ok, I made it!  (on the phone though ;)
<peterthoeny> hi CraigMeyer and pnixon
<CraigMeyer> Hello
<pnixon> Hi Peter
<procopio> hi there!
<peterthoeny> hi ctrace, missed you
 hi procopio
 welcome
 good turnout today!
<procopio> thanks
<peterthoeny> today is the kick-off meeting of the twiki helsinki release
 12 people, nice!
--> SopanShewale_ (n=chatzill@112.110.25.18) has joined #twiki_release
<peterthoeny> could everyone state their twiki.org wikiname (if registered) and one sentence about twiki use at work/hobby?
--- peterthoeny has changed the topic to: http://twiki.org/cgi-bin/view/Codev/HelsinkiReleaseMeeting2009x04x06
<KiltBear> AJAlfieriCrispin - work - KQED uses it for production and administrative collaboration
<qhartman> no username at the moment, no twiki use at the moment, still evaluating options and Twiki is among them.
<peterthoeny> hi aj, nice to see you here
<PeterJones> PeterJones TWiki at CERN
<KiltBear> back at you PT
<pnixon> I'm PeterNixon, and we use TWiki as Sun's Microelectronics main intranet portal
<PaulReiber> Hi I'm PaulReiber - using twiki for both work and fun - TWiki's the engine behind my reiber.org/nxt RobotWiki and I've got a short list of corporate clients who count on me when things break.
<krk_> (noname on twiki.org -- Kim Knuttila in real life tho) (twiki selected at a previous Co I worked with and am looking at things for the home network)
<peterthoeny> paul is also a twiki consultant listed on twiki.org and twiki.net
<ctrace> mine is ChrisTracy, from MAX GigaPOP in the DC-metro area, been using twiki since ~2001 and manage several production/personal twiki sites
<peterthoeny> hi kim, nice to meet you here
<Mowgli> Klaus Ethgen - work - We did many work with own skin and such to use it as unit website. (Packagign RPM too).
<krk_> hey peter -- I lurk once in a while ;-)
<peterthoeny> :-)
<Mowgli> Ups, should be KlausEthgen
<SopanShewale_> Hi - i am  SopanShewale - used TWiki every place where i moved - now working with Peter
<CraigMeyer> CraigMeyer - developer/work - (sorry on the phone at work)
<peterthoeny> klaus built a nice twiki skin for eth in zurich
<procopio> RuiProcopio... im more of a curious mainly because i recognize in the TWiki great potential
--> ashcrow (n=ashcrow@nat/redhat/x-62d9e744dfa5e026) has joined #twiki_release
<peterthoeny> and we have pnixon, i believe PeterNixon who contributed many twiki features while at sun
<CraigMeyer> CraigMeyer - developer / work - TWiki used for 4 years in MDRIT department at GlaxoSmithKline
<peterthoeny> hi ashcrow, welcome. could you state your twiki.org wikiname (if registered), and one sentence about twiki use at work/hobby?
<PaulReiber> also I'll mention while we're still doing introductions, I started using TWiki last century :-) and I'm now focused on javascript, jQuery, AJAX, TiddlyWiki, and more... and integegrating much of that w/ TWiki of course.
<ashcrow> peterthoeny: SteveMilner, I work for Red Hat as an Agent of Infosec.
<peterthoeny> ah, hi steve! thanks for the security reports (with fix!)
<ashcrow> :-)
 no problem
<pnixon> I've mainly been in the skinning business at Sun, and migrating stubborn amateur web admins onto our main TWiki
<peterthoeny> pnixon: the human factor on wiki adoption at work is more challenging than technical
<KiltBear> can I get a witness!
<pnixon> Also layering lots on top of LdapContrib to guarantee unique user names across Sun (10000s of users)
<procopio> PaulReiber ... great website!
<peterthoeny> we have a packed agenda and lots to talk about, let's use the time effectively
 proposed agenda:
<pnixon> Yes, I've rarely had to tweak code as much as general attitude
<peterthoeny> # 1. TWiki Release 4.3.0 Post Mortem
 # 2. Review TWiki Roadmap
 # 3. Feature requests for Helsinki Release
 anything to add?
 i volunteer to facilitate
 who is taking notes?
<-- SopanShewale_ has quit ("ChatZilla 0.9.84 [Firefox 3.0.8/2009032609]")
<peterthoeny> SopanShewale: still here?
 sopan sometimes has power outages where he lives
<ctrace> i would offer but am currently dividing my time with several other tasks :-)
--> SopanShewale__ (n=chatzill@123.252.229.19) has joined #twiki_release
<peterthoeny> welcome back sopan
<qhartman> I'm planning on saving a transcript of this, if that is what you mean by "take notes" I'll volunteer.
<SopanShewale__> thx peter  :)
<peterthoeny> qhartman: that would be good
<peterthoeny> attach it with filename GeorgetownMeetingLog2009x04x06.txt to minutes topic at http://twiki.org/cgi-bin/view/Codev/HelsinkiReleaseMeeting2009x04x06
<qhartman> will do
<peterthoeny> by taking notes i mean also summarizing key points in meeting sections
<SopanShewale__> my internet connections seems to be very slow :( not sure if i am able to see all chat on irc
<PeterJones> Sopan, you seem to have fixed http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item6151 in Georgetown.
<peterthoeny> time check: +20 min
 let's start
 ---++ 1. TWiki Release 4.3.0 Post Mortem
 see http://twiki.org/cgi-bin/view/Codev/TWikiReleaseManagementProcess
 what worked well, what can be improved?
<-- SopanShewale has quit (Read error: 110 (Connection timed out))
--- SopanShewale__ is now known as SopanShewale
<SopanShewale> PeterJones: Thanks - let me check after the meeting
<peterthoeny> personally i am pretty happy with our release process
 for the 4.3 release we had a resource problem, so a lot fell back on a few people
 but overall it went well
 and since 4.3 is based on stable 4.2.4 release and we made conservative changes to the source code i expect it to be a very stable .0 release
 sopan, any feedback on process?
<PaulReiber> right so in general question is do we want to expand the role of TWiki Community Members?
<Mowgli> peterthoeny: I will do a update of our installation, then I will find if there are new problems. But as I test the rc1 I think there should be only minor problems.
<SopanShewale> Peter - going through the process... any highlight whats new in the new process? whats changed?
<peterthoeny> PaulReiber: yes, the idea is to form task teams, as described in http://twiki.org/cgi-bin/view/Codev/TWikiGovernance
 that we we can nicely scale the community
<ctrace> not having been involved with the release process, i don't know what happened internally -- but externally i see that you seem to have met your goal/deadline for when the release was finished
 (and that is always impressive...!)
<SopanShewale> ok - sounds good Peter
<peterthoeny> i'd love to see people form task teams on marketing and other areas
 we have tweaked the process a bit during 4.2.x releases
 i think it is pretty solid
 the 14 day automatic acceptance rule has proven to be effective
<PaulReiber> one area that was weak for 4.3 - for some reason, 4.2 got installed in a _lot_ of places - "automated availability" via godaddy for example.  Good things.  But 4.3 didn't get rolled in on top of 4.2 (for these instant-on type TWikis) even well after it was available.  I'm unsure if that's (a) just my perception (b) indicative of a process issue or (c) indicative of some technical hurdles I wasn't aware of
<peterthoeny> although there have been cases where i felt concerns raised where blocking a proposal for too long
 PaulReiber: automated update is a weak spot of twiki at the moment
 definitely something that can be improved
<PaulReiber> cool.
<peterthoeny> 4.3 is "done", but we need to provide an upgrade package
 that is pending
 sopan and i can take this offline
 time check: +30 min
<Mowgli> Paul, Peter, As I told you (peter) I did test building a RPM which can be easily updated. That works too with the 4.3 release.
<peterthoeny> on release process, i'd like to see a way where a feature can be implemented before the 14 days pass if core developers agree on the feature
<Mowgli> I am not a friend of the install and configuration scripting.
<peterthoeny> not sure how that can be formalized so that it is a transparent process
 may be something like: if x% of active contributors agree on a proposed feature it can be implemented before the 14 days passed
<ashcrow> Just a note, when I made an RPM for installation I had to patch out some items in TWiki to avoid conflicts on perl provides
<SopanShewale> This is good idea - it does not make sense if we really really need to with release which is schedule say in 3 days
<peterthoeny> rpm updates can overwrite tailored files in twiki; twiki still needs to be enhanced to be rpm friendly
<Mowgli> "AutoReq: no", the RPM building tools are so braindamaged...
<peterthoeny> another point to consider: release train
<ashcrow> if it would be helpful I might be able to get one of my guys to send what they did for their rpm's ... it wasn't perfect but it worked with 4.2.x
<peterthoeny> e.g. scheduled releases
<SopanShewale> Mowgli - we have brainstormed rpm building for TWiki - but its not easy to resolve a few things e.g. A few configurations variables of Plugins are stored in TWikPreferences
<procopio> Hi gyus, mind if i cut in a bit?
<peterthoeny> procopio: go ahead
<PaulReiber> peter: things like "core team consensus beats 14-day-rule" and "when is a concern really a concern" indicate to me that a small admin team riding herd on that stuff, so long as it's kept open and people comment _why_ they changed things, made decisions, etc.
 ...that said, say your mind, procopio!
<procopio> recentely  i proposed to have TWiki based Knowledge share tool in my company.
<Mowgli> SopanShewale: True, therefor I implemented a plugins.d directory with one file for one plugin.
<ctrace> as much as i like packages, i have never been a fan of installing twiki via .rpm or .deb (although i do wish that this worked better)
<Mowgli> that scales up to many plugins.
<procopio> unfortunatly i had to give up on the idea after coleages tried it
 I would have made it to be accepted, if tiwerent for the WYSIWYG interface
<Mowgli> But true, it is not easy. The .spec file has 663 lines!
<SopanShewale> for rpm - i think let us add that as proposal - let us brainstorm/debate on the proposal-we can definitely make that working for TWiki :)
<PeterJones> procopio, what were te issues that your colleagues didnt like?
<peterthoeny> procopio: there is a lot of inertia to overcome to get a wiki based kb accepted at work
<SopanShewale> we can use Mowgli's and other peoples experience in this
<procopio> well we were comparing TWiki with DeiWimi...
<Mowgli> And twiki needs to be packaged different to the normal way to have it working unter selinux.
<procopio> and Deki is much more user friendly
--> wmertens (n=wmertens@170.48-136-217.adsl-dyn.isp.belgacom.be) has joined #twiki_release
<procopio> still i think TWiki is far bettwer from Deki, form plugins and applciation point of view!
<peterthoeny> hi wmertens, welcome: could you state your twiki.org wikiname, and one sentence about twiki use at work/hobby?
<CraigMeyer> DekiWiki is a struggle to install, looks good on paper ;)
<Mowgli> How is it more user friendly? Is there any that can be improved in TWiki? (Well, yes, but I think in comparisation)
<CraigMeyer> DokuWiki is closer to TWiki, but in PHP not PERL!
<wmertens> peter, hi this is WoutMertens and I support a twiki install at work since 2003.
<SopanShewale> Procopio - every system has a few Plus and A few minus.. .it totally depends on the enterprise environment/people mindset/leadership ... TWiki is actually wonderfull Knowldge Management system
<peterthoeny> imho usability is a very important factor for upcoming release, i'd like to see a task team formed around usability
<Mowgli> Ok, that is a big minus for DokuWiki. ;)
<procopio> Well ... for enterprise, install is not an issue!!! i guess!!
<CraigMeyer> Mowgli, I agree
<procopio> someone will do it!...
<wmertens> Deki has a different philosophy, it stores html not wiki text
<SopanShewale> no .. support person does not have any value when it comes to see the success of the system
<procopio> Sopan: agree totaly...
<CraigMeyer> Though upgrades on enterprise for TWiki are tedious, as I have improved so many parts of TWiki
<procopio> that is why i was so disapointed...
<ctrace> sounds like we are getting into the area of roadmap/feature requests :-)
<wmertens> my biggest gripe with TWiki is that metadata is embedded in the documents where it can be edited
<CraigMeyer> (Which I guess is called a branch, my own fault ;)
<procopio> wmertens: for users it doesnt matter what it stores!!!!
<SopanShewale> procopio - you are most welcome to contribute your findings/experience/pain points you faced with TWiki while working at .. you please share experience in Codev web
<pnixon> I've been trying to do all my improvements as AddOns or Plugins since MegaTWiki
<peterthoeny> good discussions here. in interest of time let's go back to release process
<pnixon> I like it.
<wmertens> procopio: true - although it makes the wysiwyg editor work better :)
<peterthoeny> (and i'd like to see task teams formed to track the initiatives we discuss here!)
<procopio> wmertens: and that is the point!
<wmertens> procopio: let's not both argue the same side of an argument ;-)
<peterthoeny> on release process, we could consider switching to a release train model where we have a known (fixed) schedule, say release every 6 month
<procopio> soory about that Peter
<peterthoeny> beta release is minus 3x days, code freeze minus y days (etc) from general availability date
<CraigMeyer> For the uninitiated, a Release Train model, means regularly timed releases, every 6 months ??? Like a scrum release period?
<PeterJones> Peter, In past versions several minor releases have quickly followed version 0 nd for this I have waited a while before upgrade. You seem to be confident that 4.3.0 is quite stable though.
<peterthoeny> a feature is on a train, or misses it and goes to the next train
<CraigMeyer> ok, got it, I like that idea
<PaulReiber> A release train gives two big benefits:  (1) communicates intention of regular updates to the system (2) provides a context for introducing improvements/solutions for automated-update
<peterthoeny> patch releases are anoth story, they still need to be done as needed (especially to address security issues)
* qhartman also likes release train model
<peterthoeny> but a release train also has pitfalls
 it is hard to to sweeping code changes
<PaulReiber> ..OK... ?
<peterthoeny> which actually might be a positive thing ;-)
<wmertens> sorry if this was touched upon already, but I'm quite behind on current TWiki, has anything been done to make upgrades easier? If we upgrade every 6 months that'll be very painful
<PaulReiber> depends... if codebase is relatively stable, it probably _shouldnt_ have sweeping changes?
<wmertens> My problem is that a lot of the configuration of twiki is actually inside the twiki data
<pnixon> Release trains might be good for minor releases, but major releases with sweeping code changes (e.g. 5.x) branch from previous major release
 ?
<peterthoeny> the reason why i raise this question is our current code base: we have very stable 4.2 and 4.3 brnaches, and an unstable trunk with sweeping code changes
 currently we maintain two branches: trunk and 4.3 branch
 it takes time to stabilize trunk
<SopanShewale> release train method - we definitely need more developers
<wmertens> peterthoeny: what are the types of breakage you expect on trunk release?
<SopanShewale> else it is big workload to meet the schdule
<peterthoeny> a possible solution is to release trunk with current process, and establish release train after that
<pnixon> Might be time to target 4.4 with the trunk (with it's own release train), and put 4.3 in bugfix mode with it's own release train.
<peterthoeny> well, some develoepers who left in the mean time made sweeking changes to trunk
 "sweeping changes"
<pnixon> Is it functioning?
<peterthoeny> such as twiki standalone with pluggable webserver architecture
 it is functioning, but needs to be stabilized
<wmertens> right, something I very much would like
<pnixon> Is so much changed that we need to do an audit?
<PaulReiber> PT - have to defer to your judgement on this whole can of worms; in my mind, trunk should _always_ stay stable, and instabilitiy only exists in experimental branches... (I know, ideal != reality)
<SopanShewale> trunk has good pieces - but some one needs to check the stabality - we might need to write/rewrite test cases.. current test cases are not greatly written
<peterthoeny> frankly, i never felt comfortable with the large code refactoring that has been done in the past
<pnixon> Yes, I'm not familiar with the test framework yet.
<CraigMeyer> I agree with WMertens, from my experience too much configuration inside TWiki code, and data
<Mowgli> PeterJones: I agree..
<peterthoeny> that is the reason why i would like to go to smaller more stable releases, with release train
<PaulReiber> PT: / frankly, i never felt comfortable with the large code refactoring that has been done in the past/ <- TRUST YOUR GUT!
<Mowgli> Ehem, should be peterthoeny...
<peterthoeny> i trust my gut and my code changes :-)
<Mowgli> I am not a friend of the different structure of trunk and branch.
<pnixon> I think there needs to be room for sweeping changes (sometimes they're unavoidable, as in re-architecture of sub-components, e.g. UserManagement)
<CraigMeyer> I may be wrong, but with proper use of Plugins, Contribs, there shouldn't need to be too many changes to main code?
<peterthoeny> so, one key decision that we need to make: next release, is it 4.4 (stable, based on 4.3), or 5.0 (based on currently unstable trunk)
 feedback?
<SopanShewale> trunk has good changes - but we need to make it stable
<Mowgli> true. But if you have a big difference in the structur of branch/trunk that makes it very dificult to maintain both.
<CraigMeyer> I am also nervous of the unstable trunk, should probably be relabeled as experimental
<pnixon> I'd do 4.3->4.4, and handle trunk->5.0 on the side for the next release after 4.4
<SopanShewale> i would vote of 5.0 based on  trunk
<CraigMeyer> I agree with pnixon
<SopanShewale> trunk has something like "Catalyst" framework which i love
<qhartman> so, ignorant opinion of an outsider re: 4.4 vs 5.0. I'd suggest doing a 4.4 before a 5.0. Need to show some stability in the project. The external perception is that things are still all wonky from the falling-out / fork stuff.
<Mowgli> Lets just get the 4.* branch get stable. 5.0 for the next release whould be fine IF this clears up the structure.
<ctrace> imo, twiki that can run in standalone mode sounds like 5.0, that is a pretty significant shift ;-)
<CraigMeyer> I also agree with ctrace
<peterthoeny> lively discussions, nice!
 we do not need to decide on 4.4 vs 5.0 today
 i think decision should be based on roadmap and priorities of it
<pnixon> CraigMeyer:  On sweeping changes, yes main code *should* be stable, but if someone gets a great idea that involves a re-code, we need to be able to handle it.
<CraigMeyer> I agree, Main should be stable
<qhartman> seems like there needs to be a deep breath and stabilizing before diving back in. From the outside, it doesn't quite feel like that has happened yet.
<peterthoeny> time check: +60 min
<PeterJones> I vote for a more stable approach.
<peterthoeny> i suggest we go to next agenda item
<PaulReiber> Need to assess the ROI of the 5.0 feature set vs. 4.4 feature set, to see the "wow" factor...  LOTS of eyes will be on the team as the next release rolls out - it can be a big win if done right.
<CraigMeyer> I also vote for more stability
<peterthoeny> to summarize on release process: 4.4 or 5.0 is decided later, depends on priorities and roadmap features, consider switching to release train model  (possibly after 5.0)
<PaulReiber> OK what's next on the agenda?
<peterthoeny> personally i also am for stable releases
 ---++ 2. Review TWiki Roadmap
 see http://twiki.org/cgi-bin/view/Codev/TWikiRoadMap
<ctrace> PaulReiber: (sorry for the delayed response) i have to agree that trunk should always be something that is working/stable -- as a user/admin, if i do want the latest features which haven't been released, i typically expect trunk to be working (and experimental stuff to be in branches that are eventually merged back into trunk)
<peterthoeny> and http://twiki.org/cgi-bin/view/TWiki/TWikiCharter
 ctrace: agreed
 please glance over roadmap and charter
<SopanShewale> thats true ctrace :)
<peterthoeny> let's use some time to brainstorm on it
<ctrace> i was happy to see the usability and mashups features that were proposed
<peterthoeny> please don;t go into too much detail, idea is to see twiki space from 30,000 feet
<pnixon> agree with ctrace (trunk vs branch)
<peterthoeny> the roadmap has been defined and refined mainly by the community
 since we have now some new community members i'd like to get them a chance to chime in
<PeterJones> Isnt the 4.3 WYSIWYG editor acceptable?
<pnixon> like to see more polished admin interface, probably can be done as a contrib
<peterthoeny> wysiwyg still has many quirks
 and is not extensible
<PaulReiber> w.r.t. roadmap:  happy as a clam to see "SQL Storage back-end that scales to gazillions of pages with compatibility and audit trail " and also the "Mashups" section (kinda what I've been doing) - w.r.t. DB interfaces: independent of, or integrated with, traditional "forms"?
<ctrace> for usability i was mostly thinking about the 'point and click permissions' and 'flow of manipulating content'
<KiltBear> Coming at this as a consumer: We're a release or two behind... using this in production, I will err on the side of waiting for a while, rather than updating every time. I will only update if there is a feature I know my users will just go crazy for. I'm looking forward to giving them a usable WYSIWYG as the default.
<pnixon> ctrace: right on.
<peterthoeny> for example, i would expect that if i drop in the chartplugin or spreadsheetplugin, i would get menues to select chart with options, and possibly a wizzard
<KiltBear> The release train idea would allow me to see when a "must have" feature is coming out, and know how long I have to wait for it.
<ctrace> for example, i run gallery2 for hosting pictures, it is very nice to be able to add bulk content by either drag & drop via java applet or (2) via an external app that runs on my computer that communicates with my gallery installation
<pnixon> haven't reviewed latest JoeUser docs yet, but general population needs a separate set of documentation (I only need to edit X and do Y or attach M to N)
<CraigMeyer> A better WYSIWYG would be wonderful
<KiltBear> Things I'd like to see: Calendar Plugin produce iCal compliant output for subscription
<PaulReiber> kiltbear: yes, better visibility of features coming is another side-effect of the release train approach.  I think we pretty much have consensus on heading down that track (heh)...
<KiltBear> RSS streams for page changes
<peterthoeny> pnixon: yes, admin interface improvements are high on my personal priority list since it is the admins who get the first impression and recommend for/against twiki in a competitive eval
<SopanShewale> WYSIWYG is must for all Wikis :)  we definitely needs to improve it :)
<CraigMeyer> SQL backend should use the pluggable Store idea
<KiltBear> RE SQL backend, I understand the benefits, but one of my initial requirements for wading into the world of wiki was an easy quick restore of data.
<qhartman> The Usability and Administration stuff (particularly P&C permissions) would be a big win for my org.
 PeterJones peterthoeny
<pnixon> peterthoeny: have done some work on point/click admin interfaces, but in serious need of refactoring
<CraigMeyer> Easier skins would be nice
<KiltBear> If I lose my store (files on a disk) they are easily recoverable and usable directly from tape as human readable raw data files
<peterthoeny> KiltBear: that can possibly be done with a custom formatted search where you set the content-type (i have done that in different area for excel export)
<Mowgli> The skin part iss a mess. yes. :)
<qhartman> peterthoeny: Yes, if a product has an awkward admin interface I am unlikely to recommend it no matter how well it does anything else
<pnixon> Yes, skins are a priority... spent last 3 weeks on my latest
<CraigMeyer> KitBear, using SQL does not preclude have the files behind the scenes
<Mowgli> backend could be easily pluggable...
<ctrace> KiltBear: if twiki supported SQL i would most certainly be using replication schemes like mysql's master-slave
 KiltBear: but believe me, i appreciate flat files as well :-)
<peterthoeny> pnixon, qhartman: i hear you on point and click admin interface
<Mowgli> So there could be RCS, MySQL, git, none, ...
<CraigMeyer> In our Wiki, Admin was not a big issue, WYSIWYG bigger (only a few admins, many Users)
<Mowgli> But I think the main files should stay txt!
<CraigMeyer> We kept our Wiki open
<pnixon> Mowgli:  backend is (sort-of) pluggable now...
<CraigMeyer> Mowgli, I agree keep .txt files
<peterthoeny> agreed on better skin interface, yet another task team (hint, hint!)
 see http://twiki.org/cgi-bin/view/Codev/SimplifySkinCreation
<pnixon> Admin not an issue for us, but I find myself sneaking in via terminal all too often
<CraigMeyer> I prototyped a SQlite DB interface, used to reduce fetching time, and to speed up searchs, also allowed true TextIndexing, was blazing, still wrote .txt in backgroudn
<peterthoeny> on pluggable storage backend: yes, needed for large deployments > 50 k pages, and to address perceptions
<CraigMeyer> I was wondering about something like a compiler for Skins, so many damn files, including everything...confusing, but not the most important feature
 PeterJones peterthoeny
 I have noticed that TWiki does like to open (and close) many files while processing a request!
<KiltBear> CraigMeyer: sounds ideal (SQlite)
<CraigMeyer> I used the CPAN DBIx:TextIndex code, (I am guessing at the actual name)
<SopanShewale> for skin mess - it definitely makes sense to factor templates directory into directories for each skins
<peterthoeny> CraigMeyer: i think that is a good aproach to keep .txt for system of records, and to use db to speed up twiki
<CraigMeyer> SopanShewale, yes, I directory for each skin is much cleaner
<qhartman> peterthoeny: addressing perceptions is likely to be a (the?) most important "meta-task" that the project needs to address. Good to keep that in mind.
<SopanShewale> CraigMeyer - is your work shared on TWiki.org anyplace?
<peterthoeny> qhartman: :-)
<CraigMeyer> SopanShewale, nope, I talked about it once or twice, but I had a bad experience a while back with ImgPlugin, and was not eager for another colonoscopy!
<peterthoeny> time check: +80 min, let;s close in 10 min
<SopanShewale> i am definitely interested in the kind of things you discussed
 may be let us discuss offline some time
<CraigMeyer> :) Thank you
 Sure
<Mowgli> Good for me as I have to go next.
<CraigMeyer> I have the code, written for an older version of Twiki, we are running an older 4.X version
<peterthoeny> going back to http://twiki.org/cgi-bin/view/Codev/TWikiRoadMap, anything that should be scrapped or added?
<CraigMeyer> Topic Ojbect model does not seem important
<SopanShewale> i would be happy to see the code and make changes for latest version
<CraigMeyer> I was concerned about emphasis on Object model code, when Perl is not object oriented. is probably less efficient
 A better Search syntax, would be lovely, writing a %SEARCH{} is a monster right now
<KiltBear> CM: Amen!
<peterthoeny> on topic object model, it is mainly for plugin developers to manipulate content
<PaulReiber> FWIW my db needs are orthogonal to topic storage - clients have expressed interest in using TWiki to hold onto (and render) forms, which would somehow manipulate their data via a database rather than as topic data. ...hope that made sense...
<Mowgli> Uhh... I hate UTF-8... ;)
<CraigMeyer> (Search) That is a huge change, I would suggest  using something in parallel until the older search dies
<peterthoeny> CraigMeyer: do you envision something better than the current sql-like querysearch? http://twiki.org/cgi-bin/view/TWiki/QuerySearch
<CraigMeyer> I need to read that again...I am not up-to-speed QuerySearch
<pnixon> RoadMap covers what I'm looking for, with emphasis on usability & skinning improvements, JoeUser docs, wysiwyg & admin interface improvements, faster %SEARCH% or better indexed search in general
<CraigMeyer> PaulReiber, Yes, our users think of the forms and pages as a sort-of DB themselves, In fact i was just asked about having a Table (created from a search) be exported to user as a Excel file.
<Mowgli> peterthoeny: encapsulated tags.
<peterthoeny> on roadmap, my personal interest are with enterprise social networking and mashups
<CraigMeyer> Speaking of tags, there is much we could do with tags
<ctrace> peterthoeny: i'm not so sure about the Enterprise Social Networking features, does anybody here feel they would use such features?
 :-)
<qhartman> ctrace: I think my org would use them.
<ctrace> mashups would be must more interesting to me (and my organization)
<peterthoeny> CraigMeyer: you can export to csv easily with click, ask me offline, or better, pester me to write a how-to
<CraigMeyer> Do the SocialMedia stuff as a plugin (ala tags0
<KiltBear> re: tags - sound like "Form" values for form topics and plain topics alike
<CraigMeyer> sorry (ala tags)
<Mowgli> peterthoeny: I have such monsters as <span class="sitelinks" style="%IF{"defined ETHSERVICEROW and not $ ETHSERVICEROW=''" then="display: none;"}%"><a href="%SCRIPTURLPATH{"view"}%/%MAINWEB%/Contact">Contact</a>%TMPL:P{"barseparator"}%<a href="%SCRIPTURLPATH{"view"}%/%WEB%/WebTopicList">Sitemap</a>%TMPL:P{"barseparator"}%<a href="%SCRIPTURLPATH{"view"}%/%MAINWEB%/Help">Help</a>%TMPL:P{"barseparator"}%<a href="%SCRIPTURLPATH{"admin"}%/%WEB%/%TOPIC%">
<CraigMeyer> Kilt: Yes, Tags can be extended to embrace Form values
<Mowgli> Just to display one value or not.
<CraigMeyer> Ouch, I have the same code :)
 I have tried to develop light weight plugin macros to handle common code like that
<qhartman> Re Enterprise SocialMedia stuff: features like in recent editions of Clearspace would be very valuable to a lot of people I deal with.
<KiltBear> Cool: opposite of the Perl contest for shortest code: TWiki searches for 1 charactar return values
<CraigMeyer> I have a Plugin called GskPlugin, which I stick all the helpful little %MACRO{}% to help things go smoother
<peterthoeny> qhartman: contact me offline for more on esn features
<CraigMeyer> like %EMBED{}% which allows tables to have cells which span a line ending
<ctrace> the roadmap item "Easy ways to build & exchange applications & component" could probably use a little elaboration
<Mowgli> Maybe we can implement a stack which can be done like RPN
<pnixon> Topic Object Model could use expansion also
<CraigMeyer> Other User friendly items to add: Ajax wdigets, Like Topic Jump, Spell checking in TextAreas (meaning comments, and raw TWiki code)
<pnixon> and better Trash handling
 I get guys deleting the same attachment day after day
<peterthoeny> pnixon: a la not possible to delete same attachment twice!
<pnixon> correct
<peterthoeny> lot's of ideas here, and energy
<pnixon> Perhapse a "Time Machine" like interface for trash
<peterthoeny> now the question is to turn that energy into action!
<KiltBear> or datetimestamp for deleted attachment renames
<CraigMeyer> Maybe just more User training?
--> SopanShewale_ (n=chatzill@123.252.226.238) has joined #twiki_release
<pnixon> User training doesn't get around hokey trash
<CraigMeyer> True
<peterthoeny> time check: +93 min, we should wrap up soon
<CraigMeyer> My wiki is for IT people, they might be more savvy
<pnixon> I have managers (a big feat)
<CraigMeyer> We have 610+ Users (both IT people, and scientists)
<pnixon> what's perl?
<CraigMeyer> What's a wiki?
<pnixon> You're lucky :-)
<CraigMeyer> On some days ;)
<pnixon> My goal is to get a VP using TWiki
<CraigMeyer> I get them using it, and they don't even know it!
<peterthoeny> pnixon: build him/her a dashboard that presents key data
<Mowgli> So, I hit the road.
 See you...
<pnixon> Done, so I guess Craig's right... now to get them editing pages!
<-- Mowgli has quit ("Grüßt mir die Sterne")
<peterthoeny> we have one more agenda item
 ---++ 3. Feature requests for Helsinki Release
<ctrace> one of the other developers here was recently wondering if anything had ever been done to make WebLeftBar dynamically created...(e.g. using tags on the individual pages which contain a) the text and b) position [in a dotted-numerical form such as 1.3.4])
<peterthoeny> may be defer that to next time
<CraigMeyer> I would defer
<peterthoeny> unless sopan has a feature he wants to discuss
<PaulReiber> Hey one more item - login/authentication - w/ 420 as I'm using it today first-time-new-users get told their logins failed, when they really didn't and the redirect just went kaflooey instead... we need to ensure the unit tests on the auth subsystem are all-encompassing.
<CraigMeyer> Sounds fairly esoteric
 Yes, unit tests are great!
--> SopanShewale___ (n=chatzill@123.252.226.238) has joined #twiki_release
<peterthoeny> ok, let's wrap up the meeting
 great energy
<ctrace> i also suggest to defer feature requests until next time :-)
<peterthoeny> thanks all for participating!
<CraigMeyer> A pleasure
<peterthoeny> feel free to continue the discussion in #twiki
<pnixon> Thanks.
<peterthoeny> talk to you soon
<krk_> Agreed -- ta for now.