create new tag
, view all tags

Minutes of Georgetown Release Meeting, 2008-06-09

TOC and Agenda

Logistics, Participants, IRC log

1. Review Urgent Bugs with 4.2.1 scope

2. Feature requests for Georgetown Release

Meeting never happened because the developers again chose to boycott the meeting.

This is the last release meeting held without commitment from the major contributors to participate in the democratic release process. -- KennethLavrsen - 09 Jun 2008

Back to: GeorgetownRelease

Comments / Feedback

Does anybody still have the IRC-log and can post it here?

-- MartinSeibert - 08 Jun 2008

Martin. You wrote the above one day BEFORE the meeting.

The log will be uploaded AFTER the meeting wink

If there is a meeting. That requires that developers show up. Last time we were 2.5.

I will NOT walk through open bugs tonight unless someone adds specific bugs to this agenda.

Same with feature proposals. I will not put any proposals forward unless someone want a specific proposal discussed.

This means that if nothing is added to this agenda the meeting will be SHORT.

-- KennethLavrsen - 09 Jun 2008

Sorry, as previously announced in the meeting invite, I could not make this meeting due to another high prio meeting. I usually shift my other meetings so that I can make it to the release meetings.

I find it unfortunate that we have had a number of meetings where key contributors do not participate. I would like to state that we have a democratic process and those who participate can and should make decisions, even if the team is small. In other words, those who chose not to participate cannot claim later on that a decision is not valid.

-- PeterThoeny - 09 Jun 2008

I'm awfuly sorry that you guys moved the meeting from a time that I could not attend, to one that is impossible for me to attend, but, that was your choice.

I'm rather shocked at the antagonism towards voluntary contributors to an open source project, and the general tone of demand - I can't see why blaming people for what has become a non-working process, rather than working out howto adjust the process could possibly be productive.

-- SvenDowideit - 10 Jun 2008

You made it very clear that you would not attend no matter if the meeting was at 21:00 CET or 22:00 CET so we moved it from 22 to 21 in an attempt to get more European developers to participate because the meeting is now before normal bed time.

I have the impression via misc comments in Codev and emails that the lack of participation from Crawford in reality is a boycott. And the rest do not show up because they all know that without the most active core developers the meeting is a farce.

If we were 6-10 people at the meetings we could at least still make decisions, but the people that show up are not interested in the proposals. Not even the people that raise the proposals show up to talk their own cases anymore.

But when I show up and meet 2 other people only then I am not going to put forward proposals and vote them through with 1 vote for and 0 against. The proposals that go to the release meeting are not the ones that are no-brainers or the consensus ones. They are settled in Codev.

The ones that go to the release meeting are the proposals where people have raised concern and where a technical discussion is needed to move the proposal along.

But when both the proposers and the people raising concern stay away from the meetings the meeting has no value anymore and there is nothing the 3 people that show up can vote for or decide or get moving.

Without participation the release process is dead.

There are people that talk about lack of governance. The feature proposals is exactly the ONE area where we have a governance process that worked well when people participated. The same people that want governance are the people that stay away from the meetings.

That tells me that those people do not really want a democratic governance process. They just want to replace one benevolent dictator with another one (themselves).

So if this is the case then let us go back to Peter Thoeny deciding on all feature proposals.

-- KennethLavrsen - 10 Jun 2008

(I made it quite clear that I'm unlikely to attend a meeting at 5am or 6am my local time - interesting how you represent that as somehow unreasonable)

So you've highlighted that the process is broken, but from there you're jumping to blaming the contributors.

I'm sorry, but that suggests to me that your thinking is fundamentally flawed.

-- SvenDowideit - 10 Jun 2008

If I lived in Australia I would not have a problem setting my alarm clock at 6:00 instead of 7:00 one morning every two weeks. At 5:00 I would not consider. I did not expect you to be there last night. But you clearly stated last time this was discussed that you would not be there at 6:00 your time so that is why the time was moved. It is mainly moved because we know Crawford gets up early and punch out early too.

If you say you are willing to get up at 6 I have personally no problem moving back to one hour later. But do not expect us Europeans to sit up till 2 AM just to get you in the meeting at 8 or 9 in the morning. The planet Earth is round and that we have to adjust our timing on as a compromize and the best compromise is us Europeans in bed a bit late and you up a bit early.

But where are the other developers? I discuss with Sven who we all expected to be sleeping. Where are the rest of you? Why have you stopped participating? Why do you whine about lack of governance and then boycott the one governance institution we actually have? How is any other governance proposal going to work if you will not participate in any of it anyway?

-- KennethLavrsen - 10 Jun 2008

actually Kenneth, I am trying to point out, that you are causing issues, and blaming people. Personally, I think part of the reason is that you are making participation unpleasant by doing so. In effect, treating others in this project as your plebs to boss about.

You are implying above that simply because you are willing to shift your alarm clock by one hour, that you can demand others to do the same. That is IMO quite unacceptable - irrespective of the same discussion you and I have had on several other meeting topics - pointing out that for me, getting up at 6am is changing my clock by about 4 hours - and leaving me with about 4 hours sleep.

-- SvenDowideit - 10 Jun 2008

I used to attend release meetings mainly because I was intending to implement feature proposals, and wanted to canvass other views, or because I had fixed (or created) a lot of bugs, and wanted to be available for questions. Because I am not contributing to core dev any more, the motivation for attending the meetings regularly is absent, and I will only attend on the same basis as everyone else i.e. when something comes up on the agenda that I specifically want to voice an opinion on (beyond what I have written in Codev). I'm not boycotting your process, I just haven't felt the need to engage with it for a while.

On governance I made my position abundantly clear after the farce of the release notes and press release during 4.2, and the San Francisco summit meeting. I do not want to be involved with TWiki core dev under the current status quo (ineffective "core team", inactive leadership) because it isn't fun any more. I am not comfortable contributing to core development until there is movement towards a resolution of the TWikiGovernanceProposal1 question.

I never imagined this question would be allowed to drag on this long. It is now four months since the SF summit, and AFAICT nothing has been done to follow up on actions to address this question. To me, this just reinforces the need for change. Please note that I have absolutely no interest in being dictator of the TWiki project, benevolent or otherwise. I just want a governance system which allows TWiki to exist as an open, friendly, independent community project, where contributors are empowered and decisions get made in public.

For better or for worse, I still remain a key stakeholder in TWiki, just because I have done a great deal of the development work on it over the last few years. I hold the all-time record for checkins, I have fixed more bugs than anyone else since records began, and have proposed and implemented many features. I still care a great deal about the future of TWiki, and it took a massive dose of negative vibes to make me walk away as far as I have done. There is one thing that might make me re-engage with the TWiki core, and that's a resolution of TWikiGovernanceProposal1.

BTW for those of you thinking "why don't you just fork then", I have never had any intention of forking, and have none now. I don't believe a community fork is in the best interests of TWiki. There is no need; it's open source, developed by the community, and is independent of commercial interests. As long as there is nothing about the project that compromises these principles, there is nothing to fork away from. If TWiki can't resolve the governance question then there are other technologies, which are now almost as well placed as TWiki, waiting in the wings. A fork is IMHO pointless.

-- CrawfordCurrie - 10 Jun 2008

You are trying to hit Peter, Crawford. But it is ME you harm the most because it is me that has the release manager role. It is me that have the role to make sure feature proposals are processed instead of ignored. And I have had enough now.

And Peter. Get that core team proposal on Codev now. It is ridiculous that this is still open.

Peter and Crawford - pick up the dammed phone and call each other.

-- KennethLavrsen - 10 Jun 2008

I am not trying to hit anyone. I want a peaceful, productive life, which is why I backed away from core dev in the first place.

-- CrawfordCurrie - 10 Jun 2008

I feel a bit helpless reading all these comments. I have no idea what the true problems are and I do not know, what to do to help cure them. But I feel a bit "quixotic" thinking about usability-improvements when the core development-team is falling apart meanwhile. Is there anything I can do to help?

-- MartinSeibert - 10 Jun 2008

I cannot believe what I'm seeing: Another great open source project going down the drain due to personal differences between the core developers. Sad. Very sad.

FFS, get over with your stubborn, pridefilled, disgruntled, pissed little egos, pick up the phone, sort this pathetic misapprehension out and get back to work. You're better than this!

We, your customers and users, need all of you, dammit!

-- JoachimBlum - 11 Jun 2008

More demands and insults? that is a wonderful way to encourage and 'pay forward'. I don't know why some users of open source think that this kind of attitude begets more contributions!

I'm still doing everything I can for TWiki - what are you doing?

-- SvenDowideit - 11 Jun 2008

Sorry for being more rude than necessary. At least I rang a bell there ;-).

I've seen a lot of projects failing because of this very pattern I'm seeing here. Ego. Always ego. Makes me mad and wanna puke. The very active and friendly development team was one of the key criteria why I chose TWiki because it promised a guaranteed future. That future is gone now. Or is it?

And as for what I'm doing for TWiki: Yes, I'm just a user. Just a little admin of an intranet tech-department TWiki with ~300 registered users and 100k hits/month. Our productivity must have gone up since I installed it, otherwise the management would have canceled the project and fired me. My users and I are very satisfied with your work. So what am I doing for TWiki? I'm using it.

If you don't have users, what's the point anyway?

-- JoachimBlum - 11 Jun 2008

Okay granted there's no point in having a release IRC meeting without participants. Is there a way to do the same decision process asynchronously? Why is the key to decision making an IRC chat? Can't we just resolve issues using TWiki only? For me, the most important thing in "the process" is not the IRC meeting on #twiki_release. Moreover it is (a) the bug tracker and (b) proposals at Codev. Nothing else. That's where things happen. Most interesting things have to be resolved offline non-IRC anyway. IRC isn't appropriate for other reasons also. So just get away with this chat-based release process and maybe things work out better.

Well, and with regards to the current release blockers in the bug tracker: Yes, there are some that are desperately waiting for feedback. But there's none from those that might be able to answer. That's where I am having problems and where things got stuck also. Not sure what's going on here.

Anyway, my conviction is that an async mode is the best we can do on this project. There's a far higher probability people will find a spare minute reading and commenting on some bug item or a proposal than attending an IRC chat midnight.

The rest of it is just to get back to a more friendly cooperation. Kenneth, you should really improve your social skills, so to say ;). Peter, well I've got the impression that you are not participating on bug items in form and content at all actually. At least I don't see any impulses from you, nor any bug fixing action. I am not asking for governance. I am asking for substantial participation to lead by example. (Just take the miserable state and organization of the documentation in the TWiki web that we ship.)

In the end there's no point to try to resolve a governance issue if there's nobody left doing the work.

Besides the actual code development efforts and a stalled TWikiGovernanceProposal1 discussion, there are some other processes that are stalled as well, for example the redesign of twiki.org, NewNavigationModelForTWikiDotOrg etc. There is zero progress here as well. So stop bashing Crawford.

-- MichaelDaum - 11 Jun 2008

thanks for bringing back some actual ideas on how to improve this situation

-- CarloSchulz - 12 Jun 2008

Michael: I disagree on me not participating. There is more than coding and bug fixing. May be you see the 4-6 hours I spend a day on open source TWiki a waste of time? Somebody needs to do the non-sexy work on twiki.org.

Joachim and Martin: I would not say the core dev team is falling apart. It is normal in open source projects that people come and go, and I (as everybody else) is thankful to all the contributions a person did while active in the project. The reality is that one person who happened to be very active, stopped contributing and choses not to participate in our democratic process. This is his choice and I respect that. As the community lead I urge everybody to help recruit new developers, as I am actively doing. TWikiCommunity, please stand up and participate in the meetings, this is the most effective way to support the community. Our TWikiReleaseManagementProcess has been developed by the community after all. Don't let anyone spoil the fun!

Kenneth: I am working on the new proposal, it will be based on the Ubuntu model. It is going slower than everybody (including myself) anticipated. I am totally overloaded, among other things the NewTWikiOrgServer2008 setup takes a lot of time (we spent again 4 hours on Monday tuning the system). As stated elsewhere, until the new core dev model is established, the same process we have in place for feature enhancements can (and should) be used for non-feature decisions. As we have seen in the past we know it works!

-- PeterThoeny - 12 Jun 2008

Joachim, you must understand first that "Ego" is not always bad. Being proud of what you do is actually the fuel that make Open Source projects work, and is necessary. What is bad is not will to understand other people points of view. For my case I guess that I had no free time in the last months and so even if I could participate, would have serve to nothing as I would not have had no available workforce to offer. (so logically I should not be in the core team anymore, if we had a governance)

Michael, I tend to agree with you, IRC chats may not be as useful as confcalls to solve things, and the Synchronous constraint is not really needed. I guess sending an email to make everybody aware of the pending bugs may be better than the current irc chat.

On a side note, we are not alone, look at what is hapenning to the django community.

On Crawford... Please people, keep things in perspective. Crawford is putting a lot of work in TWiki, and more importantly he is still help TWiki whatever the flames he gets and the financial interests he finds in it. Compare this with the elephant in the room that nobody wants to talk about, the fact that on the opposite people like Rod will just abandon TWiki on a whim.

So stop bashing TWiki friends, people that will actually keep helping TWiki by code or work even in tough times (Crawford but also Peter, Kenneth, and all of you on this page). For the governance, what could be the next step? a (skype/teamspeak) confcall devoted to state on this issue?

-- ColasNahaboo - 12 Jun 2008

Peter, I do know and appreciate that you are doing non-sexy work. Admining servers, i.e. solaris, can be a pain in the a*. So I can clearly picture in what maze you are. That's not the point I wanted to make. Hey, how about doning more sexy work instead? (hint: how about improving usability in the TWiki web, docu-wise and admin-wise)

Joachim, keep kool. Here's another article saying X Server 1.4.1 Is Released, No Joke. Hehe this could easily be "TWiki-4.2.1 released, no joke" wink

Peter, here's another one on democracy versus individuals in a decision finding process, from Creating Passionate Users.


Here are some citations that are just spot on ... as so often on this blog:

The wisdom of crowds comes not from the consensus decision of the group, but from the aggregation of the ideas/thoughts/decisions of each individual in the group.

Paradoxically, the best way for a group to be smart is for each person in it to think and act as independently as possible.

So what is the conclusion to draw for TWikiGovernanceProposal1? Dunno, but don't put too much trust into a democratic, voting-based decision processes. We'd be better off to boost enthusiastic individuals and offer them more freedom to experiment. The current proposal process is somewhat counter productive in that respect, while it tries to keep software quality high. And these are the two key factors which are not in balance on the TWiki project currently: boost more research & development vs software quality. The more you force a process the less you get research, even less if the process is based on consensus. However, maybe it is already too late as we already alienated away people with lots of ideas. But I am very confident that other people will come back and dive into it. Let's heat up the water for them a bit.

-- MichaelDaum - 12 Jun 2008

About my social skills. At least I show up. Staying away is not an admirable social skill in my view.

Our release process is today based not only on the release meetings.

The release process when it comes to feature proposals is that people raise a proposal. Then either themselves or someone else commit to implement the proposal. It is now discussed on Codev. And if you look at the already processed proposals the big majority gets accepted by consensus. Intelligent consensus. Some proposals are accepted because noone voice anything against it. Many are decided after a few questions. And many are being improved by a good healthy discussion on Codev.

But some of them seem to get stuck. They end up with a concern raised and counter proposals that conflict with each other. Very few end up with a community split between a yes or no.

The main reason for bringing these to a release meeting is to get a more live human discussion how to bring it forward. Several proposals were discussed at the release meetings where the decision was to go back to Codev and a few days later I could declare a modified proposal accepted by consensus.

But the past 3-4 months this process has stopped. TWiki as a project is not a democracy in every respect. A handful of developers with a lot of insight of the code are being listened to much more than the rest of us. And it is difficult to make decisions that involves the deep inside of the core code without advice and approval from a person with a lot of domain knowledge in the area affected by a given proposal.

In real life we all both write documents and emails to each other. AND we meeting face to face in meetings.

The picture above of the two groups make no sense. In fact it is pretty stupid and probably taken out of a different context.

One of the most powerful tools in software development is peer reviews. Documents are distributed. People prepare and raise comments - often using a tool for it. And at the end a review meeting is held where the "must discuss" comments raised are discussed. Often such review is moderated. In most cases the issues are resolved with a decision. And sometimes an issue has to be taken "offline" by a couple of experts.

I see our release meeting as a final review of the proposals. One additional thing to note if you look at the history of release meetings.

  • Core veto has never been used
  • Very few proposals that we voted for had any votes against the proposal. The vote was more a round the table nodding.

Michael I do not know what work experience you have with working in groups. I have project managed multinational projects or significant sizes and a huge mix of cultures and skills. And I have learned that the best way to get things moving is to use all the means of communication we have available. Just to mention a few.

  • Documents on fileservers
  • Status webpages
  • Presentations
  • Personal private phone calls
  • Informal review meetings
  • Formal moderated review meetings
  • Desktop reviews via email
  • Private emails
  • Mailing lists
  • Travel by airplane to meet remote people face to face
  • Wikis

When you look at my approach to TWiki it is exactly that. Use all possible ways to collaborate. We have.

  • Mailing list
  • Private emails
  • TWiki - informal random Codev pages
  • TWiki - formal feature proposals and bug reports
  • Two summits per year to meet face to face
  • TWiki meetups - meet our customers face to face
  • Personal meetings when we have the chance.
  • IRC - informal chats during the day
  • IRC - formal biweekly marketing meeting for those interested in marketing
  • IRC - formal biweekly release meeting for those interested in getting next release out and having influence on what features future TWiki versions will have

We sit in different parts of the world. We are in different time zones. We cannot just go and meet face to face because it cost a lot of money and time.

There are a few things we can do better.

  • IRC sucks as a meeting forum. Best is face to face. Because we are not computers - we are humans. But 2nd best is meets on the phone in conference calls. I think we need to persue this more.
  • Call each other directly on the phone. International phone calls are so dirt cheap now. And we have Skype which is totally free.

I think I will try and arrange a next release meeting voice based.

But first there are two people that need to pick up the phone and talk things out. Do you need a conciliator in a 3 way call?

-- KennethLavrsen - 12 Jun 2008

A more visual description normally gets the message through more easily. Maybe others get the point.

-- MichaelDaum - 13 Jun 2008

I think the picture is trying to tell the same story as the most recent studies about group brainstorming.

People tend to say it is highly productive but it isn't.

" Contemporary research, however, suggests otherwise. Most current literature asserts that group brainstorming is half as effective as individual brainstorming.

But that hasn't stopped the practice. "

from: http://www.uta.edu/publications/utamagazine/winter_2007/stories.php?id=452

-- CarloSchulz - 13 Jun 2008

So what is it you are suggesting?

Remember that there was a time before the current release process. People raised proposals on Codev - and then they were ignorred.

The release process has nothing to do with brainstorming or democrature where a majority of ignorants overrule the experts. That is not at all the picture of the reality. Carlo: Your references starts with ""The formal brainstorming process is the exchange of ideas under conditions that encourage individuals to exchange as many ideas as possible without worrying about quality". Release meetings has nothing to do with brainstorming. It never had. Release meetings is a bunch of experts and people interested in TWiki that meet to resolve issues when there are mixed oppinions about specific proposals raised by developers.

As I already said. Most proposals are agreed without any voting. Most proposals are passing through with a few people interested in the topic commenting and maybe proposing improvements. It is a small fraction of the proposals that get stuck. And meeting to talk about a next step is a very wise thing to do.

What else do you guys propose?

What is is you want instead?

A strong man making all the decisions? We had that.

Anarchy? Strongest bully wins - rest shut up?

The release process is also a chance for customers (admins and users) to be heard. That is if you are interested in hearing them.

"If you don't have users, what's the point anyway?" well spoken by JoachimBlum. Wonderful what you said Joachim.

-- KennethLavrsen - 13 Jun 2008

Kenneth you don't get the point. My remark had nothing to do with the release process, it was just to explain the idea behind the image Micheal posted.

-- CarloSchulz - 14 Jun 2008

Sorry. I thought we were discussing the release process and not some image.

-- KennethLavrsen - 14 Jun 2008

The concerns raised in this topic are now addressed in IntroducingTWikiGovernance, TWikiGovernanceProposal1, and initially discussed in GeorgetownReleaseMeeting2008x07x07.

-- PeterThoeny - 08 Jul 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatlog GeorgetownReleaseMeeting2008x05x12.log r1 manage 36.9 K 2008-06-10 - 00:48 SvenDowideit  
JPEGjpg dumbgroups2.jpg r1 manage 39.4 K 2008-06-12 - 08:21 UnknownUser  
Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r32 - 2008-09-05 - 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.