Debian Project Leader Debate, 2005

Debate Transcript

Introduction

Helen:: we're just giving Jonathan a couple of minutes to join us, incase he is delayed by something
Martin:: martin_krafft starts a drum roll
Helen:: ok! :) Hi everyone and welcome to the 2005 Debian Project Leader IRC debate.
I am Helen Faulkner, and will be chairing the debate with madduck (Martin Krafft). The candidates in this election are MatthewGarrett, AndreasSchuldei, AngusLees, AnthonyTowns, JonathanWalther and BrandenRobinson. we are missing JonathanWalther at this point, hopefully he will join us really soon...
The debate format has been described in https://lists.debian.org/debian-vote/2005/03/msg00507.html In the first half of the debate, I will be asking time-limited questions of all of the candidates. They will be pasting their replies into #debian-dpl-replies, which is not open to the public, though the logs will be made available later. martin_krafft will be collating the replies and pasting them in here.

Debate Part 1 - Question and Answers

Release Cycle Strategy

Helen:: question 1 has a time limit of 5 minutes:
A constantly returning topic is the release cycle and strategy,and -- arguably -- the current cycle is suboptimal. Assuming that you agree, please state what you consider to be a good (or the optimal) release strategy, and briefly say why. How do you see the position of the DPL with respect to the release strategy? If you were elected, what might be your next steps in leading Debian towards the cycle you envision? If you disagree with the above and think that the release cycle and strategy is good enough, please explain your position.
BrandenRobinson:: I think the primary responsibility of the DPL with respect to release management is to make sure the release managers have the support and resources they need. The recent proposal which I've decided to call the "Vancouver Prospectus" has done a good job of getting the ball rolling, when it comes to exposing the developers at large to the exigencies of release management. There's a lot more to it than fixing RC bugs, as critical as that is. As I said in my recent message to -vote, this is a beginning, not the end of the release management process. The current RM team certainly has my full trust and respect. As DPL, I pledge to work with them to the best of my ability to see that their needs are met. Sometimes, that includes deflecting a flame or two, of course -- though they're amply equipped in their own regard on that front. :)
AnthonyTowns:: The release strategy is primarily the release manager's responsibility. I think the key focus for the DPL is on supporting their role, andensuring they have the resources to act appropriately, such as byorganising meetings like AndreasSchuldei and Steve did in Vancouver, and be making sure that other teams are aware of what the release team needs, and vice-versa. There's a lot of benefit to be had tothe release team from simply ensuring other teams -- such as the GNOME/KDE teams or the d-i team -- are functioning effectively. I think the ideal release strategy would result in regular releases, on either a six, nine, twelve, or eighteen month basis; ideally predictable to the day. I think the release team's proposal for sarge and etch is good, and working out the kinks in it on the mailing lists is the best approach.
MatthewGarrett:: I believe that Debian should release faster, but beyond that I believe the details should basically be left up to the release team. The current proposals are somewhat controversial, and I'll happily admit that I'm not a big fan of the idea of reducing our support of other architectures. However, the release team are the people doing the work. Now that they've provided more information about the problems they face, there's an opportunity to try to find other ways of tackling the problems. The release team are the people responsible for actually doing the work - if nobody else can come up with an acceptable plan, then we should support them in their choices.
AngusLees:: The DPL should represent the projects views on the release cycle, and that means the views of the release team. Being DPL should give little weight over the average developer. Personally I think reducing the number of archs will be a necessary part of this. Given the existence of testing, I think the optimum release cycle for stable
JonathanWalther:: I believe OpenBSD has developed the optimal release strategy. However I believe that the release team, at their meeting in Vancouver, came up with a very welcome step forward, which will benefit Debian greatly.
AndreasSchuldei:: The DPLs job is to find the right people to manage the release. I think the present team is excellently qualified and has worked on the issues involved for some time already. My job as DPL would try to help them sort out problems outside their power. It would be their job to find the best release strategy.

New Maintainer Process

Helen:: Question 2 has a time limit of 4 minutes:
The New Maintainer queue has recently been "revived" thanks (in part) to additional manpower. Where do you see the strengths of the current approach to new maintainers, and which weaknesses can you identify? In what ways does the current NM process ensure the necessary skills of a prospective developer, and where does it fall short? What might you do after your election to further improve the situation?
JonathanWalther:: It has been 8 years since I went through the New Maintainer process. I haven't looked at it since then. Since we keep bringing new developers on board, it must be working well. If anyone knows of any problems with the New Maintainer queue, they are welcome to bring them up to me before, after, and during the election. Vote Jonathan Walther!
AndreasSchuldei:: The new maintainer process helps people entering the project to reach a good skill level on technical terms today. It still has probems with the socal skills. somehow we filter for endurability and patient, not for the ability to cooperate.It might help to add a SocialSkills part to the process and communicate how the new maintainer should try to behave.
MatthewGarrett:: I haven't had any particular reason to complain about the skills of any of the recent new maintainers, so I'm happy enough with the amount of testing that we're performing. Again, I don't really see it as the DPL's job to interfere with the working of a system unless there's obviously something wrong, and as far as I can tell the majority (if not all) of the people working on NM are doing an excellent job of it.
BrandenRobinson:: The NM process is strong in that it probably weeds out those who are only very casually interested. The downside is that it is so rigorous that it might scare off, or drain, people who could otherwise contribute valuably. Some of this year's DPL candidates (including aj and myself) came in under the old system, and I don't think anyone can deny that we've contributed a lot to the project. A good start, as DPL, would be to simply talk to the NM team and find out what gets complained about by the actual applicants. Also, there's a legendarily difficult dynamic loader question that's in T&S that might, perhaps, be overkill.
AnthonyTowns:: I've posted about NM on -vote; but to summarise. I think there are a few flaws remaining in NM; most notably that it takes a long time to go through. I was accepted into Debian within a week or so of applying, and only to maintain "distributed-net-pproxy", in non-free. Now, people routinely have to wait months before they can get in, which is far from ideal. I'd like to see NM focus more on a mentoring role; so that the "tasks and skills" section at least, and someof the procedures/policies section to mostly consists of working on real packages with real maintainers, rather than often filling in questionnaires, or working on new packages that aren't necessarily very useful. There are some more details in my post ot -vote, and I think the example of the -women mentoring project is worth following, but more details will need to be worked out over time as well.
AngusLees:: The new maintainer process is to weed out people who are unsuitable (either technically or because they're just downright unhelpful). My (uneducated) understanding is that few people are actually *actively* turned away by this process, and certainly Debian has little in place to deal with such people once they make it into the project So this probably shows that almost all people in NM are appropriate and we should optmiise the process a little on that assumption. In particular, I'm not at all confident that existing DDs would survive what we ask of new DDs now, which says a lot. Perhaps forcing *all* DDs to "reevaluate" regularly might force us all to pay more attention to the suitability of NM - as well as giving us a way to weed out MIA or maintainers that no longer reach our increasing demands.

Size of Debian

Helen:: Question 3 has a time limit of 5 minutes:
It has often been claimed that Debian is growing too large. What positive and what negative influences does Debian's current size have on the project? Depending on where you see Debian in the future, what steps would you take as DPL to shrink or grow the project, or to help it maintain its current extents?
AnthonyTowns:: Debian's great as a large project; the more architectures and packages and developers and users we can support the better. Each of those have problems though; lots of architectures are a hot topic right now; but the others cause problems too: lots of packages make it hard for users to know what to install, make it hard to track bugs, and make it hard to provide services (like the buildds or the archive or mirrors or lintian.debian.org) that work on all of them. Lots of developers make it hard to reach consensus on issues, and understand what everyone else in the project is doing. And lots of users mean that you're never allowed to make mistakes. :) I think Debian's about solving those problems as well as possible, and making an OS that works as effectively as possible for everyone.
MatthewGarrett:: It's not clear whether the question refers to the size of the archive or the number of people involved. If the former, I think that's up to the release team - if they believe we can release with an archive this size, then we should do so. If they don't, then we'll need to start thinking about approaches to reduce the size. The wide range of software we offer is obviously something our users like, and it would be good to be able to continue supporting that. If it's in terms of the number of people involved, then the obvious issue is that it's harder to keep a strong sense of a single community. I don't think that Debian growing in size is an intrinsic problem, but we need to be able to communicate more clearly within the project. With a small set of developers, information can be trusted to pass back and forth. With a thousand people involved, we need to be more rigerous in terms of making sure that people are told everything that they need to know.
AngusLees:: Beyond its free software stance, Debian's size is probably its most significant asset. Because the number of developers is (pretty much) allowed to scale with the amount of free software packaged, Debian is able to give each package a much larger amount of attention than any other distro. This is evident in the complexity (and usefulness) of our postinsts compared to (say) the average redhat ".tar.gz with deps" package. I think the project is growing at a reasonable rate currently, and all we (and the DPL) really need to do is watch out for bottlenecks that aren't scaling with the number of members. One such point was DAM, which is now being addressed - perhaps the security team might be next (I have no idea without talking with people involved in various areas).
AndreasSchuldei:: Groups that dont grow stagnate. But Debian can grow a lot bigger if it manages to handle the process smoothly. It has reached several chokepoints now, limiting its growth severly. The SmallTeams approach i presented in my platform is a unique and proven way of letting social groups grow larger without losing their charater or vision. With its help there would be a smooth entry point for developers and users to help along on most levels.
JonathanWalther:: Many hands make for light work. The more the merrier! As DPL I will let things develop organically, as they have so far. When we reach the natural limits to our growth, we will stop growing without any need for DPL intervention.
BrandenRobinson:: The large size of Debian, in terms of our developer population, our userbase, and the size of our archive (thanks to both package coverage and architecture support) is both a blessing and a curse. Large size makes us appealing to a broad audience, and often an official Debian package of a FLOSS project you've heard of is just an apt-get away. Still, the large size means we've accumulated a lot of cruft. I think Martin Michlmayr has done a great job with MIA, but we probably need more people doing it, if we can find the volunteers. Likewise, we might want to more strongly consider an MIA review process for packages themselves. Some packages in sarge haven't been revved since woody -- they should be looked at, at the very least. Managing growth is a major challenge for all organizations -- many businesses fail because they can't manage this. The DPL's primary role in many respects is to manage growth. IMO the best way to do this is keep one's ears open, and remember the Social Contract: We Won't Hide Problems.

Debian and SPI

Helen:: Question 4 has a time limit of 5 minutes:
SPI is Debian's legal chaperone and holder of all assets. It was instituted to allow Debian to concentrate on the Debian system without having to worry too much about administrative issues. How has the relation between SPI and Debian changed since SPI was founded? What is Debian's role in SPI, and what would you like it to be? How could Debian make better use of the SPI?
JonathanWalther:: As DPL I would immediately canvass the developer base for recommendations for a good bookkeeper, and hire her on a part time basis to handle all of Debians accounts. By extension, this would include SPI's accounts. Last year Debian last $18,000 dollars due to lack of proper infrastructure for handling donations. This doesn't need to happen. If the SPI board is agreeable, it won't happen. The cost of a parttime bookkeeper is only $6,000 a year. Considering the amount at stake, ($18,000), that is well worth it.
BrandenRobinson:: In my view, the relationship between Debian and SPI has not changed that much over the years, and that's not a good thing. SPI appears to be viewed by many Debian developers as a black box, or as someone else's problem. The truth is that SPI is a wholly volunteer-run organization just as Debian is. SPI, however, has vastly less manpower. I'd like to see Debian developers much more involved in SPI, to exercise their rights as contributing members, and help SPI live up to the noble goals upon which it was founded. We can always use more eyes and more hands at SPI. I feel certain I know that better than anyone else running this year. :)
AnthonyTowns:: SPI was founded as Debian's legal chaperone, with some in the end trivial side projects like OpenHardware. It's had a whole range of problems over the years, which now seem to be being sorted out. Currently, SPI holds copyrights and trademarks on behalf of the Debian project, and a large proportion of funds, and is increasingly doing the same for other projects. Other organisations in countries outside the US are doing likewise. I think continuing that trend -- ie, diversity at both ends, and increasing effectiveness, is ideal.
MatthewGarrett:: In an ideal world, Debian would take more interest in SPI. However, it's clear that there's no great desire from the developers to do so, and I don't see any especially good reason to motivate them - what SPI does for Debian is fundamentally not that interesting. However, it's important to ensure that SPI continues to take good care of our finances, and if there is any evidence that there are problems there in future then we should take more action. One thing that I would like to see improved is SPI's handling of our trademarks - we've had contradictory legal advice from SPI, and as a result we've taken no great deal of action against possible infringement. That's not good for the project.
AndreasSchuldei:: SPI is in the process to get its internal process worked out. Current events show that those effords start to take effect. As DPL i will try to help in that process and get involved. Branden, who is on the dpl-team is of course deeply involved allready and could serve in this capacity.
AngusLees:: There are several issues with SPI. SPI has some issues resulting from its nature as a volunteer organisation - I don't see why Debian would be any different here. Its 501c3 status, however, is only meaningful to US donors, and I think SPI (themselves) overstate their usefulness to Debian because of this. I would rather see the existing loose arrangement of tracking distributed piles of money with more formalised non-profit entities in many countries. SPI would be but one of these and Debian would oversee and manage them. On a different track, I see SPIs reason for existence as purely a financial entity - I am nervous about the few plans people have had for growing SPI into some political force. If that happened, we'd need to find a new bank account.

Under-represented groups in Debian

Helen:: Question 5 has a time limit of 4 minutes:
While from all over the world, Debian contributors tend to come from a fairly homogeneous background, and a number of groups are obviously under-represented in the project. For example there are very few Indian, female or elderly developers. What challenges and benefits do you see for Debian in encouraging greater participation from under-represented groups? What strategies do you deem feasible for the project to deal with the challenges and maximise the benefits?
JonathanWalther:: People organize themselves on the basis of interests and abilities. Debian is a self-organizing project. Those who are interested in Debian will be the best developers. If Debian is doing something to discourage any of the groups mentioned (women, Indians, and elderly) then it needs to stop doing those things at once. The squeaky wheel gets the grease; noone will know something is wrong until someone speaks up and talks about it. As DPL, I am inviting everyone to bring their problems out into the open where they can be dealt with.
AnthonyTowns:: Debian developer's aren't that homogenous, IMO. But there are certainly some groups that're underrepresented. I think we can only solve this for the people who actually want to join and are being prevented somehow; and I'm not aware of large Indian or elderly groups who'd like to contribute more to Debian but feel unable. I think the -women and translation projects set a good example to follow here of catering to special needs, and I think we should work on making the project as a whole better at those as we learn more those needs.
AngusLees:: I don't think its appropriate for Debian to seek out contributors from certain groups - if people from under-represented groups wish to join then that is up to them. What Debian should do is make sure that there are no barriers that unfairly affect certain groups - if/when they are identified, we should all do what we can to remove them.
BrandenRobinson:: Unfortunately, I'm not sure there's a lot that Debian can do in an official outreach capacity. I haven't seen many proposals along those lines. It should be noted that some groups are underrepresented due to the "digital divide" -- in many countries, socioeconomic stratification keeps Debian from being accessible to people. Educational opportunities are lean for many people worldwide as well. Focussing on the "developed" world, I think it's mostly a matter of creating a less threatening environment. I don't mind good rip-roaring debates, but we can all remind ourselves that group-oriented prejudices and stereotypes are out of place. The good news is that I only hear of these mostly because they have been forced underground in our project. Overall, Debian is a really tolerant place. I welcome folks' thoughts on how we can capitalize further on that trait.
AndreasSchuldei:: Again, SmallTeams is a possible answer here. With an on-team-translator, even people from other language groups could contribute, for example. (I talked to developers from India about this and he thought it was more of a cultural thing with free software, though). Debian-Women is making an effort to integrate more women in the project already and seems to do a good job at it. Other underrepresented groups could follow their example.
MatthewGarrett:: The debian-women project has done a great deal to make Debian more accessible to women, and the increased number of women in the NM queue shows that it's beginning to take effect. I think we need to look at making Debian more accessible to other underrepresented groups, and I think debian-women is a good model to work from here. More input from a wider range of groups makes it easier for us to produce a distribution that's useful for as many people as possible, and that's good for the spread of free software.

Managing DPL Duties and Life

Helen:: OK, last question for Part 1: Question 6 has a time limit of 2 minutes.
How do you plan to integrate your duties as DPL with your real life and your duties as Debian developer? On a hypothetical level, how would you react to substantial criticism that you are not devoting enough of your time to the job?
AnthonyTowns:: I'm sorry, I don't have enough time to answer that question. :) Umm, mostly I expect to be able rely on other developers to help me out if there gets to be a lot to do; most of the projects in Debian I've workedon have had co-maintainers, teams, or NMUers, or patchers or similar, andI expect if I'm DPL, I'll try to follow the same philosophy there.
BrandenRobinson:: I believe I mostly addressed this issue in my platform, and I urge people to review it. My real-life duties are already largely integrated with my life as a Debian developer, since I work on "Debian stuff" as part of my job (and career). If time constraints impose, I expect to be able to seek assistance from others. Delegation is good. The DPL team of which I'm a proud part is just one source of candidates for delegates. Above all, regular reporting and accountability are key to preventing time limitations from becoming crippling.
JonathanWalther:: Criticism is not a problem. I am accustomed to controversy. Technical excellence is what is important here. You will NOT get excellence without debate and competition. As for time, I have a job which is very flexible in hours. My availability to meet the needs of the project is excellent, probably the best of all the candidates.
MatthewGarrett:: If there is justifiable concern that I am not devoting enough time to the role of DPL, and if I am unable to alter the situation, then I will resign. I don't believe that that will be necessary, though. I've been reducing my other time commitments over the course of the past few months, and the student lifestyle is fairly well suited to having timeto devote to Debian... Fundamentally, the role of DPL should not be a huge time sink. It's about ensuring that the right people are doing the right job, not micromanagement.
AngusLees:: I consider travelling as an extremely important factor of being DPL. Before nominating, I carefully considered the time I will have available and I am confident that I can do what is required and it will not impact on my existing (minimal) Debian duties. micromanagement.
AndreasSchuldei:: I think that I established very well that i prepared and planned ahead for this not to happen: i can work on Debian and DPL issues during work hours and have the DPL-team to fall back on. Even with flames and critizim, which can hurt individuals and demotivate them severely, the team can help by offering moral support.
Helen:: That concludes the first half of the debate. Thankyou to all the candidates and to the people contributing interesting comments on the discussion channel. We will now break for 10 minutes to allow people to grab more coffee (especially those in UTC and similar timezones!).

Debate Part 2 - Question and Discussion

[07:10:21] AndreasSchuldei: Due to a self-inflicted irc fuck-up i managed to ignore everyone and everything on #debian-dpl-debate, including helen answering the questions. This was fixed during question 2. Feel free to ask me question 1 on -vote, please.
[07:10:38] martin_krafft: you can also answer now here if you want.
[07:10:58] AndreasSchuldei: what was the question, again?
[07:11:16] martin_krafft: http://rafb.net/paste/results/MuNRQi49.txt
[07:11:25] martin_krafft: 5 minutes. please restrict yourself appropriately
[07:14:41] BrandenRobinson: AndreasSchuldei: not your fault. Someone posted bogus advice to #-discuss. When I took it, irssi told me I was "ignoring ALL from #debian-dpl-debate".
[07:15:00] BrandenRobinson: So I just killed the ignore and let the joins/parts wash over me :)
[07:15:02] AndreasSchuldei: yes, i noticed too late
[07:15:30] martin_krafft: /ignore * PARTS JOINS QUITS worked fine for me in irssi
[07:16:04] BrandenRobinson: what exactly I did has long since been expunged from my irssi command history, I fear
[07:16:20] BrandenRobinson: not like it would be politic to go pointing the finger of blame right now anyway ;-)
[07:16:29] martin_krafft: quiet now
[07:16:38] martin_krafft: here comes AndreasSchuldei's reply to question #1
[07:17:11] martin_krafft: [AndreasSchuldei] The DPLs job is to find the right people to manage the release. I think the present team is excellently qualified and has worked on the issues involved for some time already. My job as DPL would try to help them sort out problems outside their power. It would be their job to find the best release strategy.
[07:17:21] martin_krafft: okay, the break is over
[07:17:31] martin_krafft: would the candidates please pong to confirm they are listening?
[07:17:50] AndreasSchuldei: yes
[07:17:51] BrandenRobinson is present and ready.
[07:18:00] MatthewGarrett: yup
[07:18:07] AnthonyTowns: yo
[07:18:10] AngusLees pongs
[07:18:36] martin_krafft: AngusLees: ?
[07:19:01] JonathanWalther: pong
[07:19:08] martin_krafft: AngusLees, BrandenRobinson: ping?
[07:19:16] helen: martin_krafft: they're here
[07:19:22] AnthonyTowns: martin_krafft: they /me'ed
[07:19:34] AngusLees pings too for good luck
[07:20:08] martin_krafft: Okay, let the second part begin
[07:20:27] martin_krafft: this is open debate, so I ask you to please exercise all due rules and such
[07:20:36] martin_krafft: people might well watch at how well you are handling such a debate.
[07:20:48] martin_krafft: @world: if you have followup questions, please post them to the mailing list.
[07:20:57] martin_krafft: here comes #1
[07:21:06] martin_krafft: Is the currently available infrastructure enough for now and the future? If not, in what areas are advances most needed?
[07:21:07] AndreasSchuldei: do we get to answer questions, too?
[07:21:15] martin_krafft: yes
[07:21:17] BrandenRobinson: AndreasSchuldei: I believe that's the idea :)
[07:21:38] JonathanWalther: infrastructure will be found when it is needed.
[07:21:43] martin_krafft: "the mailing list" is [email protected]
[07:21:46] MatthewGarrett: What sort of infrastructure are we talking about? Social or technical?
[07:21:49] BrandenRobinson is not too worried about hardware infrastructure, though there seem to be concerns about mirror space and bandwidth...
[07:21:50] JonathanWalther: our growth will stay static until our infrastructure grows
[07:21:55] AnthonyTowns: And software or hardware?
[07:21:57] helen: MatthewGarrett: either or both
[07:21:58] AngusLees: that question is too open to really address properly..
[07:22:00] martin_krafft: MatthewGarrett: i believe both.
[07:22:16] AndreasSchuldei: Beeing a technical project full of geeks, we have managed well solving those problems untill now. (c:
[07:22:17] martin_krafft: Okay, let's talk about communication infrastructure
[07:22:19] AnthonyTowns: Better BTS, archive software, etc etc is always needed, anyway.
[07:22:25] BrandenRobinson: Personnel-wise, I think we could definitely stand to take a hard look at the teams we have, and ask the current membership how we can best grow the ranks constructively, if and as needed.
[07:22:43] AnthonyTowns: Mostly that's the job of various delegates to work on, and the DPL to facilitate more than ebing something the DPL can direct.
[07:22:46] martin_krafft: BrandenRobinson: what would that entail?
[07:22:51] BrandenRobinson: One of the first things I'd like to do as DPL is to survey the existing infrastructural teams with precisely this in mind> Do *they* feel they're overworked/understaffed?
[07:23:08] MatthewGarrett: Socially, I worry about both the amount of aggressive behaviour on mailing lists and the lack of communication from various parts of the project. I'm somewhat guilty of the first myself - I'm trying to improve in that respect. In terms of the second, well, I think my platform makes it clear what I think :)
[07:23:12] AndreasSchuldei: BrandenRobinson: i agree. here we cross over from the technical to the social.
[07:23:14] BrandenRobinson: If so, what sort of things would help? Does code need to be written? Are faster machines required? How about new team members?
[07:23:32] JonathanWalther: Our technical infrastructure in Debian is the best in the Linux world. Because of that, our personal problems with communication get thrown into stark highlight. We can't blame technology anymore; we can only work on improving ourselves. Who here is up to that challenge?
[07:23:41] BrandenRobinson: I forsee a large part of my first few montly DPL reports as being "State of the Project" reports on these aspects of infrastructure.
[07:23:48] BrandenRobinson: s/forsee/foresee/
[07:23:51] martin_krafft: BrandenRobinson: interesting.
[07:24:10] martin_krafft: Let's see... walking on a tangent, what do you think are the greatest communication problems in Debian today?
[07:24:11] AnthonyTowns: So, with an infrastructure hat on, my answer would mostly be "mailing lists that aren't full of flamewars, anytime you suggest something difficult" as the most useful feature to make life easier.
[07:24:11] AndreasSchuldei: i would think debian needs a cuture change to handle the *listening* better. (c:
[07:24:22] AnthonyTowns: Obviously I've tried to address that in my platform
[07:24:22] martin_krafft: AnthonyTowns: i will return to this in a second.
[07:24:25] BrandenRobinson: On that note, I think Matthew Garrett did us a great service by describing the current state of affairs, based on his personally-conducted research.
[07:24:28] JonathanWalther: If we need more bandwidth or more disk space, we can always find those. Our bug tracking system and mailing lists are the best you'll find anywhere.
[07:24:44] BrandenRobinson: WRT one aspect of infrastructure.
[07:24:47] martin_krafft: JonathanWalther: how many BTS do you know?
[07:24:56] MatthewGarrett: The greatest communication problems? I'd tend towards the lack of it.
[07:25:07] martin_krafft: MatthewGarrett: and what would be reasons?
[07:25:10] JonathanWalther: martin_krafft: bugzilla. I use a few proprietary ones at work. I've used the BSD sendpr stuff.
[07:25:16] BrandenRobinson: What we need to do is repeat this for all the traditionally flamed-about areas. The best quencher of flames is facts, backed up and calmly reported.
[07:25:20] helen: AngusLees: what do you think about Debian's communication problems?
[07:25:37] JonathanWalther: Debians biggest communication problem is people with thin skins.
[07:25:39] BrandenRobinson: are we totally freewheeling here?
[07:25:42] JonathanWalther: Everyone loves a rollicking good debate.
[07:25:45] MatthewGarrett: To some extent, I think it's possibly due to the fact that the project has changed in size to a massive extent
[07:25:45] BrandenRobinson: i.e., will there be a "question 2"?
[07:25:48] martin_krafft: BrandenRobinson: within bounds. :)
[07:25:56] AngusLees: helen: I don't think there's much new to add.
[07:25:58] BrandenRobinson: JonathanWalther: don't quote me without citation, please ;-)
[07:25:59] MatthewGarrett: (Uh, please ignore the fact that I used the word extent twice there)
[07:26:00] martin_krafft: BrandenRobinson: kind of... :)
[07:26:07] BrandenRobinson: martin_krafft: okay.
[07:26:18] JonathanWalther: but when people with thin skins come along, it has a chilling effect on cameraderie, rough-housing, and all the high energy thinking that goes into making Great Software.
[07:26:22] AngusLees: clearly everyone seems to have recognised the same sets of problems and suggested similar solutions
[07:26:31] JonathanWalther: boys need to blow off steam. fact.
[07:26:33] helen: AngusLees: fair enough
[07:26:42] martin_krafft: let's combine communication and infrastructure... JonathanWalther wants VoIP, but what other improvements could help our communication?
[07:26:45] AndreasSchuldei: JonathanWalther: so are we discriminating against people with thin skin?
[07:26:48] MatthewGarrett: I'd like to see teams talk about what they're doing and *why* on a more regular basis, and the increased number of posts from teams to devel-announce is very heartening
[07:26:56] JonathanWalther: martin_krafft: eh? VoIP? I hate VoIP!
[07:26:57] AnthonyTowns: In response to Jonathan's point, I don't think we can afford to turn away good people with thin skins: I think the only real question we should discriminate on is how well you can contribute to the project.
[07:26:57] AngusLees: martin_krafft: s/jonothanwalther/me/
[07:27:02] martin_krafft: argh
[07:27:03] martin_krafft: sorry.
[07:27:08] BrandenRobinson thinks there is a balance to be found between the flame-heavy extreme-deathmatch list scenario, and the all-roses-and-chirping birds scenario. I know I've experienced social pressure to alter my approach to the lists over the years, and that's as it should be.
[07:27:28] martin_krafft: What are the differences between lists that have flamewars and those that don't?
[07:27:36] AngusLees: martin_krafft: size of audience
[07:27:36] BrandenRobinson: "If you can't say something nice, don't say anything at all" can lead to conflict with "We Won't Hide Problems".
[07:27:36] JonathanWalther: BrandenRobinson: you are one to complain about thin skins; you had me on /ignore for a long time. ^_^
[07:27:47] BrandenRobinson: JonathanWalther: that's not actually true :)
[07:27:57] MatthewGarrett: I agree with Branden and Anthony here. The lists could do with some cleaning up, and I think more social pressure is a good start here
[07:27:59] AndreasSchuldei: i think it is mostly the mix of individuals and the size.
[07:28:03] JonathanWalther: BrandenRobinson: ah. you did a really good job of pretending to /ignore me then ;)
[07:28:19] JonathanWalther: BrandenRobinson: which takes a stunning amount of self-control. I applaud you.
[07:28:22] BrandenRobinson: JonathanWalther: I do sometimes keep my mouth shut if someone is provoking me so badly that I might just embarrass myself by talking :)
[07:28:24] martin_krafft: What kind of social pressure are we talking about?
[07:28:31] MatthewGarrett: The biggest difference between lists with flamewars and lists without is probably down to how those lists are used
[07:28:38] AngusLees: JonathanWalther: i'm guilty of deleting your -private posts based purely on the sender
[07:28:39] AnthonyTowns: martin_krafft: Usually it's a habit of just not having flamewars -- it takes at least two to create one, and if people are in the habit of just chilling, they don't start. Debian's not really in that habit in a lot of places.
[07:29:02] BrandenRobinson: martin_krafft: calm replies to unreasonable messages that point out how a person could responsd more constructively.
[07:29:12] BrandenRobinson: martin_krafft: It's an art form. Some people are very good at it, others aren't.
[07:29:13] AndreasSchuldei: martin_krafft: is this the kind of debate you envisioned? it seems pretty chaotic.
[07:29:14] martin_krafft: AnthonyTowns: you want to "enforce"... do you see other ways than moderation?
[07:29:28] MatthewGarrett: Lists that focus entirely on a specific task (or small subset of tasks) tend to be without flamewars. People are on those lists because they're actually doing stuff, so there's much less temptation to descend into flames.
[07:29:32] JonathanWalther: AnthonyTowns: to the contrary, people with thin skins need to program alone.
[07:29:33] AngusLees: flaming seems to only be a problem where there are audiences: ie: -private, -devel, -project, -legal
[07:29:44] martin_krafft: AndreasSchuldei: you may well suggest another format. It's not easy to debate with 7 people on IRC.
[07:29:44] AngusLees: the smaller, focussed lists don't seem to have problems
[07:29:45] BrandenRobinson: Ouch. I just got ripped on -discuss.
[07:29:46] JonathanWalther: AnthonyTowns: people with thin skins are a net liability to ANY type of team effort. Debian is a massively team effort
[07:29:50] AnthonyTowns: I want to solve the problem; and I think it's bad enough that some sort of enforcement, rather than just a list policy and polite reminders is necessary. I'd love to be wrong.
[07:29:52] AndreasSchuldei: yes
[07:30:14] JonathanWalther: AnthonyTowns: we can't afford thin-skins throwing monkey wrenches into things. That is part of why Debian has stagnated of late; too many thin skins combined with assholes.
[07:30:22] BrandenRobinson seconds AndreasSchuldei's observation that this is a bit chaotic.
[07:30:31] martin_krafft: suggestions?
[07:30:42] MatthewGarrett: JonathanWalther: What level of criticism do you believe people should have to put up with?
[07:30:46] martin_krafft: i can also ask questions and allow 1-3 sentences for answering to each. :)
[07:30:52] AnthonyTowns: Moderation -- ie, every post being approved by a moderator group -- is pretty extreme; delaying posts (as already happens to some extent), bouncing replies to some contentious threads, digesting mail for subscribers who've been provoked into being uncooperative, or suspending/banning people are all other options.
[07:31:04] AndreasSchuldei: JonathanWalther: thin skins just means that they take the insults they receive to hard. in my oppinon there should be no insults in the first place. it is possible. we should try.
[07:31:06] BrandenRobinson: martin_krafft: I am known for my ability to craft very long sentences -- that might give me an unfair advantage. ;-)
[07:31:12] JonathanWalther: MatthewGarrett: I think threatening someones personal safety is beyond the limit.
[07:31:16] AngusLees: i would like to see a more widely known standard for what sorts of posts are deemed better to not have been sent
[07:31:37] AnthonyTowns: JonathanWalther: Yeah, I think there's a compromise to be reached between treating people with respect and not getting in the habit of flying off the handle ro getting overly grumpy.
[07:31:39] AngusLees: and we can refer people to that. repeat offenders (and most of the problems come from them) can be moderated or something
[07:31:39] MatthewGarrett: JonathanWalther: So all criticism up to that point should be accepted? I'd disagree quite vigerously
[07:31:41] BrandenRobinson: I believe I expressed my opinions on hard-moderation tactics in -vote.
[07:31:45] helen: BrandenRobinson: I think we're doing OK. this is not as complex/confusing as some IRC discussions I've seen. People will sort it out later on anyway.
[07:31:51] martin_krafft: It has been raised that Debian encourages flames by commending their posters.
[07:31:51] AndreasSchuldei: imho this debate mostly proves that we have a lot of candidates talking. (c:
[07:32:05] martin_krafft: I have also seen people commending calm posters.
[07:32:05] JonathanWalther: AndreasSchuldei: A thin skin will ALWAYS find a way to construe criticism or humour as an insult.
[07:32:09] BrandenRobinson: I don't believe we should undertake them without having a well-documented process for appeals that has the trust of the developers.
[07:32:11] martin_krafft: Do you think more of that would help?
[07:32:18] BrandenRobinson: A gag is a powerful weapon.
[07:32:22] JonathanWalther: AndreasSchuldei: therefore there is no possibility of eliminating "insults"
[07:32:27] martin_krafft: Do you think public tar-and-feather approaches might reduce flamewars?
[07:32:40] JonathanWalther: martin_krafft: absolutely not
[07:32:42] AndreasSchuldei: JonathanWalther: not true, i am on channels and lists with sensitive people on them, and they do fine there.
[07:32:44] AngusLees: martin_krafft: public tar-and-feather approaches *start* flamewars
[07:32:47] JonathanWalther: martin_krafft: people need to be mature enough to use /ignore
[07:32:58] BrandenRobinson: martin_krafft: Some people can be "shamed", others seemingly cannot.
[07:33:01] AnthonyTowns: BrandenRobinson: A post to -devel-announce is a pretty powerful weapon too :-P
[07:33:03] martin_krafft: AngusLees: exactly.
[07:33:04] MatthewGarrett: martin_krafft: If done by someone with sufficient authority? I think so, but it depends on what you mean by "tar and feather".
[07:33:10] BrandenRobinson: AnthonyTowns: Acknowledged.
[07:33:10] AndreasSchuldei: JonathanWalther: there, we hardly have any insults.
[07:33:12] JonathanWalther: AndreasSchuldei: really? which lists and channels are these?
[07:33:22] AndreasSchuldei: #debian-devel, for one
[07:33:23] martin_krafft: MatthewGarrett: take aj's and my flamewar from February.
[07:33:27] AnthonyTowns: martin_krafft: Public tar and feathering *is* a flamewar. I don't think making them official will reduce the unofficial ones; quite the oppisite.
[07:33:34] AndreasSchuldei: äh
[07:33:38] martin_krafft: If you had stepped in and told us both to go play with toys, do you think it would have helped?
[07:33:40] AndreasSchuldei: debian-edu, soory
[07:33:44] JonathanWalther: AndreasSchuldei: uh. right.... the channel where doogie talks about shaving his pubic hair in public?
[07:33:47] AngusLees: the "that post was inappropriate for this list" posts should be done in private - otherwise they just continue the very thread they're stopping
[07:33:58] JonathanWalther laughs
[07:34:01] BrandenRobinson: Social pressures can get out of control too. I don't think we necessarily want to go the way of shunning, or scarlet letters.
[07:34:01] AndreasSchuldei: JonathanWalther: sorry, freudean slipp. (c:
[07:34:16] BrandenRobinson: That leads to a less tolerant society, not a more tolerant one.
[07:34:18] MatthewGarrett: I think it's important for it to be made publically clear that certain behaviour is unacceptable, but I think that ought to be done in a calm and reasoned way
[07:34:26] AngusLees: i'm not confident social pressure alone can get debian out of the hole we're in
[07:34:31] martin_krafft: AnthonyTowns: i think the community might well misunderstand your desires to "enforce"... how do you plan to enforce without too much social pressure?
[07:34:36] MatthewGarrett: (I know I'm guilty of failing in this, and I've already apologised for that after people picked me up on it)
[07:34:38] martin_krafft: AngusLees: what else could?
[07:34:59] JonathanWalther: when people get into a pissing contest, they need peer pressure telling them that they've gone beyond the pale. the last thing they need is to garner yet more (as they perceive it) attackers
[07:35:00] AngusLees: martin_krafft: we need to have a fairly widely published list of what we consider appropriate (for each list)
[07:35:17] BrandenRobinson: MatthewGarrett: implying that the general subscribership (at least the subset who post) of -legal is basically nuts isn't very nice either.
[07:35:24] AndreasSchuldei: AngusLees: i think social pressure is where we need to start. we should not escalate measures of dicipline to quickly.
[07:35:25] JonathanWalther: AngusLees: baloney. everyone here is an adult and should be expected to know what that means
[07:35:26] AngusLees: martin_krafft: then we need to have known procedures in place for dealing with repeat offenders
[07:35:35] martin_krafft: AngusLees: don't we already? or even more concrete?
[07:35:48] AnthonyTowns: martin_krafft: Most of the options I said above were technical options: if things get out of hand, posts just stop going through. That can calm things down, which I think is helpful. The real trick isn't social pressure, it's.. I don't know, social reinforcement -- having an environment where people don't mind posting because they know their ideas will be treated with dignity, and don't need to flame, because they're confident they'll be
[07:36:00] MatthewGarrett: BrandenRobinson: I disagree with the viewpoints expressed, and my experience suggests that the consensus viewpoint on d-l is not the same as the consensus viewpoint amongst other developers.
[07:36:05] BrandenRobinson: Like SPI, -legal does -- or tries to do -- some gritty, sometimes unrewarding work that not all people care to fool with.
[07:36:18] martin_krafft: AnthonyTowns: and walk the thin line between that and censorship...? how?
[07:36:29] AngusLees: martin_krafft: more widely published. for example, i don't think i've ever stumbled across such a statement (although i know we have it somewhere)
[07:36:44] AnthonyTowns: martin_krafft: Carefully. :)
[07:36:44] martin_krafft: AngusLees: it's linked from lists.debian.org
[07:36:46] MatthewGarrett: I don't believe people's viewpoints should be ignored just because they're unwilling to express them in a forum where they feel unwelcome
[07:36:47] BrandenRobinson: MatthewGarrett: I think a lot of the problem is a lack of outreach. I've been pondering a "surprising FAQ" that would expose some of the more counterintuitive aspects of copyright/patent law to the uninitiated.
[07:37:06] AngusLees: by definition, the problem posters are frequent offenders
[07:37:12] AndreasSchuldei: an interesting option that was suggested by our new DAM was to ask individuals who have a hard time restricing themself to step out for a social checkup.
[07:37:18] BrandenRobinson: MatthewGarrett: In many cases, people feel -legal is "being unreasonable" simply because people there have researched the real-world application of law.
[07:37:21] AnthonyTowns: martin_krafft: Having checks and balances on what threads/people are gagged, having different areas where people can discuss things or flame or whatever and otherwise have an outlet is good too.
[07:37:22] JonathanWalther: MatthewGarrett: that is an interesting statement, considering you banned me from the debian-women@ mailing list, based on the fact that a few women didn't like my beliefs.
[07:37:36] BrandenRobinson: MatthewGarrett: and the law, it is said, "is an ass".
[07:37:48] JonathanWalther: MatthewGarrett: how do you reconcile your real world censorship of a Debian developer from a Debian mailing list, and your previous statement about not believing in censorship?
[07:37:53] AnthonyTowns: "confident they'll be consulted." if that was truncated before, btw
[07:38:04] MatthewGarrett: JonathanWalther: I haven't banned anyone from any mailing lists
[07:38:11] martin_krafft: Here's a question from the community: Do you feel it is appropriate to delegate new people to a position within Debian without the support of the individuals already delegated, should that need arise?
[07:38:12] MatthewGarrett: I'm not even a subscriber to debian-women
[07:38:25] BrandenRobinson: As long as we labor under the perversities of the concept of "intellectual property", I fear people's intuitive notions of free software will hit the shoals of reality.
[07:38:45] AngusLees: moderation isn't censorship btw. (its simply congestion control ;)
[07:39:00] AnthonyTowns: martin_krafft: It's not whether it's appropriate; it's whether it's effective. Having two people in a team working against each other doesn't work. But there's plenty of ways of encouraging people to accept new members into teams.
[07:39:02] BrandenRobinson: AngusLees: it's not? Even if a post is bounced/rejected?
[07:39:05] martin_krafft: AngusLees: people will disagreeon that.
[07:39:15] helen: can we move on to martin_krafft 's latest question now please.
[07:39:20] AngusLees: provided reasonable posts by a "problem poster" are still allowed through, i don't see anything wrong with it
[07:39:21] MatthewGarrett: BrandenRobinson: But to a large extent, the argument is down to differing beliefs about how stringently the DFSG should be interpreted. That's not down to disagreement about how the law applies.
[07:39:43] AndreasSchuldei: martin_krafft: i think such steps need some consideration. it depends on the individual and the group, and how the group is doing.
[07:39:52] JonathanWalther: MatthewGarrett: sorry; I must have mixed you up with a different Matthew. Perhaps Matthew Palmer. Someone who has admin access to the Debian mailing lists anyway, unilaterally booted me from debian-women@
[07:40:02] JonathanWalther: MatthewGarrett: if you were DPL, what would you do to remedy that?
[07:40:10] helen: BrandenRobinson, AngusLees, MatthewGarrett, JonathanWalther : next question, please :)
[07:40:13] martin_krafft: AndreasSchuldei: well, what might a DPL do to make sure that all groups actually make it possible?
[07:40:17] AndreasSchuldei: could that community question person elaborate on the context, for a more sensible answer?
[07:40:17] BrandenRobinson: MatthewGarrett: Sometimes, that is the case. But I've seen people on -legal get angry and carry over...
[07:40:19] helen: [07:38:11] martin_krafft Here's a question from the community: Do you feel it is appropriate to delegate new people to a position within Debian without the support of the individuals already delegated, should that need arise?
[07:40:21] BrandenRobinson: helen: okay.
[07:40:42] JonathanWalther: Delegation is always volunteer.
[07:40:46] BrandenRobinson: helen: I'd regard that as an option of near last-resort.
[07:40:54] martin_krafft: JonathanWalther: see womble on -discuss
[07:40:56] BrandenRobinson: JonathanWalther: the moderators mean appointment to a team
[07:40:59] MatthewGarrett: If it's the only way to ensure that work is done to a standard acceptable to the rest of the project, then yes
[07:41:02] JonathanWalther: You can be delegated. And you can refuse the delegation. There is no need for prior consultation.
[07:41:06] AngusLees: helen: if the result is going to be harmful, of course not
[07:41:14] JonathanWalther: martin_krafft: I'm not on -discuss
[07:41:18] AndreasSchuldei: martin_krafft: "never change a running system". if the groups work well no need of additional man power is there and they dont want more people, the dpl should keep out of their way. (c:
[07:41:24] JonathanWalther: martin_krafft: I can only track two irc windows at once
[07:41:36] martin_krafft: AndreasSchuldei: but what if a group suddenly goes unwell.
[07:41:37] BrandenRobinson: JonathanWalther: the scenario is, A, B, and C are on team X. The DPL wants to appoint D, and D wants the position, but A, B, and C don't want D on the team.
[07:41:43] martin_krafft: JonathanWalther:
[07:41:44] martin_krafft: [08:40 womble Can I get a retraction on that comment by krooger? I don't
[07:41:47] martin_krafft: have admin powers over any list
[07:41:55] AndreasSchuldei: martin_krafft: the reason for that would be interesting.
[07:42:03] martin_krafft: AndreasSchuldei: death?
[07:42:09] AndreasSchuldei: martin_krafft: if a new member can fix it, sure.
[07:42:11] BrandenRobinson: As I said, I'd hate to see things reach that point. I would definitely do a lot of consulting around before taking that step.
[07:42:15] martin_krafft: (to name the most extreme)
[07:42:17] MatthewGarrett: But obviously it's going to cause unhappiness and general misery, so it should only occur if there's no other solution
[07:42:17] JonathanWalther: martin_krafft: people are free to read Matthew Palmers posts to debian-women and decide for themselves what "powers" he has.
[07:42:19] AndreasSchuldei: martin_krafft: is the group dying or a memeber?
[07:42:25] BrandenRobinson: Because of course, one risks the angry resignations of A, B, and C.
[07:42:39] martin_krafft: AndreasSchuldei: let's say 50% of them stop working for the group.
[07:42:57] MatthewGarrett: But fundamentally no set of people, no matter how established they are, should have the ability to become a major bottleneck without justification
[07:43:07] AndreasSchuldei: martin_krafft: the desired state would be that the group notices that a memeber is dead. (c: and then go and find a successor.
[07:43:14] AngusLees: BrandenRobinson: exactly. so A, B and C would have to be completely disfunctional already for the DPL to even be considering forcing in a new person
[07:43:22] AndreasSchuldei: if the dpl is the only one knowing, he should tell them and help them go on.
[07:43:36] MatthewGarrett: A consensus-based solution to that is massively preferable, but if that's impossible then "hostile" delegation is the only real option
[07:43:37] BrandenRobinson: MatthewGarrett: It's interesting that 3 separate teams have veto power over adding a new architecture to the releasable group for etch, in the Vancouver Prospectus.
[07:43:38] JonathanWalther: BrandenRobinson: obviously, the right to freedom of association (gauranteed in the Canadian constitution) means that although the DPL can delegate someone to a team, if the team doesn't accept them, that is the DPL's tough luck. The real question is, is the DPL willing to sack the entire team in order to get his delegate into position?
[07:43:54] martin_krafft: alright, enough of this. i have been told to shut up more.
[07:43:58] martin_krafft: let's move on...
[07:44:02] martin_krafft: It is probably safe to say that the results of the Vancouver meeting
[07:44:04] martin_krafft: stirred the community up quite a bit. What could have been done
[07:44:05] BrandenRobinson: Delegates serve at the pleasure of the DPL.
[07:44:07] martin_krafft: better to prevent such turbulences and potential loss of
[07:44:09] martin_krafft: productivity?
[07:44:14] MatthewGarrett: BrandenRobinson: If such a veto occured without justification, I'd be asking questions.
[07:44:17] BrandenRobinson: martin_krafft: nice segue from my previous remark :)
[07:44:38] martin_krafft: BrandenRobinson: unintentional, but with pleasure in the after thought. :)
[07:44:41] JonathanWalther: martin_krafft: I don't see any loss of productivity. The Vancouver meeting was a necessary bit of quiet time for the release managers to get together without distraction.
[07:44:43] AngusLees: martin_krafft: it seems the meeting was arranged hurriedly for some reason. i think there was no need for such haste (the DPL election?)
[07:44:49] JonathanWalther: martin_krafft: again, I fully support the right to freedom of association.
[07:44:54] AndreasSchuldei: martin_krafft: then the group should try to find new members, in an active way.
[07:45:00] BrandenRobinson: AngusLees: That might simply have been a matter of availability.
[07:45:01] AnthonyTowns: martin_krafft: Obviously, I like the idea of cutting off the flamewar where it starts to get nasty, non-technical or overly repetitive. :-/
[07:45:15] AndreasSchuldei: martin_krafft: the dpl should tell them to do so, if they dont.
[07:45:15] BrandenRobinson: AngusLees: recall how hard it was for the 6 of us just to settle on a time for a 2-hour debate we could do via IRC.
[07:45:17] AngusLees: BrandenRobinson: surely availability is also easy to work out if there are longer time frames involved
[07:45:20] JonathanWalther: martin_krafft: if any group of Debian developers wants to get together for a purpose involving Debian, the rest of Debian has no say in that. But it would be very rude if such a group didn't make their purposes or activities known to the public.
[07:45:26] AnthonyTowns: martin_krafft: From the other side of things, having had more debates in public in advance would have been helpful; but in the current list climate just seems impossible to me.
[07:45:31] JonathanWalther: martin_krafft: it would be anti-Debian, even.
[07:45:36] MatthewGarrett: I think https://lists.debian.org/debian-vote/2005/03/msg00659.html would be a good set of starting points here
[07:46:10] martin_krafft: do you have any comments on the way the proposal was brought forth?
[07:46:20] MatthewGarrett: More opportunity for input in advance would have improved things, even if most of that input had been ignored. More detailed justification afterwards would have changed the character of the discussion considerably.
[07:46:26] BrandenRobinson thinks that the Vancouver Prospectus could have been written in a way that would not have poked the hornet's nest quite so badly, but I also suspect 1) the task of writing it up fell to one poor sucker of a volunteer (hi vorlon) who was under time pressure to get it out quickly, and 2) It was destined to generate a lot of discussion no matter what.
[07:46:38] BrandenRobinson: Simply because of the conclusions reached.
[07:46:50] AngusLees: and it seems the discussion started off with "we need to reduce the architectures on the mirrors down to ~4. how do we choose which?" which wasn't the way it was described at all
[07:47:03] AngusLees: when put that way (and explained why thats necessary) it all seems quite reasonable
[07:47:05] BrandenRobinson: As time goes on, I hope that some document is put together that satisfies the goal I established for the VancouverProspectus page on wiki.debian.net.
[07:47:10] AnthonyTowns: For reference, the document got reviewed by everyone who was there; though Steve (vorlon) wrote most of it
[07:47:27] martin_krafft: let's look at the content...
[07:47:28] AndreasSchuldei: the proposal was really meant as a proposal. the ongoing and to a good deal productive discussion between the involved people shows that best
[07:47:28] martin_krafft: Debian is known as the universal operating system. It is also known to suffer from long release cycles. What is the purpose of Debian? Does sacrifice of the "universal" slogan warrant shorter release cycles? What do our users want?
[07:47:50] JonathanWalther: I think the Vancouver concensus was done as gently and unobtrusively as possible.
[07:47:58] JonathanWalther: I see nothing for Debian to complain about in how it was conducted.
[07:48:00] BrandenRobinson: Well, "universal" means different things to different people.
[07:48:19] AngusLees: ah. apparently vorlon has said that longer times were considered. thats cool then
[07:48:21] BrandenRobinson: Does the lack of a "stable release", itself an arbitrary thing, necessarily negate universality?
[07:48:33] JonathanWalther: martin_krafft: Debian is known for its rock-solid, easy upgrades. few of our userbase care about all the esoteric architectures.
[07:48:34] AndreasSchuldei: debian would not lose the architectures. it would be able to open up to new ones, instead.
[07:48:40] BrandenRobinson: I think that's a question we need to answer collectively. It's not something the DPL can dictate.
[07:48:47] JonathanWalther: martin_krafft: a few years ago we were also known for our easy install too
[07:49:11] BrandenRobinson 's UltraSPARC, necrotic.deadbeast.net, runs unstable.
[07:49:14] AnthonyTowns: I don't think we're dropping the "universal" slogan; we're just potentially changing the way we'll support some architectures. I certainly hope it won't mean people using non-i386/ppc not being able to use Debian usefully.
[07:49:20] AndreasSchuldei: JonathanWalther: we are on a good way to have easy installs in the furture, too. (c:
[07:49:29] BrandenRobinson: If it continues to serve its purpose soundly even as a "second-class" arch, I will not personally be too adversely affected.
[07:49:36] AngusLees: the scalability of the debian approach to building a distro is one of its most important features (as i mentioned in a respone to a question in phase1)
[07:49:41] martin_krafft: isn't "second class citizens" bound to make people reconsider?
[07:50:04] BrandenRobinson: I also hope that vested interests (read: corporations) in the community with an investment in those 'second-class architectures' will help put their shoulders to the wheel to help get them promoted back to first-class.
[07:50:06] MatthewGarrett: I don't think the length of our current release cycle is sustainable, and I think it's cost us good-will from the community. I don't want to lose stable releases of some architectures (I've got at least 7 of our supported architectures in this room right now), but if that's the only way to support the vast majority our users then I think it's something we'd have to accept.
[07:50:22] AndreasSchuldei: the current *constructive* part of the discussion will solve that problem, i am convinced.
[07:50:22] AngusLees: i think people come to debian *because* we can (and do) support all sorts of niche areas
[07:50:25] AnthonyTowns: I don't think Debian has any one purpose; it's got at least as many as there are developers, and probably an order of magnitude more than that. I like it because I think it demonstrates how software development should be done
[07:50:29] BrandenRobinson: It may be that we have a bit of a "tragedy of the commons" going on when it comes to energetic volunteers and some architectures.
[07:50:47] MatthewGarrett: But *before* we make that decision, I'd like to see more discussion of what the problems we're solving are. The release team have made it clear what they view the problems as being, and that's been immensely helpful. I'd like to see something similar from the ftp-masters.
[07:50:53] AndreasSchuldei: debian has allways excelled in solving its technical problems, and it will do so this time, too
[07:50:57] BrandenRobinson: MatthewGarrett: hear, hear.
[07:51:14] MatthewGarrett: It's possible that we can come up with another proposal that solves the problems /without/ resulting in reduced architecture support.
[07:51:37] MatthewGarrett: Debian is a resourceful organisation. If we can't fix the problem, then the problem may be unfixable. And in that case, we have to make a hard choice.
[07:51:50] JonathanWalther: I haven't used the "stable" distro in years.
[07:51:55] JonathanWalther: how many people actually use stable?
[07:51:57] martin_krafft: we have another community question:
[07:52:08] AngusLees: JonathanWalther: i use it every day at work in the products i make
[07:52:08] MatthewGarrett: As I said, as much as I dislike it, I think dropping some support for some architectures is better than taking 3 years to release
[07:52:11] martin_krafft: In what way do you think Debian can honor the labor contributions of non-DDs who do significant work for the project (e.g. translators)?
[07:52:16] BrandenRobinson: AndreasSchuldei: I like your confidence, but I wouldn't want to lull people into complacency. We'll only solve this problem if we get off our butts and work for it.
[07:52:26] AngusLees: believe me, corporate (and embedded, etc) users do *not* want 6 monthly releases
[07:52:29] BrandenRobinson: martin_krafft: Insufficiently.
[07:52:39] JonathanWalther: it is important to remember that "dropping support" is much different from dropping the architecture.
[07:52:45] MatthewGarrett: In my experience, the best reward I've obtained from my contributions to anything has been to see it being used.
[07:52:49] martin_krafft: BrandenRobinson: and that cannot change?
[07:52:52] JonathanWalther: the developers for various architectures work hard, and are proud of the fruits of their labors.
[07:52:58] BrandenRobinson: martin_krafft: When I get debconf translation updates for xfree86, for example, I always credit the submitter.
[07:53:03] JonathanWalther: even our "unsupported" architectures will live up to the high Debian quality
[07:53:04] BrandenRobinson: I've seen many other people do that too...
[07:53:22] BrandenRobinson: But given the benefits of translation, I'm not sure the people who do that work are esteemed as highly as they should be.
[07:53:22] JonathanWalther: and once we have the unsupported category, we will be able to add even more architectures in.
[07:53:38] MatthewGarrett: We need to ensure that contributions from non-DDs are incorporated rather than being dropped on the floor, and we need to make it clearer to people how they can get involved in doing that
[07:53:41] martin_krafft: JonathanWalther: in the real world, people care very much about the official vs. not 100% official labels. do you see that as a problem?
[07:53:41] BrandenRobinson: I got a bit of insight last year into just how challenging translating some of my English, for example, can be... :)
[07:53:43] AndreasSchuldei: MatthewGarrett: i actually think the people involved in solving the problems (porters, relase team and the ftp masters) are very well qualified to find a good solution. have some faith in them and give them some time to find it.
[07:54:00] JonathanWalther: AngusLees: corporate and embedded users don't want to upgrade at all; they want to take a snapshot and run with it for years and years, like NeXT did with 4.3BSD.
[07:54:09] helen: AnthonyTowns, AngusLees : do you have an opinion on that?
[07:54:09] AngusLees: i think we aknowledge contributions well already. most changelog lines will include a persons name where appropriate - and the scandle that arises when someone screws this up just shows how well we do normally
[07:54:15] BrandenRobinson: Here's an idea for a DWN feature: weekly, we could give props to a translator or l10n specialist.
[07:54:16] JonathanWalther: AngusLees: we shouldn't try to pick oranges from an apple orchard
[07:54:16] AnthonyTowns: martin_krafft: I'm not sure what more you want than already happens; mentioning the names of people who contribute patches seems fairly standard practice; and I assume the translation websites already have shout outs to the guys who do the work.
[07:54:24] MatthewGarrett: AndreasSchuldei: I think limiting the set of people working on a problem of this magnitude is not necessarily wise.
[07:54:26] BrandenRobinson: I think the KDE project used to do this for some of their developers.
[07:54:50] martin_krafft: AnthonyTowns: i think the problem is the lack of direct belonging to the project
[07:54:51] JonathanWalther: martin_krafft: do not translators get credit for their work?
[07:55:00] JonathanWalther: martin_krafft: aren't their names in the translations and changelogs?
[07:55:09] BrandenRobinson: Do translators not deserve to be DDs, though?
[07:55:09] AndreasSchuldei: MatthewGarrett: no one is excuded. some exclude themselfs by giving up or by deciding to boycott the process.
[07:55:15] martin_krafft: they are not developers and in as such they are not specially recognised outside their individual contributions. my take...
[07:55:17] AnthonyTowns: martin_krafft: If translators want to be more involved in Debian and have a use for developer access, I'm all for that of course; even if that's just the ability to Vote [1] AJ ;)
[07:55:18] BrandenRobinson: Or people who just write/edit documentation?
[07:55:35] BrandenRobinson: s/just/"&"/
[07:55:39] JonathanWalther: martin_krafft: I personally would like to see our translators get a personal debian.org address; probably [email protected] instead of a top-level debian.org email address
[07:55:46] BrandenRobinson writes no small amount of documentation himself.
[07:55:58] martin_krafft: were are problems with giving out 200 new accounts to translators and other contributors?
[07:56:03] BrandenRobinson: JonathanWalther: SCD? Second-Class Developers?
[07:56:13] AngusLees: hell, non-DDs can even get packages uploaded fairly easily. how much more contribution do we want?
[07:56:13] BrandenRobinson: Tiered developership has ben proposed before.
[07:56:17] BrandenRobinson: I'm pretty uncomfortable with it.
[07:56:26] JonathanWalther: BrandenRobinson: a developer writes code. a translator is a "contributor"
[07:56:34] JonathanWalther: BrandenRobinson: maybe [email protected]
[07:56:42] JonathanWalther: BrandenRobinson: sort of like an honorary degree from a university
[07:56:44] BrandenRobinson: a lot of "developers" don't "write code". They maintain it.
[07:56:48] AnthonyTowns: martin_krafft: There's no problem, except that they have to pass trhough n-m just like everyone else. That's pretty time consuming for them, and comparitively little benefit for anyone, afaics
[07:56:59] MatthewGarrett: In some ways, I wonder if the Gnome foundation is a worthwhile model here - the membership requirements include you having made some contribution to Gnome, but don't require it to be in the form of code
[07:57:02] BrandenRobinson: I sure didn't do much code *writing* my first year or two as an xfree86 maintainer.
[07:57:05] JonathanWalther: BrandenRobinson: most developers CAN write or FIX the code they maintain, if called upon.
[07:57:10] AndreasSchuldei: martin_krafft: i discussed that with DAM. they think it is hard to draw a line
[07:57:18] martin_krafft: Would you, the candidates, be willing to go through NM again, anonymously, and report on your experiences afterwards?
[07:57:20] JonathanWalther: BrandenRobinson: I don't know any debian developers who can't at least program their way out of a paper bag.
[07:57:28] BrandenRobinson: JonathanWalther: Uh.
[07:57:31] MatthewGarrett: martin_krafft: Absolutely.
[07:57:35] JonathanWalther: martin_krafft: sure.
[07:57:45] BrandenRobinson: I know of Red Hat employees with their names on well-known software who can't code their way out of a paper bag :-P
[07:57:46] martin_krafft: anyone else?
[07:57:47] AnthonyTowns: Note that we've started getting non-packagers through n-m now days, and hopefully the "Must know debian/rules backwards" part of n-m won't be so crucial in the future.
[07:57:51] AndreasSchuldei: martin_krafft: the example they gave was: would a sponsor of machine and bandwidth also become a DD, with voting power?
[07:57:52] MatthewGarrett: However, it sounds like a bit of a logistical problem if it's going to be properly anonymous
[07:57:58] BrandenRobinson: but I have high standards, and I am being crotchety :)
[07:58:03] MatthewGarrett: (Faked up GPG keys, that sort of thing)
[07:58:06] AndreasSchuldei: martin_krafft: they are contributing, too.
[07:58:09] AngusLees: martin_krafft: of course
[07:58:28] BrandenRobinson: martin_krafft: Yes.
[07:58:28] martin_krafft: okay, we are nearing the end.
[07:58:33] martin_krafft: i have two more questions for you:
[07:58:52] martin_krafft: if you could not vote for yourself, whom would you vote and why? please make it short...
[07:58:53] AnthonyTowns imagines a pool of dormant piranha
[07:59:01] AndreasSchuldei: martin_krafft: i personally think that debian should try to find ways for artists, translators, fair-organizers etc to become voting members
[07:59:10] AngusLees: martin_krafft: heh. cool question
[07:59:29] BrandenRobinson would vote for Andreas. As a fellow leadership-team member, I trust him to take my proposals the most seriously.
[07:59:41] BrandenRobinson: However, as usual we have a pretty strong slate of candidates.
[07:59:44] MatthewGarrett: I fundamentally disagree with Anthony on the issue of the level of communication expected from teams, but other than that our views seem broadly aligned. So him.
[08:00:14] AngusLees: "JonathanWalther", because he probably has less of a chance at winning than I do :P
[08:00:19] AnthonyTowns: I think we have anonymous leadership ballots for a reason ;) I'm tossing up between Matthew and Andreas at the moment; but I haven't even been able to read people's answers to the first hour yet.
[08:00:25] martin_krafft: AngusLees: that was below the belt line.
[08:00:30] AndreasSchuldei: lol
[08:00:39] AngusLees: yes it was for such a public forum
[08:00:47] martin_krafft: others?
[08:00:49] AnthonyTowns: banhim!ban!ban!bannityban!
[08:00:51] AnthonyTowns: err
[08:00:54] JonathanWalther: AngusLees: fairly tame compared to what I've heard elsewhere.
[08:01:11] martin_krafft: we have one more community question:
[08:01:19] AngusLees: seriously, i'd probably say AJ because i'm nervous about the DPL team thing
[08:01:22] BrandenRobinson would point people to his rebuttal this year for more on the candidates.
[08:01:26] martin_krafft: what is the minimum level of activity we can expect from DDs?
[08:01:46] BrandenRobinson: martin_krafft: It's proportional to how much responsibility they've accepted.
[08:01:48] AndreasSchuldei: branden has the added "seriousness factor" of beeing on the dpl team. he does not underestimate the task
[08:01:52] JonathanWalther: martin_krafft: as much as they see fit to give.
[08:01:56] MatthewGarrett: An inactive DD isn't a problem. An obstructive one is.
[08:02:05] BrandenRobinson: If they maintain packages, I expect them to keep up with their bugs.
[08:02:18] BrandenRobinson: squish the RC ones, and fix as many non-upstream ones as possible.
[08:02:23] JonathanWalther: martin_krafft: most DD's are volunteers with real life jobs and careers.
[08:02:45] martin_krafft: alright... wrap it up...
[08:02:45] martin_krafft: In one sentence: what makes you a good project leader for Debian?
[08:02:50] MatthewGarrett: I don't think we have any right to demand people should work to a certain level, but if they accept responsibility without putting in sufficient effort then it should be socially acceptable for someone else to pick up that responsibility
[08:03:00] BrandenRobinson: In general, as Matthew noted, I don't think we truly notice inactive developers until they actual impede the progress of the project somehow.
[08:03:20] BrandenRobinson: And such impediments are easily noted, and recognized as problematic.
[08:03:28] martin_krafft: AndreasSchuldei, JonathanWalther: whom would you vote?
[08:04:05] martin_krafft: 2 minutes left.
[08:04:05] MatthewGarrett: I'm willing to upset some people in order to make things better for everyone else.
[08:04:09] AngusLees: martin_krafft: independence, personality, and relevant experience.
[08:04:31] AndreasSchuldei: oh i said BrandenRobinson
[08:04:32] AnthonyTowns: Uh, I think asking to sum up in one sentence is biassed against me and Branden. :)
[08:04:45] AndreasSchuldei: branden has the added "seriousness factor" of beeing on the dpl team. he does not underestimate the task.
[08:04:46] martin_krafft: keep it short.
[08:04:58] martin_krafft: AnthonyTowns: ^
[08:05:06] AnthonyTowns: (And that can my sentence; if you're deciding your vote on one sentence you're going on intuition, so good for you :)
[08:05:19] BrandenRobinson: I would make a good project leader for Debian because I've worked the hardest for it, I've consistently turned my attention to difficult problem areas, I combine an ability to work well with others with a resistance to intimidation, and I live and breathe the ideals of the Debian Project every day.
[08:05:54] BrandenRobinson: Oh, and I try to know when to laugh at myself. Like now, when I've gotten much too grandiose in my rhetoric :-P
[08:06:08] martin_krafft: JonathanWalther: ?
[08:06:22] JonathanWalther: I'd be a good DPL because I am FEARLESS, just like my namesake Jonathan, son of Shaul, who climbed up a cliff and singlehandedly attacked an entire Philistine fortress.
[08:06:24] AngusLees: BrandenRobinson: and i was just about to give you the the longest sentence award :P
[08:06:29] AnthonyTowns: see, branden couldn't do it either!
[08:06:32] AndreasSchuldei: i have started to work on the issues at hand a dpl should work on. i will continue to do so, if i get elected.
[08:06:33] AnthonyTowns: bias!
[08:06:38] AnthonyTowns: cancel the debate! reschedule!
[08:06:50] martin_krafft: okay, the debate is cancelled^Wover
[08:06:52] BrandenRobinson: AnthonyTowns: that last bit was an, uhm, footnote. yeah, yeah, that's the ticket!
[08:07:01] martin_krafft: Thank you all for participating
[08:07:12] martin_krafft: we can now move back to 300 posts/day on debian-vote
[08:07:13] MatthewGarrett: Thanks very much to the moderators. I know they must be about as exhausted as I am right now...
[08:07:18] BrandenRobinson: thanks for managing this logistical challenge, Martin and Helen.
[08:07:21] martin_krafft: I hope you enjoyed it half as much as I did (at least)
[08:07:24] AndreasSchuldei: thank you for your efford, helen and martin_krafft!
[08:07:27] helen: thanks to martin_krafft for working with me to run this :)
[08:07:30] martin_krafft: MatthewGarrett: i am ready to drop dead.
[08:07:32] JonathanWalther: tchau tchau!
[08:07:34] AngusLees: thanks. i'll try to stop my eyes from jumping around so much..
[08:07:46] AnthonyTowns: and ta for the awesome timing :)
[08:07:48] martin_krafft: candidates: you are invited to continue in -discuss
[08:08:10] martin_krafft: i will followup to -vote and -devel-announce
[08:08:14] helen: and thanks to helix, slef, Rhonda and dondelelcaro for helping with the -discuss channel and forwarding questions from there to us.