[12:10] PeterThoeny: +10 min, shall we start?
[12:10] PeterThoeny: not many people today
[12:11] Lavr: Summer time
[12:11] HaraldJoerg: The others will be there in about two hours :-)
[12:11] PeterThoeny: :-)
[12:12] PeterThoeny: so who is moderating, who is taking minutes
[12:13] Lavr: I take the minutes already
[12:13] PeterThoeny: thanks
[12:13] PeterThoeny: i volunteer for moderating
[12:13] Lavr: Cool
[12:13] PeterThoeny: or if someone else wants to do be my guest
[12:14] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x07x03
[12:14] PeterThoeny: anything to add to the agenda?
[12:15] Lavr: No
[12:15] PeterThoeny: ---+  1. Review Previous Action Items
[12:15] PeterThoeny:  Kenneth: Invite for Doc meeting
[12:15] PeterThoeny: we had some e-mail last week, but no meeting
[12:15] PeterThoeny: everybody was busy i think
[12:15] Lavr: I was "hit" by family and friends. Will try and set one up this week.
[12:16] PeterThoeny: and i was still recovering from the virus attack
[12:16] PeterThoeny: anything else on doc group?
[12:17] Lavr: Not from me.
[12:17] PeterThoeny: kenneth, we can meet this week
[12:17] CDot: are there minutes?
[12:17] ArthurClemens: Because we haven't met we cannot discuss to make the discussion open
[12:17] ArthurClemens: the doc progres
[12:18] PeterThoeny: ok, next
[12:18] PeterThoeny: -  Peter: followup on 4.0.3 release incl index.html update
[12:18] PeterThoeny: done
[12:18] *** Drusilla has joined #twiki_edinburgh.
[12:18] PeterThoeny: except announce at sf and freshmeat
[12:18] PeterThoeny: -  Martin? Make link to WebPreferences conditional in all distro webs except 
TWiki web so only the TWiki Admins will see the link.
[12:19] PeterThoeny: what is the status on this?
[12:19] CDot: No idea. Was there ever an Item added for it?
[12:19] CDot: I don;t recall seeing one.
[12:20] PeterThoeny: so open still
[12:20] PeterThoeny: - Harald: Investigate further the VarXXX topics and their linking. Including 
creating VarTopics for TWikiPreferences defined vars: OrganizeTWikiVariables
[12:20] Lavr: This must be Martin's call to do
[12:20] PeterThoeny: thanks harald for creating the topic
[12:20] HaraldJoerg: I've opened an Item2582 but have not yet committed any topics
[12:20] PeterThoeny: ok
[12:20] HaraldJoerg: There are more than I had expected in TWikiPreferences :-)
[12:21] PeterThoeny: people have not commented on harald's codev topic
[12:21] PeterThoeny: there are many useful settings for users in twikiprefs
[12:21] HaraldJoerg: It isn't actually a hazard to the codebase - the only drawback is that 
TWikiVariables will load slower if several dozens of new variables are included
[12:22] PeterThoeny: i would not worry about this
[12:22] HaraldJoerg: And I've found some of them already documented in TWikiVariables
[12:22] PeterThoeny: speed degrades with a few hundred entries
[12:23] PeterThoeny: anything elese on harald's topic?
[12:23] PeterThoeny: -  Crawford: Will draft a Codev topic on the process that the rest can comment 
on. - DONE WhatIsIn04x01
[12:24] *** SteffenPoulsen has joined #twiki_edinburgh.
[12:24] PeterThoeny: crawford, i think it would help to split the topic in two
[12:24] PeterThoeny: one for process, one for proposed 4.1 items
[12:24] PeterThoeny: hi steffen!
[12:24] SteffenPoulsen: evening all - I'll let myself in
[12:24] Lavr: Hi Steffen and also Hi Dru that arrived a few minutes ago
[12:25] CDot: PeterThoeny: fine, when someone comments on the process...
[12:25] PeterThoeny: the reason: process is also for 4.2, 5 etc
[12:25] CDot: potentially
[12:25] PeterThoeny: items is just for 4.1
[12:26] CDot: if everyone is happy with the process, I'm quite happy to cast it in stone
[12:26] PeterThoeny: actually, on prev meeting we could not decide on process
[12:26] PeterThoeny: shall we add one item on this meeting to finalize the process?
[12:26] CDot: which is why I was actioned to write the topic
[12:27] PeterThoeny: yes, that was good
[12:27] Lavr: I think the process became more down to earth once it was written down than when we 
discussed it.
[12:28] CDot: thinngs often become more real when you can read them
[12:28] CDot: I am surprised by the lack of comments, though
[12:28] PeterThoeny: no comments = acceptance
[12:29] Lavr: Not many comments. Not many commits. It is summer time. Let us try it for a while. We 
can always change it if it does not work out
[12:29] PeterThoeny: i think you wrote a moderate proposal based on our discussion
[12:29] ArthurClemens: because it looked fine to me
[12:29] SteffenPoulsen: you hit something we could fairly agree on I s'pose .. but we could speak up 
more on that account also of course
[12:29] CDot: ok. There are a whole bunch of proposals in there. Do you want to discuss them at this 
meeting? if not, when?
[12:29] Drusilla: Since I wrote the major bit, there wasn't much for me to say
[12:29] CDot: there has to be decision made *soon* to give people time to code
[12:30] PeterThoeny: lets not mix process and proposed items
[12:30] CDot: erm, this meetin git the proposed forum for the decision making process
[12:30] CDot: ^git&is
[12:30] CDot: oops
[12:31] PeterThoeny: i personally did not have time last week to look into the proposed items
[12:31] PeterThoeny: but i do have some feedback
[12:31] PeterThoeny: (not at this meeting)
[12:31] CDot: when, then?
[12:31] CDot: we cannot leave coders hanging
[12:32] PeterThoeny: this week i wiull take time
[12:32] PeterThoeny: for proposed itesm
[12:32] PeterThoeny: but, first, can we go back on the process itself?
[12:33] HaraldJoerg: I think that was basically agreed as proposed by CDot
[12:33] PeterThoeny: i think overall it is good
[12:33] PeterThoeny: i miss a timeframe
[12:34] HaraldJoerg: It says "4.1 will probably be released in August/September."
[12:34] Lavr: The process is simple and clear.
[12:34] PeterThoeny: for example, two weeks grace period for each item listed in WhatIsIn04x01
[12:34] SteffenPoulsen: I have no objections on the process - splitting it in two is good
[12:35] PeterThoeny: i mean, timeframe to decide on the go-ahead for each item
[12:37] PeterThoeny: also, on the "current proposals" is the decision doen in codev or in a release 
meeting?
[12:37] Lavr: Will we be able to keep such a timeframe in practical?  Sometimes things are 
no-brainers. Sometimes things are complicated. Sometimes people are on vacation etc
[12:37] CDot: if you try and nail things down to dates like that, you just set yourself up for a fall
[12:37] SteffenPoulsen: add declaration to make a 1h go/nogo session next meeting, starting from #1?
[12:37] HaraldJoerg: How many of the topics are covered by a coder/tester/doc writer?
[12:38] PeterThoeny: ok, consensus seems to use the meeting as the decision maker for each item
[12:39] PeterThoeny: yes, good point on no brainer
[12:39] PeterThoeny: what is the threashold for nobrainers?
[12:39] Drusilla: There's a difference between something that's just proposed and something that's far 
along
[12:39] PeterThoeny: no listed in WhatIsIn04x01 means "nobrainer"?
[12:39] PeterThoeny: s/no/not/
[12:40] CDot: I don;t think you can state a threshold
[12:40] CDot: it has to be a gut feeling from the assembled experts
[12:40] HaraldJoerg: An interesting question would be "when can it be finished" so that there is time 
for testing
[12:41] PeterThoeny: crawford: which brings up the question of user focus vs developer focus
[12:41] PeterThoeny: i think we should establish a user focus group
[12:41] Lavr: The important thing is that we have a process we try to follow instead of coding a half 
working feature - check it in - loose interest - leave it to others to make it work.
[12:41] PeterThoeny: (something for another meeting)
[12:41] CDot: a user focus group is an excellent idea
[12:42] CDot: and soemthing you should definitely follow up on, as soon as possible IMHO
[12:42] PeterThoeny: yep
[12:42] Drusilla: Focus groups don't have a very good track record so far
[12:43] Drusilla: timewise, i mean
[12:43] PeterThoeny: ok, back to topic
[12:43] SteffenPoulsen: perhaps we need something like "team is able to make decisions if 5 are in 
meeting, nobrainer if 100% gathered members are for, accepted if XX% is for
[12:44] PeterThoeny: and veto for founder (to be used sparingly)
[12:44] PeterThoeny: s/veto/veto right/
[12:45] SteffenPoulsen: veto for founder is ok, personally I think we could benefit from a 
releasemanager role having more votes .. but last time we decided discussion until consensus if at 
all possible
[12:45] Drusilla: So some pigs are more equal than others
[12:45] Lavr: I am sure that in 99% of the times we have no issues other than lack of resources to 
do it. So let us take the issues when they come
[12:46] CDot: I would prefer not to have a voting system
[12:46] SteffenPoulsen: so I think we should just start doing 1h chunks, 1st chunk at next meeting 
and see how it goes
[12:46] PeterThoeny: some pigs are also more chatty than others ;-)
[12:46] CDot: I would strongly prefer that we had a release manager
[12:46] CDot: and the release manager has to be convinced of the value
[12:47] CDot: if we pick the right release manager, we get both a user focus
[12:47] CDot: and the ability to veto (because they will listen to logic)
[12:47] PeterThoeny: according to http://twiki.org/cgi-bin/view/Codev/TWikiReleaseManagerRole it is 
sven and me
[12:48] PeterThoeny: we can revew that
[12:48] CDot: I think it has to be per release, to avoid burnout
[12:49] SteffenPoulsen: I agree, should rotate if possible (if volounteers available)
[12:50] PeterThoeny: i think the decision needs to be based on several factors: code stability, doc 
quality, usability, consistency, completedness
[12:50] Drusilla: And willingness of volunteers to work on something.
[12:51] PeterThoeny: i am wondering if the release manager can look at all
[12:51] CDot: no; that's why they are called a "manager"
[12:51] PeterThoeny: seems like a bottleneck issue
[12:51] CDot: they take advice from the people around them
[12:51] CDot: and deliver decisions
[12:52] CDot: at the moment the bottleneck is (still) that it is excruciatingly difficult to get a 
decision
[12:52] CDot: this is designed to break that deadlock
[12:53] PeterThoeny: status: the edin meeting is the decision maker until we decide on a release 
manager for a release
[12:53] SteffenPoulsen: that's ok for now I think
[12:54] CDot: peter, on past performances, you are saying "I don;t want a release manager, I want the 
meeting to decide". Correct?
[12:54] CDot: let's try and come to a conclusion, rather than putting something else off till another 
time
[12:54] PeterThoeny: no, i am stating the current situation, and i am open for a release manager role
[12:55] CDot: ok, cool. So when will we decide, do you think?
[12:55] SteffenPoulsen: anyone against a release manager role?
[12:55] Drusilla: In theory no. 
[12:56] PeterThoeny: we need to define the responsibilities for the release manager role before we 
assign the role
[12:57] Lavr: CDot. WHO were you thinking about in that role?
[12:57] CDot: Lavr: I had only though of "nots"
[12:57] CDot: as in "not me, not any developer"
[12:57] SteffenPoulsen: Lavr: Someone customer minded .. getting nervous?
[12:57] CDot: as we want a user focus
[12:57] CDot: no, not at all
[12:57] CDot: I like being customer driven
[12:58] CDot: and the feedback would be really refreshing
[12:58] PeterThoeny: we are at almost +60 min
[12:58] Lavr: OK understand
[12:59] PeterThoeny: what kind of action items can we define?
[12:59] Lavr: Codev/ReleaseManagerRole ?
[12:59] CDot: I will take an action to define the role (though I will have to decouple it from the 
core team definition)
[12:59] PeterThoeny: a.i.: draft release manager role in codev, with responsibilities and criteria 
for decisions
[13:00] SteffenPoulsen: perfect
[13:00] PeterThoeny: why decouple?
[13:00] CDot: the existing topic; don;t want to create a duplicate.
[13:01] PeterThoeny: why not simple create a draft on the existing topic?
[13:02] PeterThoeny: shall we move on to the next item?
[13:03] Lavr: Yes let us do that
[13:03] PeterThoeny: ---+  2. Visibility of hotfixes for our releases
[13:03] PeterThoeny: Desired outcome: Revisit current practice, brainstorm on improvement
[13:03] Lavr: If people did not already  - please read the agenda/minutes topic to save having to 
type it again here
[13:04] Lavr: It is basically Arthur and I that put the proposal forward
[13:04] Drusilla: Personally I don't understand what happened to the 4.0.x branch
[13:04] PeterThoeny: i think arthur made a good refactor on the known issues topic
[13:05] ArthurClemens: Drus?
[13:05] Lavr: The Known Issue topic itself is partly good and yes - it got much better.
[13:05] ArthurClemens: Is the proposal clear?
[13:05] Drusilla: As I noted somewhere, 4.1 is  5.0-0.9, not 4.0+0.1
[13:06] Lavr: The issue is that when you download a twiki release it is not obvious what hotfixes / 
patches you can download and add.
[13:06] Lavr: I think you are offtopic Dru
[13:07] SteffenPoulsen: I think the proposal is clear enough
[13:07] Lavr: There is a balance. The two extremes are...
[13:07] Lavr: 1. You have a download and 30 patches and it looks like a mess out of control.
[13:07] Lavr: 2. You have the download and any fixes are well hidden where most will not find them
[13:07] Lavr: I would like to see something in between.
[13:08] ArthurClemens: 1. can be the table with fixes plus a more visible link to more
[13:08] ArthurClemens: I doubt if we reach that situation
[13:08] Drusilla: My point was that by deciding that there would be no 4.0.4, the only choices are 
patches
[13:08] CDot: I don;t think we decided that, did we?
[13:08] PeterThoeny: you can look at it from another angle: quality of the product
[13:08] Drusilla: And if there are 30 patches, then there should be a 4.0.4
[13:08] PeterThoeny: which is has a real aspect and a perceived aspect
[13:09] Lavr: If we look at the current download topic I think it is a little close to 1 than 2 now. 
4.0.2 was too close to 1.
[13:09] PeterThoeny: best case is we churn out stable production releases where hot fixes are a moot 
point
[13:09] Lavr: I would like to see a download topic with a larger table for the actual download.
[13:10] CDot: PeterThoeny: of course that's an ideal; I'm sure M$ would love to reach that holy grail 
too
[13:10] Lavr: And a smaller table futher down at some distance with hotfixes. And we should not see 
more than maybe 15 hotfixes when the release gets obsoleted by the next.
[13:10] CDot: we have to be realistica bout what an OSS project can do, though
[13:10] CDot: and Drus idea is not - on reflection - a bad one
[13:10] CDot: the only probelm is controlling *what* goes in patches
[13:11] CDot: because unscrupulous people could misuse them.
[13:11] SteffenPoulsen: I like the current direction (Arthurs refactor) on development of balance .. 
as long as we continue in that direction I have no objections
[13:11] Drusilla: 4.1 is the next release, yes?
[13:11] Drusilla: If so, then nothing but patches until then.
[13:12] Drusilla: And patches will be minor-version specific
[13:12] Lavr: We could have called 4.0.3 4.1. It is not important. The important signal with 4.1 is 
that we now allow enhancements as well as bug fixes.
[13:12] PeterThoeny: do not neglect the perceived quality
[13:12] CDot: *minor* enhancements
[13:13] PeterThoeny: if the donload page has a big list of patches to apply it makes a bad impression 
for first time users
[13:13] ArthurClemens: ah, we have to spare the killers...
[13:13] Lavr: Yes. Minor release = minor enhancements PLUS bugfixes.
[13:13] SteffenPoulsen: patches, just .. larger :-)
[13:13] CDot: PeterThoeny: you can avoid that by rolling up patches
[13:13] ArthurClemens: but first time users that cannot find the patches will get the bad experience 
later on
[13:13] Drusilla: Or it shows that people are maintaining the product
[13:14] HaraldJoerg: ...where "minor" should be defined in terms of quality risk and not amount of 
lines of code
[13:14] Lavr: I do not want sa large list. Looking at 4.0.3 as it is today I would not put more fixes 
than the one that is there and the updated language file that came in late.
[13:14] SteffenPoulsen: I think the suggestion in numbers (10-15) is good, that's about a patch per 
week or so
[13:14] Lavr: Even less.
[13:14] PeterThoeny: arthur: the insatllation and upgrade docs clearly state to check the known 
issues page,
 and the download page link to the known issues page
[13:14] SteffenPoulsen: lesser is better :-)
[13:15] Drusilla: Hiding fixes suggests one has something to hide
[13:15] Lavr: Yes. 15 would be maximum. A typical good hotfix is new languages. That also signals 
positive development.
[13:15] CDot: yep
[13:15] Lavr: And we do not have time to produce that many hotfixes anyway.
[13:16] ArthurClemens: Peter: they will not be found like they are now
[13:16] CDot: how do we control what goes into hotfixes?
[13:16] Drusilla: And if bugs don't get fixed, support issues go way up
[13:16] CDot: is tht something for the release manager of the next release to decide?
[13:16] ArthurClemens: It is not about reading, but about visually understanding
[13:16] CDot: I think it is
[13:16] Drusilla: (bug fixes don't get applied, I mean)
[13:17] Lavr: Today the known issues page is mainly a list of a small selection of bugs and with no 
download you can install. You will have to figure out how to sneak out a patch from SVN. Not user 
friendly at all.
[13:18] CDot: agreed
[13:18] PeterThoeny: may be the solution is to add a "hotfix section: to the known issues page?
[13:18] CDot: we could do with some tool support for building patches, though
[13:18] Drusilla: I don't even know what a hotfix *is*
[13:19] CDot: it's a patch
[13:19] Lavr: I would like to see the hotfixes listed on the download page - but less prominent than 
it is on 4.0.3
[13:19] PeterThoeny: patch recommended to apply
[13:19] SteffenPoulsen: if we can agree current direction is good, I think we can trust those working 
on this (Kenneth+Arthur) to go a bit further if they feel like it
[13:20] PeterThoeny: as it is now, the hotfix table is bigger than the actual download table
[13:20] Drusilla: Seems like a combinatorics problem
[13:20] PeterThoeny: i find this distracting, it gives also a bad first time impression
[13:20] CDot: roll up the patches, then
[13:20] Lavr: Yes Peter. The 4.0.3 does not have the right balance. But that is something Arthur - 
the master of CSS can improve better than any
[13:21] Drusilla: Buggy releases also give a bad first time impression.
[13:21] PeterThoeny: a simple solutin is to add a link below the download table to a "hotfixes" 
section on the known issues page
[13:22] ArthurClemens: are we talking about http://twiki.org/cgi-bin/view/Codev/DownloadTWiki?
[13:22] Lavr: I get a good impression when I see software which is very clearly maintained. And we 
sometimes get the same support question again and again on a bug which is fixed but not yet released. 
THose are the obvious hotfix candidates
[13:22] Lavr: Yes Arthur
[13:23] ArthurClemens: _the hotfix table is bigger than the actual download table_ ?
[13:23] Lavr: In practical the download page has 50+ links. People do not find them. We find them 
because we know the page so well
[13:23] ArthurClemens: of course, the download table is one line
[13:24] ArthurClemens: yes, visibility should be improved
[13:24] *** Dzaster has joined #twiki_edinburgh.
[13:24] SteffenPoulsen: this is web 2.0, constant beta / continous improvement are here to stay, the 
new generation knows this .. I think it's more of a first impression issue we're discussing now
[13:24] PeterThoeny: how about this:
 - remove the "Release complements and fixes" table, and
 - add this: Please apply the _recommended_hotfixes_ and read also the _known_issues_ topic
[13:25] ArthurClemens: I don't agree
[13:25] ArthurClemens: I want to offer our users the complete picture
[13:25] ArthurClemens: "here's the download" and "here's what you need next"
[13:25] ArthurClemens: (not copy)
[13:26] PeterThoeny: the alternative is to create high quality product: 4.0.4 with the hot fixes
[13:26] Lavr: I agree with Arthur here. When you download you need to get the overview of what you 
need.
[13:26] ArthurClemens: "Release complements and fixes" does not need the gray band at the top
[13:26] ArthurClemens: i.e. should be made more natural part of the page
[13:26] Lavr: We will annoy our users if we make too many small patch releases. Also our existing 
users will love to be able to apply only the most urgent bugfixes.
[13:27] Lavr: Why don't we ask Arthur to try and re-arrange the download page so we get BOTH a good 
impression and the extra downloads visible in a less provoking way than now.
[13:27] Lavr: ?
[13:27] ArthurClemens: and we don't want them to land on the KnownIssuesOfTWiki04x00x00 page where 
they will get lost
[13:29] Lavr: In a normal release cycle we will add 2-3 hotfixes the first week after the release 
because there is always something that comes up when many people install the new release. And then 
only once every month when something big comes up.
[13:29] PeterThoeny: arthur: feel free to refactor the known issues page again if people get lost 
(although i find it just fine)
[13:30] PeterThoeny: brainstorming: what about _one_ hotfix, a cumulative one?
[13:30] ArthurClemens: Its just that it contains much information that is not needed for the 4.0.3 
release
[13:31] CDot: PeterThoeny: that's a good idea, for another reason
[13:31] CDot: if we don;t make them accumulate, then dependencies will be hard to manage
[13:32] SteffenPoulsen: we should be a aware that when a hotfix is created it is often out of 
personal drive / motivation for the issue, doing cumulative patches is something else
[13:33] PeterThoeny: +92 min
[13:33] SteffenPoulsen: so I agree it's a brilliant idea, but I see a weak part in implementation 
(unless automated, of course)
[13:34] PeterThoeny: it could be automated somewhat
[13:34] PeterThoeny: a hotfix directory in svn
[13:34] PeterThoeny: where you can drop files (with proper dir structure)
[13:34] PeterThoeny: and a build switch to create the hotfix
[13:35] Lavr: I would not want to hotfix based on a badly tested intermediate SVN version. Hotfixes 
have to be well tested fixes tested applied to the latest released TWiki.
[13:35] SteffenPoulsen: something like that would indeed help
[13:35] SteffenPoulsen: but let's put that up for a codev topic and brainstorm a bit more on it
[13:36] PeterThoeny: lets put this as an action item
[13:36] PeterThoeny: anyone taking it?
[13:37] Lavr: I still think we need to discuss something we can SEE! And using Arthur's skills as 
web designer to make a download page proposal would be something to make decisions on.
[13:38] Lavr: It can be a "test download page" on codev.
[13:38] Lavr: With 10 imaginary hotfixes
[13:38] CDot: good idea
[13:38] PeterThoeny: i think we can trust arthur to make sensible changes
[13:38] PeterThoeny: why not directly on the download page
[13:39] Lavr: OK with me. Only reason for a test pages is to see how it looks with more than 1 hotfix.
[13:39] PeterThoeny: of corse, up to arthur, create a demo page if you feel like
[13:39] Lavr: Do you take that action Arthur?
[13:41] PeterThoeny: seems like arthur stepped oy for a moment
[13:41] Lavr: Looks like he is away for a minute. I assume it for the minutes. Scream if you disagree 
Arthur
[13:42] PeterThoeny: shall we move on to the next item?
[13:42] ArthurClemens: I'm back
[13:42] ArthurClemens: reading back
[13:42] Lavr: a.i. : Arthur: Create an improved download page with better balance between main 
download and Release complements. May choose to do a test download page with 10 imaginary hotfixes.
[13:42] ArthurClemens: ok fine!
[13:42] *** Soronthar has joined #twiki_edinburgh.
[13:42] PeterThoeny: good
[13:42] PeterThoeny: ---+  3. Next big release focus
[13:43] PeterThoeny: hi rafael!
[13:43] ArthurClemens: somewhere end of this week
[13:43] Lavr: Hi Raf
[13:44] PeterThoeny: the edin topic at http://twiki.org/cgi-bin/view/Codev/EdinburghRelease states 
the release focus
[13:44] PeterThoeny: that is a starting point
[13:44] PeterThoeny: Desired outcome: Gathering fresh input.
[13:44] Lavr: WhatIsIn04x01 ?
[13:44] Lavr: Are you thinking 4.1 or 5.0 now?
[13:45] ArthurClemens: I remember in March we would do an exercise
[13:45] ArthurClemens: but we got hung up by the releases
[13:45] Drusilla:  The irony of this item leaves me speechless
[13:45] PeterThoeny: i see "next big release focus" as 5.0 (and partly 4.1)
[13:45] PeterThoeny: so this topic is mainly a brainstorming session
[13:46] ArthurClemens: I miss the goals we want to reach
[13:46] PeterThoeny: "Desired outcome: Gathering fresh input"
[13:46] PeterThoeny: e.g. no decision, just brainstorm
[13:47] PeterThoeny: which is important too :-)
[13:47] Lavr: The main thing my users keep on crying about is better editing. They do not like TML. 
Wysiwyg is not working well enough. Too much topics get destroyed by it
[13:47] ArthurClemens: A lot of people have added features/wishes at the bottom
[13:47] PeterThoeny: kenneth: that is a good one
[13:48] ArthurClemens: but we need to connect them and bring focus
[13:48] CDot: Lavr: you should create your own roadmap topic
[13:48] PeterThoeny: on editor: wysiwyg should be seemless
[13:48] Lavr: I showed some of the concept work that Sven have been working on as plugins where you 
edit only a section at a time as TML and see the rest in "normal" mode.
[13:48] ArthurClemens: the roadmaps should be connected
[13:48] PeterThoeny: crawford did an excellent job on the diffucult task of tml html tml roundtrip
[13:48] CDot: ArthurClemens: yes; wish I knew how
[13:48] CDot: Wysiwyg is the wrong approach
[13:48] PeterThoeny: but it can never be perfect due to html editor differences
[13:49] CDot: it isn't needed in wikis
[13:49] Lavr: And that concept was well received. Editing one section in TML when you see the context 
in normal mode seems very acceptable to people.
[13:49] CDot: what is needed is context-focused editing
[13:49] CDot: but that needs more internal changes before TWiki can handle it
[13:49] CDot: esp. a better REST interface
[13:50] Lavr: So you are talking about the same CDot?
[13:50] ArthurClemens: For instance, commercial wikis are proclaiming more ease of use 
http://www.technologyreview.com/read_article.aspx?ch=infotech&sc=&id=17009&pg=1)
[13:50] PeterThoeny: after trying out socialtext i must say it is a seemless experience to 
instantaneously edit the page in wysiwyg style
[13:50] PeterThoeny: very intuitive for users
[13:50] Drusilla: More and more products are using wikimedia for their product support
[13:51] ArthurClemens: to accept Wikimedia syntax is also user friendly
[13:52] PeterThoeny: now that is revolutionary idea!
[13:52] PeterThoeny: twiki with wikimedia syntax
[13:52] ArthurClemens: will shut up "I have to learn yet another markup"
[13:52] CDot: not a new idea
[13:53] CDot: we batted that one around a couple of years ago
[13:53] Lavr: You need some geek/nerd/TML mode for the advanced features that people also appreciate 
such as advanced searches etc. What people have a great issue with is to find their way around a 
large document on TML mode.
[13:53] CDot: it can be done; in fact, it's fairly easy
[13:53] CDot: just needs a programmer to care enough to do it.
[13:53] CDot: but it's missing the key problem
[13:53] Lavr: Even if Wikimedia is popular I would say that 99% of my users could not care less if 
we used their markup instead of our own.
[13:54] PeterThoeny: we have a large market share in the corporate space, do we need/want that?
[13:54] PeterThoeny: we would alienate many twiki users
[13:54] HaraldJoerg: Lavr hit the spot.  With firefox one can't even "find" the location you want 
to edit in the text box
[13:55] Lavr: That is why the context editing that Sven has a concept of already is something I 
strongly believe will be a great success.
[13:55] HaraldJoerg: I doubt one can simply *replace* TML by something else.
[13:55] CDot: HaraldJoerg: exactly
[13:56] CDot: you can, however, have a wiki substrate that is syntax-independent
[13:56] HaraldJoerg: The best thing I can think of is having other syntaxes while *editing* which 
are then converted to TML when saving
[13:56] CDot: since TML is just a "user presentation" thing
[13:56] CDot: don;t want to save in TML
[13:56] CDot: it's too lossy
[13:56] PeterThoeny: but we could make it customer focused: "i am used to wikipedia, please show 
me the markup in mediawiki style"
[13:56] CDot: yu can and you can't
[13:56] PeterThoeny: e.g. translate on the fly on beforeedit / afteredit
[13:57] CDot: wikimedia and twiki have overlapping markup
[13:57] CDot: but not 100% overlapping
[13:57] CDot: each doesn stuff the other doesn't do
[13:57] CDot: that is the hardest thing to solve
[13:57] ArthurClemens: could it be done in a plugin?
[13:57] PeterThoeny: yes, i think so
[13:57] ArthurClemens: (except variables)
[13:58] PeterThoeny: the plugin does not need to support the syntax 100%
[13:58] PeterThoeny: most users use only 10 or so markup commands anyway
[13:58] HaraldJoerg: That's dangerous - what if you edit a topic containing unsupported things?
[13:58] Drusilla: One could also face the fact that TWiki isn't the solution for everyone
[13:58] CDot: yes it does; if it doesn't you will alienate an awful lot of people
[13:59] PeterThoeny: if you edit a topic that has unsupprted things you simply leave it alone, e.g. 
before edit handler and after edit handler do not touch it
[14:00] Drusilla: parking lot
[14:00] PeterThoeny: only the widely known syntax is translated, e.g. bullets, headings, bold etc
[14:00] SteffenPoulsen: syntax .. a question I tend to get surprisingly often is "can I use BB code? 
(I think it is called)" .. ppls first experiences appears to be in foras, often .. but we usually 
agree TML is better (they want to make me happy I presume :-))
[14:00] PeterThoeny: (we are in a brainstorming session, people not intersted can do something else)
[14:01] PeterThoeny: yes, a BbSyntaxPlugin and a MediaWikiSyntaxPlugin would be useful
[14:01] PeterThoeny: i think it can be done with the existing api
[14:01] *** Drusilla has left #twiki_edinburgh.
[14:02] PeterThoeny: crawford, back to wysiwyg, can you elaborate why it is not needed?
[14:03] PeterThoeny: i guess he stepped out for a moment
[14:04] PeterThoeny: what other ideas do we have?
[14:04] PeterThoeny: we are at +124 min
[14:04] CDot: Lavr said it; component editing
[14:04] PeterThoeny: shall we continue until +150 min?
[14:04] CDot: if you can edit-in-place with a suitable component everywhere, Wysiwyg actually just 
gets in the way
[14:05] CDot: example: double-click anywhere in the page, a mini-editor appears to let you edit the 
aragraph you clicked
[14:05] Lavr: If we could do a context based editor where only the current section is edited and the 
rest is shown normally - AND we could offer some kind of Wysiwyg for just 2 features: headlines and 
bullets, while showing everything else as pure text based TML my users would be very very happy
[14:05] PeterThoeny: so you say, sectional editing with tml is ok?
[14:05] CDot: yes, it is
[14:06] PeterThoeny: i do not think that marketeers and sales folks would agree
[14:06] CDot: I use Svens code all the time now, and I love it
[14:06] CDot: bugs and all
[14:06] Lavr: Peter - you should try and play with the plugin Sven checked in recently. It is not 
finished. It lacks features. But the concept looks very convincing to me
[14:06] *** Flenser has joined #twiki_edinburgh.
[14:07] PeterThoeny: i have not used sven's plugin, but use sectional editing of dokuwiki and 
mediawiki, and like it
[14:07] PeterThoeny: but not as good as compared to the ease of use and speed of socialtext
[14:08] PeterThoeny: socialtext's wikiwyg changes from view to edit on the fly, no roundtrip to the 
server
[14:08] Lavr: But can social text so all the smart TWiki applications and advanced formatted searching 
etc which requires that you can write codes?
[14:08] Lavr:  But can social text DO....
[14:08] PeterThoeny: most probably not possible
[14:09] CDot: the major advantage of component editing is the ability to have "smart application" 
components
[14:09] PeterThoeny: but what would be possible is to support the tml and some of the plugins, and 
deliver the rest as plain text
[14:10] Lavr: Yep. And Sven's plugin only requires that you click on the text. Then you can edit.
[14:10] PeterThoeny: e.g. html would be shown as html (not rendered)
[14:10] CDot: are we still following the agenda?
[14:10] CDot: or is this now a freeform discussion?
[14:10] PeterThoeny: we are following the agenda, yes
[14:10] Lavr: We are at the last point and brainstorm so we can go in orbit now
[14:11] PeterThoeny: free form discussion on next release focus
[14:11] CDot: ok, thx, I was lost
[14:11] PeterThoeny: ok, any other ideas for release focus?
[14:11] ArthurClemens: Lynnwood has made groupings of his features 
http://twiki.org/cgi-bin/view/Codev/EdinburghRelease). Does it make sense to expand this with other 
people's ideas, i.e. group all ideas in captions?
[14:13] CDot: only if someone is owning the list
[14:13] Lavr: Performance is always a topic I bring in. Especially seeing that people want to add 
more translations makes me nervous.
[14:13] CDot: otherwise it will get into an unreadable mess really fast
[14:13] Lavr: RIght now I add 1 full second to the rendering when I activate i18n.
[14:14] ArthurClemens: Yes, someone has to maintain the list
[14:14] PeterThoeny: yes, performance is something we need to address
[14:14] CDot: what we need is....... a release manager!
[14:15] Lavr: Unmatched ) in regex; marked by <-- HERE in m//Codev/EdinburghRelease) <-- HERE $/ at 
(eval 17) line 7.
[14:15] PeterThoeny: or we may lose market share
[14:15] ArthurClemens: someone working on a db backend?
[14:15] Flenser: do we have a reliable way to measure market share that we'd know if we're losing 
it?
[14:16] CDot: I'm being dragged off to the pub, kicking and screaming. See you all later! (BTW my 
action is DONE)
[14:16] *** CDot has left #twiki_edinburgh.
[14:16] Lavr: My fault
[14:16] HaraldJoerg: You lose market share only if you implement new functions inefficiently
[14:16] HaraldJoerg: while the competition implements the same thing efficiently
[14:17] Lavr: As TWikis slow down by themselves as they get more topics and more users you also at 
some point look for something else.
[14:17] Lavr: So even maintaining status quo on performance is not acceptable
[14:17] Lavr: We need to scale better
[14:17] PeterThoeny: agreed
[14:17] PeterThoeny: question is how
[14:18] PeterThoeny: on i18n, one answer could be to translate once per installation instead of on 
the fly
[14:18] Lavr: First we need to measure. Harald you seems to know something about doing better 
profiling of perl code.
[14:19] Lavr: I think today i18n works by comparing english strings in the .po files. That must be 
very inefficient.
[14:19] PeterThoeny: on access control and preferences, they could be cached out of band (still 
stored in band because of audit trail)
[14:20] PeterThoeny: i just did a test with a web locked down to a 60k member group
[14:20] PeterThoeny: 18 sec vs 1 sec
[14:20] PeterThoeny: so, not scalable at the moment to groups with 50+ members
[14:20] Lavr: Yes. That shows the problem. And try a search in a web with 60000 topics. Probably 
similar problem.
[14:21] HaraldJoerg: But in a corporate environment with 60000 topics I'd go for inktomi or ultraseek 
or whatever
[14:22] PeterThoeny: rule of thumb for not losing train of thought when doing a step by step task: 1 
sec
[14:23] PeterThoeny: performance is also an architectual question
[14:23] PeterThoeny: some parts of a topic could be prerendered (as in jsp and asp)
[14:23] HaraldJoerg: ...and a question of defining the steps in a step by step task
[14:24] HaraldJoerg: I'd go for pre-rendering during save - one save has many views
[14:24] PeterThoeny: exactly
[14:24] PeterThoeny: you could prerender bullets, headings etc, but not variables
[14:25] PeterThoeny: so part of the rendering is done once on save, part is done on each topic view
[14:25] Lavr: Current searches cannot find the rendered variable values either so partly pre-rendered 
topics could work.
[14:26] HaraldJoerg: I'm thinking more TemplateToolkit like: Variables can be pre-parsed to perl calls 
or converted to opcode trees
[14:26] PeterThoeny: yep, same as jsp where content gets compiled into java code
[14:26] Lavr: But when you search - we cannot keep on searching through 1000s of topic files. Some sort 
of indexing would be needed.
[14:27] HaraldJoerg: Lavr: Yes.  But there are pretty good indexers on the market.
[14:27] HaraldJoerg: You can't beat them.
[14:27] PeterThoeny: on search, we need to distinguish regula search and search used by twiki apps
[14:28] PeterThoeny: for regual search we have plucene, swishi(sp?) etc
[14:28] Lavr: We can use the technolody I would hope. It is the twiki app search that I think about 
[14:28] PeterThoeny: for twiki app search some integration of twiki and indexing is needed
[14:28] Lavr: We use these little searches everywhere in twiki apps. And they get slower and slower 
as topics are added.
[14:29] HaraldJoerg: ...where we, as far as I know, do not have to fear any competition from other 
wiki engines....
[14:29] PeterThoeny: either with an internal search engine, or a good integration with a search engine
[14:30] PeterThoeny: goal is to keep page access time within one sec
[14:30] Flenser: why not do the searches in the background as topics get added, do the most popular 
topics first
[14:30] PeterThoeny: for regular use
[14:31] Flenser: i.e. so that every edit update WebHome, WebSearchesForAllWebs etc
[14:31] PeterThoeny: we are at +150 min
[14:32] PeterThoeny: sam, somthing like varcacheplugin?
[14:32] Flenser: yeah, I just thought of that
[14:32] PeterThoeny: that caches variables of selected topics?
[14:33] PeterThoeny: actually you go one step further, update the cached variables in the background
[14:33] PeterThoeny: instead of when that ppor person looks at a page with outdated cache
[14:33] PeterThoeny: "poor"
[14:33] Flenser: hmm, how about make search smarter, so that each unique search caches some of the 
raw search so it only has to search topics that have been edited since it last ran
[14:34] HaraldJoerg: PeterThony: "background" can be av ery bad idea unless the server is idle most 
of the time
[14:34] HaraldJoerg: s/av ery/a very/
[14:35] ArthurClemens: that is why indexing is often done on another server
[14:35] HaraldJoerg: So we're going for a TWiki cluster? ;-)
[14:36] PeterThoeny: on scalability, what would help is a how to doc on how to setup twiki in a load 
balanced server / storage backend env
[14:36] Lavr: In the years to come multi CPU will be more common. I just bought a Pentium D - just to 
play with.
[14:37] PeterThoeny: shall we close the meeting, or continue some more?
[14:37] Lavr: It actually parallel TWiki very well. When I do an "ab -n 20 -c 4" the speed difference 
is incredible compared to single CPU. So in future we can count on background processing doing stuff
[14:37] Lavr: I actually have some doc writing to do.
[14:38] PeterThoeny: ok, lets close the meeting
[14:38] Lavr: Steffen. If you can help with the SVN task I just emailed about.
[14:38] PeterThoeny: some good brainstorming
[14:38] PeterThoeny: thanks all!
[14:38] Lavr: Yes. Very good. Thanks. 
[14:39] ArthurClemens: great, before midnight!
[14:40] HaraldJoerg: I wonder what time of day Sven is going to suggest for the next meeting :-)