 This is another talk that I had originally intended to be a boss, but when I found out it had been scheduled for the end of the week instead of the beginning of the week, and it was in a 300 person room, I started thinking about it more like a talk. And so we'll see how this goes, but why have our enough slides to maybe consume about half of the time, and then hopefully there'll be plenty of time for us to have some discussion. And just this morning I figured out how to use the wiki.debian.net stuff to create a wiki page for us to continue collecting thoughts about the things that I want to talk about today. So first of all, out of curiosity, how many of you have never heard me talk before? Wow! That's cool. I'm really sorry actually that more people didn't have a chance to be here last Saturday for the Debian Day, because while I don't know that that day worked out quite exactly the way we had all thought or expected it might, there's some interesting things talked about there, and I went and pulled one or two slides out of my slide deck from there to include here today as well. So this has got a little more stuff thrown into it than I had originally intended. But first of all, who am I if there are that many of you haven't heard me talk before? It's probably worth my spending just a second on this. I like to tell people that I made my first contribution to what we now think of as the free and open source software communities in about 1979. This is a piece of assembly language that I wrote when I was in high school for an interesting little microprocessor board you've never heard of. But it got published in a newsletter in Canada, and I got invited to go give a talk at a meeting in Canada, and my parents said, no, you're not going to Canada to give a talk. Got my first UNIX login when I was at Carnegie Mellon University in the early 80s. That was the era of early BSD stuff on the VAC systems. CMU was sort of interesting. If you started a project and got some funding, you'd buy VACs and run Berkeley on it, so there were a lot of them around the campus. It's sort of a long process, and those of you who did hear me give my talk at DEBCONF2 in Toronto or who have gone out and looked at the slides from that will know that Amateur Satellite Project that caused me to switch over from being a Berkeley UNIX kind of guy and discover Linux and the Debian Project in 1994 or early 1995. I've done a lot of different things in Debian over the years, and I have not been completely consistent about the amount of energy that I've put in Debian over that time period because in fact, I went off and spent a couple of years building, helping to build a large amateur satellite in the middle of all that time and became a darn near MIA maintainer for a while. But I've stayed very interested in lots of the things that people sort of take for granted about Debian today or things that I've either had some influence on or are the downstream derivatives of work I did at one point or another in the history of the project. I've been working for the Hewlett Packard Company or its spin-off Agilent Technology since 1986. Up until 2001, all of that work was being done in the old part of HP, the test and measurement business. And I didn't actually know much about the internals of or work for the computer part of the company until I was recruited in May of 2001 to go back from Agilent to HP and work on Linux and open source software full time. And after a couple of years of doing engineering work in a lab that's now part of HP's open source and Linux organization, I was invited to join Martin Fink's staff. He's the vice president in HP who's responsible for all of HP's Linux and open source activities around the world to serve as his chief technology officer. And that's what I've been doing for the last couple of years. So what's this talk all about? It's been my observation that it's really easy to complain about things that you don't like, but my personal impression is that it's much more rewarding instead of complaining about things to ponder ways of making them better and then to set about doing whatever it takes to make them happen. And to me, that's really sort of what the Debian project has been all about since the beginning. This project began because Ian Murdoch saw some things that he thought could be improved and he pondered the best ways to do those and set about trying to make them happen. And our project's been about that ever since. One of the things about being involved in a project like Debian at the sort of level of involvement that I think I have had for more than 10 years is that I've had a lot of time to ponder what's going on in this project and to think about some of the bigger issues. It's also interesting that when you choose to do things like run for the position of Debian project leader and you're as introspective a person as I am, it's hard not to spend a lot of time thinking about what is it that makes me excited about this? Why is it that I like being part of this project? What makes it work for me? What do I think the problems are? What would I do differently if I had the power to make things work differently? And so what I want to offer to you today are just a few of my musings, things that I've been thinking about, some of which I've been thinking about for a very long time, but which got their first sort of public airing outside of small conversations at the Debian mini-conference that was held in April this year in Canberra, Australia just before LinuxConf Australia. And how I ended up presenting them there is kind of a funny story. I was traveling with my family as tourists in Australia for the week or so before LCA and that happened to be the time that our DPL election ended this year. And Brandon found himself in the interesting position he now holds, which is an amazing sort of thing to find yourself all of a sudden responsible for. And so when I arrived in Canberra, they said, oh, by the way, Brandon is the new DPL, which I had sort of heard, but I hadn't really had a chance to think about very much. And he said, you're part of this project sked thing, right? So you wouldn't mind giving the opening talk at the conference and telling us what that's all about, right? And anyway, it was sort of interesting. So very quickly, I threw some thoughts together and I didn't see any point in opening an event without being provocative and thought-provoking. I really, really, really didn't intend to sort of do, Brandon got elected. Here's what Brandon thinks and here's why, you know, I think we might totally change the structure of the project and do something different. But that's kind of how it came out. What I'd really like for you to do is think of some of the things that I want to talk about today as serious food for thought. Things that we all contemplate that we ought to use as we think about what's working and not working well in the project today. This is not some perfect answer. And I certainly would hope that we would all work together in the spirit that this project has always used when things were going well to craft a future for ourselves. So there have been a couple of things that I've picked upon this week that I sort of want to throw in here before I get too far into this because they're all sort of part of the context of what I've been thinking about. And I have to thank a couple of folks for helping me with good articulations of this. I think the talk that was given the other day about the history and status of our new maintainer process got me thinking once again this week about this whole idea of community. You know, from a definitional standpoint, the dictionary says that a community is a body of people having common rights, privileges or interests or living in the same place under the same laws and regulations. And we all understand this. We participate in traditional communities. They might be the towns we live in or the schools we attended. At least in the United States it's amazing on fall weekends when football games are happening to see the strong sense of community that people have for the schools that they attended or the ones they hate because they beat them in football at some point or something like that. There are also churches, sports teams, volunteer organizations. I think everyone has a sort of personal idea of what a community means. But one of the things I don't think we think about very often is that the internet enabled this formation of a whole new class of communities that didn't really exist very much before with some interesting and notable exceptions. And that's communities where there are lots of people with common interests or values but who might be really broadly geographically distributed. Nat Friedman used an example in a talk that he gave publicly recently that I had to chuckle over because it made it clear that he and I have been reading the same books lately. If you haven't read it, the book The Professor and the Madman, which is a description of how the Oxford English Dictionary got started and an expose on some of the more interesting characters involved in helping that to happen, has some interesting information about what was perhaps the first of this class of project where lots of people with a common interest who were really geographically distributed figured out how to do something really great together. But I don't want a rat hole talking about that even though it's cool. When we bring this idea of community into the free and open source software development world, we think about it mostly in terms of this community development model. And it is a key attribute of Linux and many open source applications that they're developed and supported by the community. What does that mean? Well, fundamentally it means that there's no one company that's in charge of things and there are a range of contributors with different interests and abilities and motivations who come together to make this great work happen. And the reason this is so cool is that it allows this whole freedom of choice thing to work effectively. I pulled this out of a slide deck that I use all the time when I'm talking to HP customers to try and explain how it is that we in HP try to interact with the software development community around Linux and open source and why it is that we behave the way we do. You know, we think of this as all as being hugely disruptive and when I say disruptive, I mean that there's not a single business that I'm aware of inside HP that doesn't have the word Linux somewhere in their business plans for the next year. It's become pervasive. Everybody has to care about it. It doesn't matter whether it's the printer guys trying to figure out what to do about device drivers or the notebook guys trying to figure out how to make some Linux support available for their systems or the server guys trying to figure out how Wall Street can be happy running huge processes and databases on open source platforms. It's all over the place. We ship a couple hundred products today that have Linux embedded in them that people don't even know about because they're consumer products or other appliance things and it's just an embedded part of the product. It's all over the place. And so to do this, we try to participate as part of the community consistent with the community's values to develop, you know, enterprise capabilities and other things that are of value to HP. So I spent a lot of time thinking about this whole idea of community and when the talk about the new maintainer process came up the other day, one of the ideas that sort of popped into my head in the middle of all of that from the things that they said that I think is worth highlighting is this notion that we could think of the NM process as a citizenship process rather than as a filter. I know that at least for in my own thinking in the past, this whole idea of what in him was supposed to be about was a mixture of an attempt at socialization. And how do you formalize the mechanisms of making sure that the people who are going to participate have actually read the foundation documents that we all sort of agree are our expression of our shared set of values in the project. But they've also grown to behave like a filter hazing process and whatever your favorite definition is, you know, in effect, we've made it hard so that only people who really care will try to fight their way through it in some sense. I wonder sometimes if it's really more important to test for the kind of depth we seem sometimes to test for in a single area, whether we should be more focused on ensuring that new members of our community have a broad foundation of knowledge across all of the areas of work in Debian. When I think about what citizenship means in real world communities and countries and so forth, there's an expectation actually that people who apply for citizenship will be willing to learn as much or more about foundational things like how the judicial system works and how representatives get elected and all of those sorts of things than most of us who were born in that country will remember from our primary school educations. And this is all about a breadth thing, making sure that you have enough context to be able to appreciate all of the other things that are going on in this community so that you can behave as a good citizen of the community and you understand what that means. And this causes me to think about something that this morning I sort of in my head wrote down is gating versus rating. What I mean by this is gating is sort of the process of do you open the gate for this person or not. It's the filter. It's do you decide to let someone in or keep them out. Rating on the other hand is how do you discover who's actually behaving well, what's working, what's not working. Is there some way that we can sort of measure the behavior and performance of people as citizens of our community and use that as some kind of in the end some kind of a gating function on their access to things. I know that in conversations we've had at various times that Brandon has expressed concern about this notion of having multiple tiers of developers and in effect building sort of different levels of citizenship in our community. But I keep scratching my head about what the right approach to it is. We currently have a model that sort of goes deep and narrow and I keep wondering if there isn't some way we can go more broad and end up with something that would actually work better for us in the future. Brandon, why don't you speak and I'll repeat. It's faster. Beat Beat Beat Dale can tell I'm going to run long. I was having a conversation with Hannah Wallach the other day and I just floated an idea idea to her I can't speak. I can't speak for her and say what she thinks of it. But in the wake of her presentation on NM, it occurred to me that the current NM process is designed to try to prevent people from ever screwing up really. So we test them on all kinds of things and give them all kinds of questions designed to serve mostly as preventative measures and ensure that they have clues. And the thing that occurred to me was, well, wouldn't it be interesting and I think there's already some stuff on Alioth that kind of begins to point this direction. Wouldn't it be interesting if we could just screen people to the level that we want to determine citizenship, the gating part, and then let people rate themselves regarding their various... I'm surrounded by German. What's going on here? I don't think you're coming through the PA now. At any rate, if we gated people enough to let them in to let them vote in our elections, maybe we could let them rate themselves regarding their things like their technical expertise. Like, do they want a Debian.org email address? Is one important criterion? Some developers don't and the fact that some people have those addresses has actually caused problems when those addresses are used in certain contexts, as we well know, at least those of us who've read any of the lists for the past year. Another important issue is package uploading. Some people don't necessarily want that privilege and some people shouldn't have it. And if we had just a few areas like this, I imagine we should, again, use the Enrico principle of just having a relatively few, then what do you gain out of this? Well, you get not only the ability to switch off access to various things on a voluntary basis, but when someone says they do want this responsibility, they're making an affirmative statement, I want this power, I think I can handle it. So if they do mess it up, you can come to them, you know, with a little bit more of a disciplinary thing and they can't, basically they can't claim ignorance because they affirmatively stated that this is a responsibility they thought they could handle. Okay, because what you said changes the NM water citizenship process. I think that was all the things that were happening. When other members, when I got to my NM, that was just one and a half year ago, a lot of things were about just, well, what do you know? And a lot of things have now been changed to please behave as a good citizen like. Please show me how would a sponsored upload from a look like if you do it for us and a similar thing. So I think we are already on the right track there, but of course there are some more steps to do. Yeah, and of course, is this working now? Yes. Dudes, thanks. Batteries. Batteries, it's always batteries. Yeah, my little travel alarm has the same problem. It seems to work fine until the battery runs out and then I miss flights. Actually, I've never missed a flight, but I've not missed some because they were multiple hours late in any case. Now that I've said that, I'm in trouble. And again, what I'm hoping to accomplish today is to give people things to think about. These are some things that I've heard this week, particularly this notion of thinking about this as a citizenship process, which is sort of the next step down the conceptual chain from a socialization process, which I always thought was part of what we were trying to accomplish, at least with the mentoring and sponsorship pieces of all of these things that go on with new maintainers. But obviously there are lots of people who have lots of thoughts, and this is something we ought to follow up on. So another idea that is the one that actually got all the attention down in Australia in April was that I keep wondering if the model of governance or how we structure and operate the project that's currently coded in the WN Constitution still represents the best set of choices for a project today. And when you think about this, out of curiosity, how many of you have read the WN Constitution like in the last six months? Wow, really? Are you all in the NMQ or something? I didn't expect there to be that many hands. So how many of you actually remember what it says about the responsibilities and the rights and powers of the DPL and the technical committee? Yeah, it gets a little fuzzy, doesn't it? Well, what I think is interesting is there's this whole set of sort of misimpressions that are floating around out there that somehow the Constitution says one thing and I keep trying to quote it to people from time to time and get strange reactions. One of the questions we could reasonably ask is are the DPL and the technical committee taking full advantage of the powers that are part of the current definitions of their roles in the Constitution? And regardless of what you think the answer is, is that good or bad? And another thing you could ask is have the conditions in which our project is operating changed enough since the time that this was written in 98 originally to want a different approach? And some of the reasons I get to asking these questions are that it's been my observation that the whole process of electing a DPL is a strange event for WN. What do I mean by that? Well, in WN we really value working together but the whole process of electing an individual is rewarding people who are willing to compete with each other for an ill-defined, well, maybe not ill-defined but certainly ill-defined in practice role in our project. There's also this notion that as Debian keeps getting bigger and bigger, I think Brandon's expressed a couple times this week that he has great concern that maybe it's just too complex for one person to directly wrap their brain around and that's what's led us to some interesting experiments and sort of tiered delegation, which is sort of what this guide thinks about. There are limits. There are constraints on the role of the DPL that are defined by our constitution, all of which were well-intended, maybe not all of which have really worked out well in practice. It's unclear to me. And one of the things that just drives me crazy, though I completely understand why we coded it that way at the time, is that the process of electing DPL takes nine weeks every year. Now, should it really consume nine weeks of our lives? Well, it probably really doesn't. We don't all just sort of stop doing everything else during this process. But for anybody who's contemplating participating in the process, you really have to think, and I speak as someone who's like been through it three times with a, you know, 330 batting average, 333 I get, well, having been through this, you really sort of have to contemplate putting lots of other things in your life at a lower priority level for, you know, more than two months so that you can be, you know, visible, participatory and responsive as questions come up and people want to know what you think about this and everybody wants to tell you what they think so that you'll factor that into your thought processes and so forth. I guess in theory, you know, it should only be that intense during the quote-unquote campaigning period, which is the middle three weeks, but my experience is it doesn't really quite work that way. So overall, this whole electing a single individual thing just seems strange to me. And I have the sense that our technical committee, as it's currently defined and or perhaps better stated as it's currently behaving, just isn't very satisfying. There's this perception that the technical committee is inactive and that because it's inactive and doesn't do anything that there's no reason to try and use it. And of course, that's a vicious circle because if you don't try to invoke the technical committee to get help with things, then they're not active and there's, well, you see what I'm saying. It's very clear that the composition of the committee needs a periodic review and refresh. There is a sort of committee private mailing list and one of the things that I'll let leak at sort of the conceptual level is that there is a discussion ongoing right now about the possibility of adding some new people to the committee and a little bit of discussion about what you do about what the process ought to be for getting folks that have really gone inactive and just sort of aren't around anymore to sort of de-participate from the committee. And then there's this interesting phenomenon where many people seem to wish the committee would take a more active role in defining Debian's technical direction. And I think this comes from the fact that there are all of these other projects around us that have technical advisory boards or I look at how the GNOME and Apache foundations work, there really are in some sense groups of people who are put in a place for one reason or another where they have the ability to review different thoughts about the direction that the project might follow and they build that sort of sense of technical vision for the next period of time that everybody then goes and tries to make their contributions fit in with. I think the Debian project sort of has an interesting history of floating in and out of having a vision and having that vision actually be sort of useful and relevant as a guiding force for what we do. On one level it's gratifying to me that this notion of Debian as a universe of packages from which we would draw interesting subsets to do different useful things. The fact that that's still around is gratifying since I spent a lot of time trying to cleanly articulate that a few years ago. But the fact that somehow that hasn't... We're struggling right now with how that ought to evolve and what we ought to be thinking are our directions next. And people seem to wonder if there isn't somebody that ought to be sort of helping to focus that energy and they look at the technical committee's definition and if you look in the Constitution it certainly says that this is something the technical committee could do but the current composition of the committee actually behaves kind of makes that not happen somehow. There's another thing that I spent a lot of time thinking about. I'm also on the board of SPI which is the umbrella organization that provides a legal and financial existence for the Debian project. And as everybody here I hope is aware, SPI's kind of had a rough history. There have been things that really didn't work well for a while. And at Debcon 3 in Oslo a couple of years ago there was a session that I guess Mako sort of organized and various people participated in talking about SPI and some of the problems it was facing at the time. And I injected somewhere in that process some questions about whether it might make sense for us to look at something more like the foundation model that Kanom and Apache and so forth were using as a way to either fix SPI or to build a replacement for it that would actually work better for Debian. I came to realize after a while that that was fixing the wrong problem. That SPI had issues and they needed to be resolved but that SPI doesn't have the same relationship with Debian that something like the Kanom Foundation has with Kanom or the Apache Foundation has with Apache. SPI exists to provide a set of services to projects like Debian and the other member projects but it doesn't exist to provide a sense of vision or direction to those projects. In fact, quite the contrary. I think the member projects of SPI would be pretty disturbed if this SPI thing from up in the vaporist beyond all of a sudden came down and started trying to assert some sense of direction or control over their behavior. And the good news is since that time I think SPI has for the most part fixed itself. I certainly am reasonably satisfied with the way things have been going. There's a lot more work to be done and I would certainly encourage more Demian developers to get involved but I still think there's some ideas that we might take from that process though like the notion of elected boards. So then there's this project scud thing and you've heard about this in different directions from different folks. It first sort of came towards me from Andreas who was contemplating the possibility of running for DPL in this past election and was very interested in this whole notion of how teams and their effects and how they might improve the project and approached me about participating in this DPL team concept. And to be honest I had to spend some time thinking about it. I didn't immediately say oh yes it's a brilliant idea I'd love to participate. But the more I thought about it the more I started to think that this was an experiment that was being proposed that would attempt to address some of the things I'd been concerned about. When I thought about it I realized that in my own history in Debian that I had provided some kind of council or advice or had some kind of a stronger than average working relationship with every DPL going back to Ian Murdock and certainly including Bruce and everyone who's come since. And so there really wasn't anything unnatural or inappropriate about my agreeing to be part of a board of council or advice for a DPL. And when Brandon became involved in the team and we ended up with the composition of people that we have today it really seemed like we were getting a reasonable mix of representation of different viewpoints and different concerns in the project and I was fairly excited about it by the time the election happened. I had actually intended during the DPL comment period during the DPL campaigning period in the middle to post my thoughts about all of this and why I had agreed to participate in it. And finally there was a very serious medical issue that cropped up in my family involved in my father during that interval and I just disappeared for about three weeks to go trying to do the right thing with the family. And then once the campaigning period was over I didn't think it was appropriate to go spouting off too much until after the election was over. But some of the concerns that were raised about this whole approach are that the relationship between the DPL and this DPL team really isn't very clear. It's not something that exists in our constitution. The team was mostly self selected and at least one group of Debian project participants were vocal in different ways about feeling excluded and that just made the whole thing be not as sweet as it might have been. And at the end of the day it's an experiment. I hope it turns out to be a successful experiment but it's a hack. And I really think we could do a better job. So this sort of led me eventually to wondering if all of these things in my mind at least weren't leading towards the notion that it was time to think about something as drastic as amending Debian's constitution. And when I say drastic it's because those of you who know me know that the whole GR process frankly kind of scares the pants off me. I was not very encouraging to people who proposed GRs during the time that I was DPL because I almost always thought there was some better way to solve the problem. And in fact I think most of the problems that we faced in that time were faced better actively and with less angst and strife in the project by other means. But frankly there's no way to do anything about the contents of the constitution without an election or a vote involving all of the registered developers in the project. So I have gradually kind of built myself up to the notion that maybe I could tolerate doing this. And the idea that I have which is really the idea I wanted to inject here to get everybody thinking about and discussing and contemplating the pros and cons of so that we could have a productive conversation about whether it's something we want to pursue and if so how is this notion that we could change the structure of governance in the Debian project to do away with the role of the DPL and the technical committee and replace both of them with what amounts to an elected leadership board. The idea that I had with this is that the roles that are currently played and sort of the powers that are currently assigned to the DPL and the technical committee would in this model be things that were appointed or delegated directly by that board. It's my experience that most successful non-profit organizations in the U.S. that I've been involved in sort of operate this way. They are board of directors and then the board votes amongst themselves to determine who the officers of the corporation will be and sometimes they go beyond the set of elected people if there is someone who is a really ideal person to be a treasurer or something like that. One of the things that this could do is it could cause the candidates that run for these positions to be motivated to campaign on how well they can work in a team kind of an environment instead of having them focus on individual differentiation which is the thing that I think is so strange about our current DPL election process. Maybe that's something that we could figure out how to change without having to do this kind of a structural thing but it's certainly one of the things that's led me to thinking this way. I personally think that more qualified people might be likely to run for a position on a board like this than would be willing to run for an individual post. It's certainly true for me, myself personally that the idea of running for DPL again is frankly not very attractive. Not only do I have like a 330 batting average which I realize doesn't think's a big deal since I think he's proved that that's not a permanent impediment to success but frankly the whole sort of process and the sense of responsibility unique personal responsibility that comes out of it and so forth are not things that I particularly relish at this time however I might be willing to run for a board slot and in talking to other folks there are a number of people who would love to have a more significant role in all of the things that are going on in this kind of a way but aren't particularly interested in running to be DPL and I think that it might be easier for such an elected board if they believed it really was part of their mandate to take a more proactive role in defining and articulating our vision for the project and particular technology vision for the project than it is for the current technical committee but again that's something we could also choose to address by reinvigorating our current technical committee or making it abundantly clear to them that it's something that we'd like them to work on so at this point you've heard the things I've been thinking about and musing about and scratching my head about I'm not proposing these as you know the ultimate solution to life, the universe and everything and I'm certainly not trying to suggest that I'm disappointed with or frustrated with Brandon or any of those other misinterpretations that popped out of the session in Australia but these are all the things I've been thinking about I'll point out that all of my talks including this slide set eventually show up on my website and this one's actually there right now and this morning I went and figured out wiki.wm.net and created a governance page so that we'll have a place to collect thoughts and ideas about how to evolve our project's governance as we go forward so that questions yeah Andy so thank you very much Peter I think you as one of the most major concerns that a lot of people have about the team's cut so that includes myself when I first did about the team's cut it was just coming like something well it just was there I can very well Peter I can very well remember sitting in Seins flat in Vancouver having Elmonex who said well what's that just come about up and we noticed that two people who are in the team's cut invited us to go to Vancouver and we didn't know about that so that's really one of the most major issues why I voted personally against the people in the team's cut but of course I think that's a team idea was a very good idea so I was well really I said as a team was good but not that team please and yeah frankly speaking that was the cause well here's the target well and I really think we should go that way because we need a team I think it is too much for a single person to go on and what are your thoughts about how we should perhaps there's such a chance about the technical committee why I think they can't take a more active role because the current ways are constructed they just well they just add themselves so it's a bit difficult because they don't have a really clear mandate whereas if someone says okay I have a good idea and we vote them into the DPL team or the board then it's very clear that the developer has to go on that way so I think that's what you need some elected board to then advisory board in the stronger sense that for example the KDA foundation has yeah Brandon then again one of the concerns that we've seen crop up periodically over the years is to take a kind of a strong position here you know we can refactor the project leadership as much as we like but it's not going to do a lot of good if not everybody feels like they are part of the governed and there are areas in the Debian project that are vested with authority that predate the constitution and I've spoken with some of these people and they've made postings over the years and they're not comfortable exactly with the idea of the possibility of a madman DPL for example I'm not sure that have we already had that but no of course not and I'm not sure that these same historical roles would be any more comfortable with a different thing I mean it's kind of the idea so there are a couple of fundamental we've been doing this for 10 years now you can change the constitution you can change, you can put a board in there you can put a person in there do what you want man but there's none and there's no benefit to them in recognizing so there are a couple of fundamental things that come to mind when we start talking about this one is that I think organizational structure good organizational structure very rarely does anything to sort of guarantee success but if you get the wrong structure it really can impede progress and success that's sort of one idea and the other one is that I personally have ended up in a situation where I started to think I was indispensable and believe me it's happened at various times in my history when something finally sort of forced me to realize that that wasn't true things in general sort of picked up pace and moved better as a result and so there is this sort of trade off I think between motivating participation and how you actually sort of keep from getting stuck in a rut or something so I don't know that I have any more brilliant thoughts than that I know Ian do you have something else I just had a brief anecdote and I'll hand it over to Ian actually I did an interview with a French sociologist yesterday and I shared with them an anecdote that I've shared on other occasions which is one of the reasons I got as involved in Debian as I did which was adopting the X for 86 packages shortly after joining was because I she's picking on you okay was because Bruce was making his final resignation at that point I didn't have yeah I know the final final resignation the one with the famous message of private I believe but at that time I didn't know about his previous ones and I very much identified Debian the project with the identity of Bruce parents leader in part because he was such a big figure that was an easy thing to perceive in early 1998 when somebody didn't have access to the dash private archives or had got it but didn't have time to go read them all nowadays it would be an even bigger hurdle so now that wasn't true and I learned that you know Debian wasn't going to crumble just because Bruce walked away and that motivated me to do a good thing I think there have been differences of opinion over how I maintain X for 86 over the years but at least for the most part I think it caused me to get more involved to care more about Debian and that's what got me started down this road so that that sense of indispensability kind of cuts both ways so I think I broadly disagree with you there's one the big thrust of I mean there's two sort of things you seem to be saying one is that you're sort of unhappy with the way the DPL exists and is elected and so forth possibly there's some argument for now that the project is much larger having more people there more positions elected but I very strongly disagree with your second point as I see it about particularly about technical vision or whatever you want to call it I wrote the constitution as I did specifically to avoid a situation of over leadership where the leaders have power beyond influence that is where they're able to make decisions and somehow tell people what to work on and block things that they don't like and the this is why the technical committee is limited to answering questions that people ask of it or maybe issuing an opinion or two and this is why the DPL's power is actually limited as it is and I think that all of those reasons still apply and I think it's a mistake for Debian to have some board that tells everybody what the next vision is I think it'd be fine for the DPL to do that or some new DPL team to do that that's not a problem but to give them the kind of formal power to tell people what to work on to officially set the direction that's wrong and what we should be doing is we should be letting people work on what they think is important and that's why people get involved with Debian to do what they think is important and it's their vision that counts and if you can inspire them well and good but you shouldn't need to tell them what to do so it sounds to me like the only piece of this that you might want redacted as the notion that somehow the technical committee is what gets changed replaced so that you would in fact retain a separation between the sort of leadership visionary component of what's happening and the ultimate authority for technical problem resolution Yes, absolutely in particular I'm strongly opposed to the idea that people with the power to kind of tell people what's in a technical sense and say specifically you do it like this and you should be directly elected Okay, alright, I understand that Yeah, alright and in fact that makes reasonable sense to me and we need to that's why these are in my case thoughts So who's next? Franz Yeah, there he is, okay Any ideas of the composition of the board should certain areas of the project be represented in it like maybe somebody from the release team maybe somebody from FTP Masters what else should be present in a board So for those who missed the first couple of words before the audio on that and I came up the question is what do I think about the composition of this board should specific groups in the project be represented I'm actually not in favor of that because I really have this strong sense that leadership is sort of a people thing not a positional thing I think it's expressed about the SCUD team and the fact that it maybe wasn't adequately representative of the developers I think was mostly tied to the fact that the team was somewhat self-selecting or at least sort of guided self-selection based on who the initiators of the idea thought they wanted to invite to participate and the fact that there was no ability for anyone outside of that team to either volunteer to participate or at least add at least one person Mako beyond the original composition of the team so no my thought is that I don't want a specific sort of we need a release master we need one of these we need one of those I guess my hope is that we would naturally end up with at least some of the more important areas of the project being represented because it's been my observation I think very much in alignment involved the most and you know would want to have some say an input in this process but I suppose it could always work out horribly poorly but my general sense is that I wouldn't want it to be specifically composed of representatives from different groups yeah the condorsate method is is really I mean that's one of the brilliant pieces of our constitution thank you very much again is the way we actually do the election part and how it allows the you know varying relationships between people's opinions to all get adequately counted under us yeah I want to reply to Ian who seems to first of all he seems to miss that we have a leadership problem general leadership problem in Davion and that we that is one of our key problems that we hardly have any leadership at all and those who do in the project partly do that without really knowing and reflecting upon it but still do it we have examples of leadership that does work but the leadership that for example the Davion project leader has hardly any power to lead at all so even though you succeeded in forming the constitution in that way we now ended up with the other opposite that we can't really have a leader in that sense so I think that in this way you polarized the thing it's a gradual thing that we need more leadership we don't want a dictator but we want more leadership than we have now and then about the workload of the DPL I think you underestimated that extremely I've been following TBM when he tried to keep up with stuff and it's he was really busy Brandon is also busy and he it's a good thing that well to be fair I think we have to remind ourselves that the DPL's powers in the constitution do include a very broad power of delegation that all of us who have served in the role could have been more effective about using the evidence that none of us really have been all that effective in using it is part of what gets me scratching my head about whether there isn't some different way to get a force multiplier at that level I gather we're running out of time okay so Brandon there's a buff DPL team buff or something scheduled this evening when is it figures or so at 1900 up at SMECI okay in the aquarium up at the hack lab at 7 p.m. tonight and I'm sure that I'll be there and some of the other folks are so if you want to continue the conversation show up there let's talk about this on Debbie and Dash project which seems like the obvious mailing list and as I said I've created a wiki, yep thank you very much