[11:52]
Lavr_: Hello folks
Lavr_: I had problems with my network.
VickiBrown: Hi Kenneth
carlo-: moin
Lavr_: My interest was never focused on marketing so I am normally not that active here. I am more active at release meetings. Anything on the agenda?
carlo-: not from me
VickiBrown: I added three things to the Brianstorming section
[12:15]
VickiBrown: but they re mostly from my spouse (Rich Morin) and he cannot be here today :(
Lavr_: The first item on the agenda is the homepage design
Lavr_: Under the new governance I assume we will soon have a task team empowered to work on this
carlo-: sounds reasonable
Lavr_: Carlo maybe you should work on recruiting a team
Lavr_: This is a chance for the non programmers
carlo-: so far it is Arthur and me
carlo-: but we need more people for writing the entry pages
Lavr_: I think it was rafael (I may remember wrong) that suggested that the twiki.org maintenance should have one person per web
carlo-: yep
[12:20]
carlo-: it was on the facilitator topic from peter
Lavr_: But I think ONE team should be responsible for the entry pages to ensure a good navigation for the entry level
carlo-: yes, but this is a huge task
carlo-: give you want to do it right
carlo-: given
carlo-: on the other hand, its hard to be make something that isnt beter than what we have now
Lavr_: I never understood the issue with the entry pages. I would have expected something simple without many words
uebera||: Hi there. :)
[12:22]
carlo-: but the TaskTeam thing is probably the best approach to get it solved
carlo-: hi
Lavr_: Hi Markus
carlo-: maybe it's because we set our goals too high
Lavr_: That is what I think
carlo-: creating such pages is professional full time work
Lavr_: But I am not the expert
carlo-: so we might need to settle for less
Lavr_: Without any skin changes a lot could be done just by simplifying the path to the most normal kind of information
Lavr_: Just try to imagine a user trying to find the supplementary pages in the TWiki web. You have to use pure luck to find those
[12:28]
carlo-: true
carlo-: we already created overviews of what kind of info we need on what kind of page
carlo-: all that is missing is writing these pages
Lavr_: Let us continue to the next agenda item. Blogging.
Lavr_: I have thought about writing a very positive blog about the Summit.
VickiBrown: thank you Kenneth!
Lavr_: Next is Twiki Meetups. My guess is no news on that
carlo-: nope
Lavr_: But we should learn from the Berlin meetup. Hardly anyone came. I think only 2 came.
Lavr_: Or was it 1?
[12:39]
carlo-: 1
carlo-: you need to do a lot of promo
Lavr_: Obviously more footwork is needed for these event and our communication channels are missing
carlo-: yep
carlo-: peter did this well for the silicon valley meet up
carlo-: but its easier as many folks are nearby
Lavr_: Yes. But he is also doing a lot of foot work
carlo-: true
Lavr_: Next is merchandising. Anything?
Lavr_: I assume not.
[12:44]
Lavr_: That leaves us to the last 3 brain storming items by Rich
uebera||: Which one first?
Lavr_: Quote: RichMorin Googled for MediaWiki and TWiki and got several hits of the form "How do I migrate from TWiki to MediaWiki?". TWiki is structured, programmable, and has access permissions, but MediaWiki has "buzz". Perhaps we should add a comparison of TWiki vs MediaWiki on twiki.org.
VickiBrown: we have comparisons for JotSpot and Confluence
VickiBrown: but they are not as popular as MediaWiki
VickiBrown: Rich notes people have "heard of" MediaWiki
[12:47]
VickiBrown: even here at YahoO! people ask "why don't we use MediaWiki?"
VickiBrown: I don't know who could write this
Lavr_: yes it would be good with a comparison table.
uebera||: We could copy the comparison from WikiMatrix(sp?) and try to comment it in order to find out how best to emphasize TWiki advantages. I still think most people will have a look at WikiMatrix first.
VickiBrown: we need to fight back :)
carlo-: we have something like it already
carlo-: MartinSeibert wrote one
VickiBrown: lets' get what we have out in front of people
uebera||: (http://www.wikimatrix.org/compare/MediaWiki+TWiki)
Lavr_: The Matrix one is too generic. Ours needs to be constructed so the advantages unique to TWiki are emphasized
[12:50]
uebera||: carlo-: Do you have the name of the topic/URI at hand?
carlo-: of course not ;-)
carlo-: wait a sec...
uebera||: I concur. The only subjective "disadvantage" I get from the comparison above is the data storage backend; hopefully this changes w/ v5.0
VickiBrown: My understanding is that MediaWiki does not have the full page-by-page ACL permission capability that TWiki has. We should stress that
Lavr_: The table needs to focus on the application part
carlo-: http://twiki.org/cgi-bin/view/Codev/ComparisonOfMediaWikiToTWiki
VickiBrown: that too, very much so
uebera||: Thanks.
VickiBrown: focus on anythng that looks good to Enterprise executives and admins :) :)
[12:54]
uebera||: Subwebs aren't mentioned at wikimatrix which IMHO is directly related to scaling issues.
VickiBrown: that's a nice page (thanks Martin (not here ut in the transcript))
uebera||: Maybe we should come up with a small set of important characterstics and try to get them listed on wikimatrix.
uebera||: (as 'Extras')
Lavr_: Hello Andre
Lavr_: Martins topic is good but it can be improved to add much more focus on the application part. People do not have fantasy to understand a generic statement about applications. It needs to get examplified as a list of features you can do with TWiki
Lavr_: Let is take the next brainstorm item
Lavr_: Quote: RichMorin reports that one of the main objections he got to TWiki (by an operator at a former company) was that it doesn't have an RPM archive. Couldn't this be built automagically?
Lavr_: I have wanted to make an RPM for TWiki for a while but last step I took was buying a book about rpms and reading the first chapter
[1:02]
Lavr_: It would be good with some rpm expert
uebera||: _Is_ there a recent book?
uebera||: I have some expertise w/ RPMs, but not much spare time at hand ATM.
Lavr_: I do not think it has to be very recent to do what we need.
uebera||: Some weeks ago, I read about a service from SuSE which allows to build RPMs for different distros automatically.
Lavr_: I do not trust these automatic things too much. We need at least some manual control of the items that should never be overwritten when you upgrade
uebera||: Actually, if there was a simple Makefile which installs TWiki, it would be a no-brainer due to checkinstall (which builds a rpm by 'listening' to make install)
VickiBrown: Wouldn't that be LOVERly
Lavr_: I think it is simple enough to define the install. It is the upgrade which is a challenge. Example you do not want to reinstall a default admin user each time you upgrade
Lavr_: And the dependencies of CPAN libs is also difficult because TWiki needs CPAN libs that are not in the default rpm repositories
[1:06]
uebera||: Sven already built RPMs, so we even could reingineer those if he doesn't want to publish the .spec/.srpm ;)
Lavr_: I think I did get the spec file from him but it is a very automated looking one and I do not believe it does a good job when upgrading. But I have not tried in practical
uebera||: Yes, I guess that is the main effort--provide additional Perl modules for different distros.
uebera||: If you have a .spec, I can look at it and review it (<15min) ;)
Lavr_: I think we would be well off by just focussing on having TWO good packages. One for RedHat family and one for Debian/Ubuntu. Sven has already covered the debs. It is the RH we need
Lavr_: And it should not be an installer but a clean rpm. I would personally never touch an installer that I do not know what is doing until you have run it
uebera||: Mandriva is said to be 100% RH compatible, and it's not that complicated to install RH in a VM.
uebera||: Well, usually a RPM includes a small install script. (copy httpd config file, restart httpd and the like)
[1:10]
Lavr_: Yes. But it is important that all this is not rerun when upgrading
uebera||: It shouldn't destroy anything (just uninstall it and you're clean--after all, that's the big idea behind RPM/<name your favorite packager here>)
uebera||: This should be very straightforward and can be easily tested. (If config file exists, don't change it; if you need to change it, user gets to see a diff of it--this is handled by rpm frontends)
Lavr_: Example. When you upgrade you do not want to have the twiki httpd config overwritten. Here the .rpmnew (as I remember it) suffixed file is a good solution
Lavr_: Like it happens if I upgrade Samba
uebera||: This is the usual behaviour; I guess it's handled by a flag whether the user is prompted ("need to replace"). There are a number of examples, so this isn't difficult once you have a base .spec.
Lavr_: Yes. We just need someone to do it ;-)Ê Ê Unless you want to wait till I have read my book. :-)))
uebera||: Packaging the Perl modules is a bit more effort. Though the base modules should be easy to identify.
Lavr_: Last brain thing
Lavr_: RichMorin would like there to be a TWiki "speaker registry" where folks could mention their availability to talk about (specific aspects of) TWiki. For example, Rich would like to find a speaker to talk about the plugin architecture for the SF Perl Mongers.
[1:17]
Lavr_: I would personally just send an email to the mailing list and ask if I needed this
Lavr_: You can always try and create one on Codev and see how many adds themselves. My guess is: 1 - Peter
Lavr_: I doubt many others than Peter does speaking regularly
uebera||: Aside from that, I'd contact the consultants (if I would be willing to spend money for this, i.e., it's really important to me).
Lavr_: yeah. The email to twiki-dev should reach all the consultants
Lavr_: Maybe in connection with the TWikiSchool initiative we can also include speaking
uebera||: Oh, I didn't spot that topic...
Lavr_: There is none yet. It was something I proposed in another topic once and want to follow up on
uebera||: I see.
uebera||: Sounds interesting, though. :)
[1:22]
Lavr_: I discussed with Michael Daum at the Summit (breakfast talk) if we should arrange a school day in connection with Summits
Lavr_: The idea with TWikiSchool is that we can arrange full day training that people PAY to take
Lavr_: It is often easy for people to get funding for this in large companies - from the training budget
Lavr_: And a school session in connection with a summit could help funding the travel to the summit for some of the consultants that need to travel far
Lavr_: And to help participants to get travel paid as part of a training session.
uebera||: Yes, a hands-on tutorial day can pay off fast if it's not too expensive.
Lavr_: And it would be nice to get more people to learn about the core architecture, unit test framework, etc
Lavr_: A typical pro training cost 800-900 Euros per day. People should not have problems getting this kind of training paid
Lavr_: With a class of 12 students - that is around 10000 Euros for one day training. That should be fair
Lavr_: naturally there is easily 5-10 working days behind it for preparation
[1:29]
uebera||: Hm... this sounds a big too much to me, though (for the first time). In order to attract more people, I wouldn't charge more than 300 EUR per person. But it's not my calculation ;)
Lavr_: But if multiple sessions are held most of the prep can be reused
Lavr_: Remember that the fee also has to cover travel for teacher, water, coffee, and class room
uebera||: I get a lot of ads for 2-3 full days (which are around 800-1500EUR), but this is 'economy of scale' (with a single day, it's difficult to come up with questions because there's no time to 'digest' the material/topics).
Lavr_: And believe me - noone trusts cheap training. Training should cost market price
uebera||: Personally, I'd never ever pay more than 500 EUR per day.
Lavr_: My original TWikiSchool idea was for 2 or 3 day training
Lavr_: But for the Summit a single day with small training events of 2-3 hours could be a good supplement
Lavr_: I am sending a person to VHDL training next week. It cost around 5000 DKK or 700 Euro per day
uebera||: That's how the TMRA (www.tmra.de) tutorial day is organised. Though Topic Maps are still considered an 'emerging technology', so it's a lot cheaper to attend. ;)
[1:34]
Lavr_: That also includes lunch I am sure.
Lavr_: You can always find cheap training or even free training from companies training in THEIR product
Lavr_: Like when Intel or Agilent invites to seminars
Lavr_: But then they pay the trainer because they know that of just ONE participant as a result chooses their IC or an instrument then the whole thing is paid
Lavr_: We cannot think like this with Twiki. The consultant that travels from UK to Germany to give a 2 day class needs to have a decent business out of it
Lavr_: I am out of time. I suggest we end tonights meeting
uebera||: ok.
uebera||: If you can get a hold of the .spec file, I'd happy to play with it during the next weeks...
Lavr_: Thanks to the few participants
[1:38]
Lavr_: I will search for the spec file. I believe I got it from Sven in an email.
Lavr_: Good night
uebera||: gn8 ;)
[1:39]