Tags:
edinburgh1Add my vote for this tag create new tag
, view all tags

Minutes of Edinburgh Release Meeting, 06 Mar 2006

Logistics, Participants, IRC log

Agenda

TWiki 4.0.2 release

Post-Dakar development model

  • Desired outcome: Clarification on how to use DEVELOP and TWIKI4
  • From KennethLavrsen: I think people are quite confused and not in agreement with
    • When to checkin updates to DEVELOP and then to checkin to TWikiRelease04x00
    • When to tag bug reports to 4.0.2. Last time I got the impression that it was for bugs that should be fixed in the 4.0.2. And if a bugfix for 4.0.2 has only been committed to DEVELOP and you raise a bug, shouldn't the extra bug reports be tagged to 4.0.2?
    • The current idea of checking in to DEVELOP and merge to 4.0 does not work well. Instead all bug fixes should be committed to 4.0 and DEVELOP.
    • What about plugins? They are both places. Not good! Will go wrong!!
  • From PeterThoeny: The ProductionReleaseStatistics shows that we need to improve the quality of TWiki in Edinburgh. We should try hard to refine the development model so that we get back to the quality goal of the TWikiMission of "few or no bugs for production releases."

Action Items

4.0.2

  • ProcessForTWiki4PatchReleases is proposed way to admin Dakar updates
  • PatternSkin update accepted for 4.0.2 as an Exception because of the importance of the bug it resolves. Otherwise only the patch tagged bug fixes should be merged in.
  • CrawfordCurrie asks for help from developers to checkin merges.
  • Need a machine to run TWiki 4 on. Arthur suggests his Dreamhost. Kenneth will try to mirror TWiki4 on his merlin.lavrsen.dk line. Arthur with Template login and Kenneth with Apache login.
  • Crawford helps Arthur merging in pattern.
  • Need Steffen's changed merged. Help needed.
  • Merging in SVN: MergingInSubversion
  • Goal for merges is 13 Mar 2006
  • Testing is two weeks from the Pattern Skin merge and test machines setup
  • Small fixes that people want to enter 4.0.2 (doc fixes without risk) should be marked urgent.
  • Peters doc changes on SVN: 8760, 8772, 8773, 8805, 8820, 8830, 8835, 8884 all from Bugs:Item1611 should go in.
  • Target date for release is 20 Mar 2006
  • Release meeting Monday 13 Mar 2006 - 21:00 GMT
    • Agenda: Merge process status, Testing Status, Doc Status

Post-Dakar development model

  • Edinburgh or just Edin in everyday quick typing
  • Agree to try the model proposed by Crawford. ProcessForTWiki4PatchReleases
  • Plugins is a problem. Should only be ONE place. Decision?
  • There are two schools. Decision not made.
    • Plugins are in all branches
    • Plugins are in ONE branch
  • Plugins must be in TWiki4 branch the next weeks. Otherwise pseudo-install will not work. I believe CDot "volunteered" to merge them over?
  • On dev model for core, http://twiki.org/cgi-bin/view/Codev/OneSvnBranchPerRelease needs to be updated

IRC Log

Pattern Skin Bug Update for 4.0.2 agenda item above.

added by KennethLavrsen - 06 Mar 2006

Some good news. I went through all open Pattern Bugs. And many of them are resolved with the improved Pattern (Bugs:Item1672). I have made this status to aid the discussion and make it shorter so people do not have to search in bug reports during the meeting.

I am putting checkmarks on the ones that got closed with the 1672 merge -- KennethLavrsen - 12 Mar 2006

Fixed

  • DONE Bugs:Item1146 (Two Create buttons): Fixed by 1672
  • DONE Bugs:Item1147 (Raw view should show normal view action button). Implemented as 'View Topic' link when in raw view with in 1672.
  • DONE Bugs:Item1623 (Web Left Bar border margin in FF 1.0.7). Confirmed fixed with the new pattern skin in 1672.
  • DONE Bugs:Item1634 (ALERT! The big width bug). Fixed by 1672
  • DONE Bugs:Item1430 (inconsistant width constraints on top bar and content area). Fixed by 1672.

Easy like changing one word

  • DONE Bugs:Item1148 (Change Update to Save in Edit settings): Change ONE word.
  • DONE Bugs:Item1616 (inaccurate password changed message): I propose adding one little 'may' - see bug report - and close it as part of 1672 updates. Or discard it because it is necessary with Apache login to close browser sometimes.

Partly fixed - still need more actions or discard

  • Bugs:Item959 (Change top bar image and heigh by preference). Top bar image was already implemented in 4.0. Height requires template change.
  • DONED Bugs:Item1331 (header art for PatternSkin). Not sure if this is already implemented or there is anything additional the reporter wanted. Maybe a discard candidate.
  • DONED Bugs:Item1550 (does not show TOC properly). Seems like a discard candidate because reporter never provided a test case that could make developers reproduce it.
  • Bugs:Item1659 (Splitting pattern skin templates into smaller chunks). Partly done. If more splitting is needed it should be Edinburgh.
  • Bugs:Item1704 (Make pattern skin depending on TwistyPlugin instead of TwistyContrib). Maybe done already? Then move it up. If not. Edinburgh.

Not yet fixed

  • Bugs:Item1560 (favicon.ico being fetched even when there is none attached to web preferences). It gives annoying error logs. People can work around it by adding a favicon.ico. Should be fixed but not urgent in KJL's humble oppinion.
  • Bugs:Item1617 (WebLeftBarPersonalTemplate always points to TWiki Web). KJL does not understand it. Need to try what he is reporting to see what it is. If he is right it is an easy fix.
  • Bugs:Item1417 (TWikiPreferences for CSS mixes up skin styles). Obvious Edinburgh candidate. Needs more cross skin planning.
  • Bugs:Item1327 (Make "save" button on preview screen conditional on "text" parameter). Can have surprising effects. Edinburgh!
  • Bugs:Item602 (Rewrite "additive" templates using COVER). Edinburgh!
  • Bugs:Item1783 (Plugin updates to work with 1672). Two of the plugins should be have their templates updates so they are ready for 4.0.2 release. EdittablePlugin is broken (code will not run).

Conclusion: Merging in this one closes 6 bug reports (including this one). Two more can be closed by adding or changing one word in templates. 1617 may be an easy one.

There are some discard candidates. And about 6-10 Edinburgh items where none of them are of urgent bug nature.

Back to: EdinburghRelease

Comments / Feedback

Hate to miss this meeting, IRL activities prevented me. But I think these meetings needs some sort of moderation? Looking at the logs I see 3-4 parallel threads going on most of the time (not always on topic), and a lack of conclusions or decisions.

I am afraid we will loose backup and interest in these meetings if we can't figure out how make them a bit more efficient.

One suggestion would be to slice up the agenda in two, and take a minimalistic approach in first part of the meeting:

  • Reserved for issues that are more or less ready for a "vote" or "obstacle-elimination" (pre-submitted agenda items / "pre-argued" stuff). People are expected to be context-aware/updated on items.
  • Chairperson sees that everybody is heard for a final word, and that the discussion is on-topic.
  • Chairperson makes sure that as firm a conclusion as possible is reached.

First part should be no longer than 30 mins, and people are free to leave or lessen their attention after this.

The form of the second part of the meeting would probably be comparable to what is seen in the log from this meeting.

-- SteffenPoulsen - 08 Mar 2006

I would also like to apologize for not being available for this meeting (and not letting someone know in advance). I was still recovering from a weekend-long surprise 50th birthday bash for yours truly.

Having facilitated the last few sessions, I unfairly let the facilitation role to role fall to Peter. It is quite demanding faciliating these sessions and doing that while participating in any meaningful way is next to impossible. That's true for f2f meetings and all the more so for these "virtual" meetings. My apologies to Peter for letting fall to him this thankless task.

I would like to echo Steffen's concerns and support the general intent of his recommendations. Even in f2f meetings, I consider it critical to have a clearly stated intended outcome and facilitate strictly towards that end. When the discussion devolves into multiple overlapping tangents, it's a formula for frustration and conflict. I am convinced that this risk is multiplied several times in these virtual meetings. Consequently, I have concluded that it's important to facilitate these sessions even more strickly than a similar f2f meeting.

In line with that, I strongly support the first part of Steffen's recommendations. I suspect the very best use of these meetings to confirm and "make official" decisions that have already been discussed elsewhere in Codev web. As I've stated elsewhere, I believe that achieving closure on discussions is a weak point on TWiki.org and I think the irc meetings can help this. In some cases, it's just a matter of reconfirming general points of consensus or forge compromises on small points of disagreement. These are best done in "real time" where the key stakeholders can give and take and finally say together "OK, we agree to X."

I'm not sure I agree with Steffen's suggestion that non-decision making part of the meeting should be a free-for-all. I still have concerns about the potential of this format within this medium to spiral out into confusion and un-necessary conflict. I believe our collective efforts would be better served by using open-ended, but still structured, processes that could lay foundation for or forward parallel discussion in TWiki.org. Examples of this would be:

  • Brainstorming - A quick listing of options, concerns, etc. These can provide a starting place for follow-up discussion on TWiki.org.
  • Polling - Take a quick poll of where stakeholders stand on a particular issue that has been previously discussed. This might result in immediate consensus but is more likely to clarify majority/minority positions that would need to be negotiated outside of the immediate session.
  • Scoping and Scanning - Similar to brainstorming but slightly less structured, this is an open-ended discussion to get a general handle on some area of discussion such as a new feature or broad architectural question. Again, this would lay the foundation for follow-up discussion in TWiki.org topics.

There is another concern I would like to raise here. My experience with all on-line discussion mediums - and this has been reinforced with the irc meetings - has impressed me mainly for how easy folks motivations are misinterpreted and how quickly this escalates into conflicts. The immediacy of the irc sessions only increases this risk. Therefore, I would council particular care in how we use this medium or it might have the opposite effect then we seek - exasperating conflict rather than building consensus.

Therefore, I would modify Steffen's proposal as follows:

  • The first part of the session would be devoted to bring closure to previously discussed items using guidelines such as Steffen proposed above.
  • Any tangential topics that arises would be strictly contained by being noted and placed in a "holding bin".
  • After this first part, the second part would address more open ended topics on the agenda or form the holding bin, but still using a fairly strict format such as discussed above.

In conclusion, I think that the irc meetings are a great step forward for the TWiki development community but we should be careful not to load too much on this process. It is still pretty limited and could easily be overloaded, thereby negating it's benefits.

-- LynnwoodBrown - 08 Mar 2006

Funny that the two that found it necessary to give negative feedback on the meeting are the ones that were not there. Probably because one thing you loose when you read a log is the "beat", the "pace". It means a lot to how you experience the meeting.

Maybe there are things that you would have wanted on the agenda that were not there but personally I found the meeting productive because it addressed the most urgent issues and a lot of decisions were taken.

  • We actually agreed what goes into 4.0.2. That is a big and important step. And the decision that was made was - after good arguments bach and forth - accepted by all.
  • ProcessForTWiki4PatchReleases was accepted as the process from now on.
  • There was a decision made for how to classify the bugs.
  • The merge of bug fixes which all developers are responsible for.
  • Goal for merges is 13 Mar 2006
  • Testing is two weeks from the Pattern Skin merge and test machines setup
  • Target date for release is 20 Mar 2006
  • Arthur and Kenneth both setup TWiki4 test machines
  • Release meeting Monday 13 Mar 2006 - 21:00 GMT
    • Agenda: Merge process status, Testing Status, Doc Status

  • Finally we agreed to disagree on the Plugins. Not making a decision is a decision in this case. We were not able to make a decision during the meeting because all had thought about the development model for the engine and the plugins had not been discussed much. Since then there have been discussions on the mailing list and on Codev.

When you read the log there was some noise about the plugin API. Here a moderator should have cut that out of context discussion and deferred it to a later meeting. A moderator is a good thing but a moderator also has to stay out of the heavy discussions. But if you notice most of us ignored many of the statements about the API. They take up space in the log but as I experienced the meeting it did not really disturb the important discussion.

All in all - we did get a lot decided and actual actions started and many already done. And I think that even when waves are high people still like and respect each other and we are having fun on the TWiki project. And that is at the end of the day the most important thing.

If it will help, I can setup a telephone conference call (with free access numbers and a sponser (M)) for a call now and then. It could perhaps create a different atmosphere for some of the more difficult subjects. Skype can also be used but then you can be very few. A conventional phone bridge have room for us all and with all the good (M) get out of TWiki we can for sure pay an hour of conference bridge now and then. Only condition I have is that it ends at 23:00 PM Central European Time so I do not keep my wife awake all night.

My test server is setup and I am testing. http://merlin.lavrsen.dk It updates from SVN every 30 minutes.

-- KennethLavrsen - 09 Mar 2006

Thanks for putting this in perspective - as sketched by you it doesn't look that bad at all, luckily - I am very happy with that.

The voice experiment sounds interesting, don't know what the general opinion is on this?

-- SteffenPoulsen - 10 Mar 2006

Lynnwood: No need to apologize. TWiki is an open source project, there is no obligation to participate, just heartful appreciation for those who do in a constructive way smile

I found the first part of the meeting productive, some decisions have been done as described by Kenneth. On the other hand, the second half of the meeting on the multiple branch (or not) question for Plugins development was very unproductive IMHO. If we can't do better going forward we should consider discontinue using IRC for meetings. I did not a good job in facilitating and participating at the same time.

We can do better if we:

  • Prepare the agenda items before the meeting. Kenneth's Pattern Skin Bug Update is a very good example, it was basically just a "checked item" at the meeting
  • State the desired outcome of each agenda item ahead of time, and try to work towards resolving it
  • Put off-topic items into the parking lot
  • Limit the meeting to 90 minutes
  • Split the facilitator and participation role

Kenneth: Thank you for offering a telephone conf call. I think we should give it a try! We can discuss this in the upcoming IRC meeting.

I would like to express my special thanks to Kenneth and Arthur for providing test servers for TWiki 4.0.2.

-- PeterThoeny - 13 Mar 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt EdinburghMinutes2006x03x06.txt r1 manage 61.7 K 2006-03-06 - 23:41 KennethLavrsen IRC log fro meeting
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2006-03-13 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.