Re: QUESTIONNAIRE: Debian Project Leadership
El día 02 feb 2003, Branden Robinson escribía: [Reply-To is set. This message is written with the intention of soliciting private replies; however, if you want to reply to debian-vote as well, go ahead.] Hi folks, Won't you publish the results of the survey? Won't you run for DPL this year? (Deadline is today 00:00 UTC) -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] msg02413/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
On Thu, Feb 13, 2003 at 09:11:27AM +0100, Jose Carlos Garcia Sogo wrote: Won't you publish the results of the survey? Yes; please see: http://lists.debian.org/debian-vote/2003/debian-vote-200302/msg6.html Won't you run for DPL this year? (Deadline is today 00:00 UTC) Yes, please see: http://lists.debian.org/debian-vote/2003/debian-vote-200302/msg00047.html -- G. Branden Robinson| The Rehnquist Court has never Debian GNU/Linux | encountered a criminal statute it [EMAIL PROTECTED] | did not like. http://people.debian.org/~branden/ | -- John Dean msg02423/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
El día 02 feb 2003, Branden Robinson escribía: [Reply-To is set. This message is written with the intention of soliciting private replies; however, if you want to reply to debian-vote as well, go ahead.] Hi folks, Won't you publish the results of the survey? Won't you run for DPL this year? (Deadline is today 00:00 UTC) -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] pgpVxjxc9Zq0V.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 11:31:49AM -0500, Branden Robinson wrote: On Mon, Feb 03, 2003 at 02:44:37PM +0100, Martin Michlmayr wrote: Originally I planned to incorporate whatever feedback I received into my Platform, but now I'm less sure that's the right way to go. It is a bad idea. If you strongly disagree with opinions of a majority, your opinion should still be in your platform. -- Lionel msg02409/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 11:31:49AM -0500, Branden Robinson wrote: On Mon, Feb 03, 2003 at 02:44:37PM +0100, Martin Michlmayr wrote: Originally I planned to incorporate whatever feedback I received into my Platform, but now I'm less sure that's the right way to go. It is a bad idea. If you strongly disagree with opinions of a majority, your opinion should still be in your platform. -- Lionel pgp3xl9sWTYoW.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
overall, i'd probably vote for you if it wasn't for the fact that you're against having non-free in the debian ftp archives. in fact, i'd be tempted to vote for even knowing that you're against non-free, because the majority of developers would probably vote down any attempt to remove it. you make a lot of sense on most issues, but are stubbornly pig-headed and ignorant on some others :) you also did a good job at the thankless task of Treasurer. it's a crap job, but somebody has to do it, and you did it well with regular reports and updates and generally showed good organisational skills. IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). On Sun, Feb 02, 2003 at 05:58:40PM -0500, Branden Robinson wrote: ---CUT HERE- 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 3 ] attending trade shows and conferences [ 1 ] resolving disputes internal to the Project [ 2 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 6 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 4 ] appointing delegates per the Constitution [ 7 ] fixing bugs in packages that no one else will fix [ 9 ] cash fundraising [ 8 ] acquiring donations of bandwidth, equipment, and hosting [ 5 ] mentoring other developers Comments: 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 4 ] Bdale Garbee [ 4 ] Ben Collins [ 1 ] Bruce Perens [ 3 ] Ian Jackson [ 2 ] Ian Murdock [ 4 ] Wichert Akkerman Comments (why did you rank these people as you did?): Bruce got a lot of stuff done, he might have annoyed a lot of people from time to time but he was an extremely effective and capable leader. Ian M founded the project. Ian J got the constitution completed, but was pretty much non-existent apart from that. Wichert Ben didn't really achieve very much. Bdale hasn't done much more (a shame, i voted for him last time...and will probably vote for him again if he stands for re-election). i think this is mostly because all three have had a deliberately laid-back, hands-off policy. while this isn't entirely bad, i don't think that it is a good thing. a leader should have a vision, and inspire a sense of direction - even if the direction s/he inspires is no F-ing way, i'm going the opposite direction!. i.e. it's not enough to just sit on the fence, a leader has to make choices, and provoke action or reaction. 3. True or false: the New Maintainer system is still broken. True. Comments: the DAM is a bottleneck with effective veto power over who gets in. friends and friends of friends get approved immediately, as does the occasional famous or well-known developer who wants to join, but everybody else waits forever until they give up in disgust. actually, it's worse than a veto - he just ignores applications he doesn't like so that you don't even have a right of appeal - i.e. no decision has been made against you, so what are you whinging about? this has been an on-going problem (an open secret) for years that all DPLs so far have ignored - probably because they're scared it would blow the project apart to rock the boat and try to do something about the fact that beneath the veneer of a constitutional democracy, there is a not-so-secret cabal that really runs debian. but this is one pile of shit that needs to be stirred, no matter what comes of it. 4. True or false: we should place more emphasis on architectures that have a lot of users. true. Comments: pragmatism wins. we shouldn't stop anyone from working on unpopular arches if they want, though. 5. True or false: release management in this Project is a big problem. yes. Comments: debian needs to understand that it is an internet-based distribution, and that the current stable release schedule is inadequate. we need to make regular (monthly or bi-monthly)
Re: QUESTIONNAIRE: Debian Project Leadership
* Craig Sanders [EMAIL PROTECTED] [2003-02-05 21:20]: one day an inactive developer will become active again, and they shouldn't have to go through the whole New Maintainer process They generally don't have to go through NM again, just to submit their GPG keys. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
Craig Sanders [EMAIL PROTECTED] writes: IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). Agree completely. Bonus points for not leaving in a huff when things don't go your way:-) -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
On Wed, Feb 05, 2003 at 09:20:13PM +1100, Craig Sanders wrote: you also did a good job at the thankless task of Treasurer. it's a crap job, but somebody has to do it, and you did it well with regular reports and updates and generally showed good organisational skills. I appreciate the compliment but in my own opinion I have not lived up to my own expectations as SPI Treasurer. Anthony Towns can offer you quite a long list of my failings in that department should you care to ask him (and perhaps even if you don't). While I would object to any assertion that I'm a worse SPI Treasurer than Darren Benham, that's hardly a tough standard to beat. He set the bar so low only an earthworm could limbo under it. :-P IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). Again, I appreciate the compliments. I have been known to change my mind from time to time. Joey Hess has on at least one occassion kept me from doing something fairly stupid with XFree86, and, again, Anthony Towns knows of an instance where I changed my mind and ended up agreeing with him. He also wanted me to apologize for having ever felt differently, I think, but, well, you can't win 'em all. :) -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | msg02397/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
overall, i'd probably vote for you if it wasn't for the fact that you're against having non-free in the debian ftp archives. in fact, i'd be tempted to vote for even knowing that you're against non-free, because the majority of developers would probably vote down any attempt to remove it. you make a lot of sense on most issues, but are stubbornly pig-headed and ignorant on some others :) you also did a good job at the thankless task of Treasurer. it's a crap job, but somebody has to do it, and you did it well with regular reports and updates and generally showed good organisational skills. IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). On Sun, Feb 02, 2003 at 05:58:40PM -0500, Branden Robinson wrote: ---CUT HERE- 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 3 ] attending trade shows and conferences [ 1 ] resolving disputes internal to the Project [ 2 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 6 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 4 ] appointing delegates per the Constitution [ 7 ] fixing bugs in packages that no one else will fix [ 9 ] cash fundraising [ 8 ] acquiring donations of bandwidth, equipment, and hosting [ 5 ] mentoring other developers Comments: 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 4 ] Bdale Garbee [ 4 ] Ben Collins [ 1 ] Bruce Perens [ 3 ] Ian Jackson [ 2 ] Ian Murdock [ 4 ] Wichert Akkerman Comments (why did you rank these people as you did?): Bruce got a lot of stuff done, he might have annoyed a lot of people from time to time but he was an extremely effective and capable leader. Ian M founded the project. Ian J got the constitution completed, but was pretty much non-existent apart from that. Wichert Ben didn't really achieve very much. Bdale hasn't done much more (a shame, i voted for him last time...and will probably vote for him again if he stands for re-election). i think this is mostly because all three have had a deliberately laid-back, hands-off policy. while this isn't entirely bad, i don't think that it is a good thing. a leader should have a vision, and inspire a sense of direction - even if the direction s/he inspires is no F-ing way, i'm going the opposite direction!. i.e. it's not enough to just sit on the fence, a leader has to make choices, and provoke action or reaction. 3. True or false: the New Maintainer system is still broken. True. Comments: the DAM is a bottleneck with effective veto power over who gets in. friends and friends of friends get approved immediately, as does the occasional famous or well-known developer who wants to join, but everybody else waits forever until they give up in disgust. actually, it's worse than a veto - he just ignores applications he doesn't like so that you don't even have a right of appeal - i.e. no decision has been made against you, so what are you whinging about? this has been an on-going problem (an open secret) for years that all DPLs so far have ignored - probably because they're scared it would blow the project apart to rock the boat and try to do something about the fact that beneath the veneer of a constitutional democracy, there is a not-so-secret cabal that really runs debian. but this is one pile of shit that needs to be stirred, no matter what comes of it. 4. True or false: we should place more emphasis on architectures that have a lot of users. true. Comments: pragmatism wins. we shouldn't stop anyone from working on unpopular arches if they want, though. 5. True or false: release management in this Project is a big problem. yes. Comments: debian needs to understand that it is an internet-based distribution, and that the current stable release schedule is inadequate. we need to make regular (monthly or bi-monthly)
Re: QUESTIONNAIRE: Debian Project Leadership
* Craig Sanders [EMAIL PROTECTED] [2003-02-05 21:20]: one day an inactive developer will become active again, and they shouldn't have to go through the whole New Maintainer process They generally don't have to go through NM again, just to submit their GPG keys. -- Martin Michlmayr [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
Craig Sanders [EMAIL PROTECTED] writes: IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). Agree completely. Bonus points for not leaving in a huff when things don't go your way:-) -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/
Re: QUESTIONNAIRE: Debian Project Leadership
On Wed, Feb 05, 2003 at 09:20:13PM +1100, Craig Sanders wrote: you also did a good job at the thankless task of Treasurer. it's a crap job, but somebody has to do it, and you did it well with regular reports and updates and generally showed good organisational skills. I appreciate the compliment but in my own opinion I have not lived up to my own expectations as SPI Treasurer. Anthony Towns can offer you quite a long list of my failings in that department should you care to ask him (and perhaps even if you don't). While I would object to any assertion that I'm a worse SPI Treasurer than Darren Benham, that's hardly a tough standard to beat. He set the bar so low only an earthworm could limbo under it. :-P IMO, the fact that you're confrontational and opinionated is a good thing. the DPL should take a far more active and front-line role, and set the agenda (for action and for debate). Again, I appreciate the compliments. I have been known to change my mind from time to time. Joey Hess has on at least one occassion kept me from doing something fairly stupid with XFree86, and, again, Anthony Towns knows of an instance where I changed my mind and ended up agreeing with him. He also wanted me to apologize for having ever felt differently, I think, but, well, you can't win 'em all. :) -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | pgpKtSiTY3rl4.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
* Branden Robinson [EMAIL PROTECTED] [2003-02-02 17:58]: To that end, I am soliciting specific feedback by means of the questionnaire below. If you have perspectives and opinions you would like to communicate to me on the subjects addressed below, please reply to me privately and GPG-sign your message. I hope you can post a summary. I found many questions very interesting since you touch the question of the role of the DPL. I think it would be interesting for other candidates (and for the community as a whole) to hear what people expect from the DPL. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
On Sun, Feb 02, 2003 at 05:58:40PM -0500, Branden Robinson wrote: 1. Rank the following possible functions of Debian Project Leader in [snip - ranking system] [ 2 ] attending trade shows and conferences [ 1 ] resolving disputes internal to the Project [ 2 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 2 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 1 ] appointing delegates per the Constitution [ ] fixing bugs in packages that no one else will fix [ 3 ] cash fundraising [ 3 ] acquiring donations of bandwidth, equipment, and hosting [ 4 ] mentoring other developers Comments: Letting the CTTE/others resolve disputes where applicable, procedure definitions shouldn't be made by the DPL alone, but perhaps by a delegated committee (or such) 2. Rank the following past and present DPLs in order of greatest Comments (why did you rank these people as you did?): No experience with any DPLs except bdale... 3. True or false: the New Maintainer system is still broken. True 4. True or false: we should place more emphasis on architectures that have a lot of users. False Comments: Architectures with a lot of users (i386) already get a lot of attention. 5. True or false: release management in this Project is a big problem. True 6. True or false: there are too many inactive developers. True 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. True 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True Comments: .. partly, not all packages need this. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. False ... Comments: ... but Debian needs to remain a whole, and maintain a 'uniformity'(sp) 10. True or false: the Debian Project is biased against people who do not speak English fluently. True Comments: Not much compared to others, normal in the computer world. 11. True, false, or not applicable: there is not a lot that we can do about the Debian Project being biased against people who do not speak English fluently. True 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ ] build consensus among a small group [ X ] build consensus among the whole Project [ ] take unilateral action Or, where applicable, the people affected. 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left of the item. Leave blank items you consider as having no bearing on the role of DPL. [ A ] a high level of visibility as a regular developer on internal Project mailing lists [ A ] a high level of visibility as Project leader on internal Project mailing lists [ ] a high level of visibility in Debian-related IRC channels [ ] a preference for reading prepared statements over extemporaneous presentations at public gatherings [ L ] a preference for brokering agreement behind the scenes between conflicting parties [ A ] a preference for brokering agreement in public between conflicting parties [ A ] a sense of humor 14. True or false: the Debian Project Leader should attend as many trade shows and conferences as possible for him or her. False... Comments: ... unless he wants to. He should feel free to, of course. 15. True, false, or not applicable: Debian Project funds should be spent on getting the Debian Project Leader to as many trade shows and conferences as possible when corporate sponsorship is unavailable. False 16. True or false: the Technical Committee is operating as intended under the Constitution. False 17. True or false: a simple majority of voting Debian Developers should be sufficient to modify the Debian Free Software Guidelines. False Comments: Being the basis for the Debian project, I'd expect at least a qualified majority (I do not recall the size, but 3/4ths seems reasonable to me) 18. True or false: a simple majority of voting Debian Developers should be sufficient to modify the Debian Social Contract. False Comments: See above. 19. Should decisions about DFSG-compliance be made on the
Re: QUESTIONNAIRE: Debian Project Leadership
[Reposted to -vote, so interesting parties, such as other maybe-DPL-candidates can benefit from my answers, or have a good laugh at my ignorance, etc, etc, appropriate thing should be underlined. By the way, I would be interested in what other people answered, so please Cc the list too!] 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 3] attending trade shows and conferences [ 2] resolving disputes internal to the Project [ 1] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 2] drafting and implementing internal procedures for the Project that aren't already well-defined [ 2] appointing delegates per the Constitution [ 9] fixing bugs in packages that no one else will fix [ 9] cash fundraising [ 4] acquiring donations of bandwidth, equipment, and hosting [ 9] mentoring other developers 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 2] Bdale Garbee [ 2] Ben Collins [ ] Bruce Perens [ ] Ian Jackson [ ] Ian Murdock [ 1] Wichert Akkerman 3. True or false: the New Maintainer system is still broken. True. Well, this is not entirely true... There _are_ shortcomings, but it is not as broken as some seem to think, methinks. 4. True or false: we should place more emphasis on architectures that have a lot of users. False. 5. True or false: release management in this Project is a big problem. False. It is a problem, just not a big one, IMHO. 6. True or false: there are too many inactive developers. True. 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. True. But they should not get dropped, as in userdel, but their accounts should be deactivated. Like an Active: [True|False] field in LDAP or the like. 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True. Provided that it is not mandatory. Co-maintainership already exists, and more and more people seem to realise its benefits. On the other hand, there are packages for which a group to maintain is plain overkill (think tama :). 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. False. Policy is not a beating stick, and BTS-tennis sucks. If a maintainer does not want to cooperate despite the fact he is clearly doing his job wrong, there is the TC, which should handle the case, methinks. ..or public humiliating on -devel or another appropriate mailinglist might have a good effect too :] 10. True or false: the Debian Project is biased against people who do not speak English fluently. False. 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ X] build consensus among a small group [ ] build consensus among the whole Project [ ] take unilateral action 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left of the item. Leave blank items you consider as having no bearing on the role of DPL. [ A] a high level of visibility as a regular developer on internal Project mailing lists [ L] a high level of visibility as Project leader on internal Project mailing lists [ A] a high level of visibility in Debian-related IRC channels [ A] a preference for reading prepared statements over extemporaneous presentations at public gatherings [ L] a preference for brokering agreement behind the scenes between conflicting parties [ L] a preference for brokering
Re: QUESTIONNAIRE: Debian Project Leadership
Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin * Branden Robinson [EMAIL PROTECTED] [2003-02-02 Martin 17:58]: To that end, I am soliciting specific feedback by means of the questionnaire below. If you have perspectives and opinions you would like to communicate to me on the subjects addressed below, please reply to me privately and GPG-sign your message. Martin I hope you can post a summary. I found many questions Martin very interesting since you touch the question of the role Martin of the DPL. I think it would be interesting for other Martin candidates (and for the community as a whole) to hear what Martin people expect from the DPL. I agree with this. I'd also like to see other candidates publically answer a version of this questionnaire that had the Branden-specific bits removed. I found answering the questionnaire a thought-provoking experience. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 02:44:37PM +0100, Martin Michlmayr wrote: I hope you can post a summary. I found many questions very interesting since you touch the question of the role of the DPL. I think it would be interesting for other candidates (and for the community as a whole) to hear what people expect from the DPL. It is my intention to post a summary. I didn't address this point in the original mail because I wasn't even sure very many people would reply. But so far response has been very positive (in that people are responding, and offering a lot in the way of comments) so I am hopeful that over the coming week or so I will eventually gather a fairly decent sample. Originally I planned to incorporate whatever feedback I received into my Platform, but now I'm less sure that's the right way to go. I think we should be having discussions about some of the issues I raised in the questionnaire (note that -project is the proper list for such things), especially since there are some interesting differences and confluences of opinion in the Project that I wasn't quite expecting to see. One hazard I can see with incorporating a summary into my Platform (AlGoreshould I decide to run/AlGore) is that people might incorrectly extrapolate from my personal positions to a majority of the questionnaire feedback. That would be a reckless assumption because I reserve the right to disagree with the majority of Debian Developers. :) (If I do so with respect to many issues, though, it's probably not worth running for DPL.) The hazard with not incorporating a summary into my Platform is that people may assume that I'm trying to give the impression that the questionnaire feedback will have had no impact on it, which would of course be perceived as disingenuous and negative. Of *course* the feedback is going to have an influence on my thinking. That's the point. Anyway, one way or the other, yes; you'll have your summary. I am going to try to resist the temptation to perform much in the way of quantitative and statistical analysis, because 1) I'm not experienced with such matters and 2) I strongly suspect that my survey is going to have some skew problems with regards to sampling. I am probably more likely to get responses from people who are neutral to sympathetic to the notion of my DPL candidacy, and less likely to get responses from my potential opponents or people who are very uncomfortable with the thought of me being elected to DPL. After all, the latter group, if it exists, won't want to give me ammunition with which to make myself a better candidate, because they'd rather I lose. :) Still, I'd welcome an earnest response even from someone who is outright hostile to me. If such a person wants to wait until after the nomination period or the election, that's fine. The most important thing is that we as a Project have the self-knowledge we need to make good decisions in the future. With luck, my little[1] questionnaire will be a modest step in that direction. [1] well, there is some dispute on that very issue -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | msg02381/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
* Branden Robinson ([EMAIL PROTECTED]) [030203 17:05a: I find your questions relevant to the overall understanding of the debian project and the position of the DPL. I wish we would see discussion on this and i propose to discuss this at debconf in some form or an other in great(er) depth. 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 60 ] attending trade shows and conferences [ 10 ] resolving disputes internal to the Project [ 51 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 3 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 50 ] appointing delegates per the Constitution [ 1000 ] fixing bugs in packages that no one else will fix [ 53 ] cash fundraising [ 52 ] acquiring donations of bandwidth, equipment, and hosting [ 1 ] mentoring other developers Comments: I try to reflect my opinion that your choices represent totally differnt classes of activities. I see mentoring as any leaders first goal, and since one person allone scales realy badly in the context of debian, the dpl should focus on sub-leaders (which are not formally defined yet), and who in turn should mentor and coach their sheep and subleaders. what you left out as an option and what i would have voted for as #2 is develop and realize visons and modifications to debian as a whole to keep the project on track and keep it fit to meet coming challanges. 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 20 ] Bdale Garbee [ 20 ] Ben Collins [ 3 ] Bruce Perens [ 2 ] Ian Jackson [ 1 ] Ian Murdock [ 10 ] Wichert Akkerman Comments (why did you rank these people as you did?): 1- he founded the project, 2- he wrote the constitution, 3- he wrote the DFSG these three created something lasting for debian, and moved it a good deal forward by doing so. again i try to express different classes of leadership. the letter ones seem(ed) to excell by passivity. 3. True or false: the New Maintainer system is still broken. Comments: neither. it is allready improved a good deal, but can become even more integrated into the debian community. 4. True or false: we should place more emphasis on architectures that have a lot of users. true Comments: 5. True or false: release management in this Project is a big problem. false Comments: Debian is of limited value to companies, a gradual improvement could make a real difference here. 6. True or false: there are too many inactive developers. true Comments: 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. true Comments: 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. very much true Comments: i think there should form smaller groups of developers with common interests, and if possible in local/closer proximity (and/or irc) maintaining a little pool of packages and meet regularly (increase web of trust, decrease developer flux). New maintainers can look at different smaller groups and start working gradually. the group could recomment people after half a year or year to become full-blood developers. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. true Comments: 10. True or false: the Debian Project is biased against people who do not speak English fluently. true. Especially you, branden seem to look down on people who make errors in their english, ignoring the fact that *they* are making the effort to communicate in a foreign language, which you can not even begin to understand. Comments: My above idea of local
Re: QUESTIONNAIRE: Debian Project Leadership
Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. You realize that interpreting what is and is not free according to the DFSG is not formally a question of law? And that, so long as the ftpmasters take the advice dispensed on debian-legal, you don't really get a choice wrt listening to debian-legal as regards the operations of Debian? -- Steve Langasek postmodern programmer msg02384/pgp0.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. I have an almost opposite opinion: if a license cannot be understood without paid legal advice, then it is not Free. There's no point in software licenses that cannot be understood and applied by programmers. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. You realize that interpreting what is and is not free according to the DFSG is not formally a question of law? Doesn't it really come down to deciding if, under a given license, you can or cannot do certain things with the software? That would require interpretation of the license, something that a professional would be much more qualified to undertake. -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ---CUT HERE- 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 5 ] attending trade shows and conferences [ 2 ] resolving disputes internal to the Project [ 4 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 3 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 1 ] appointing delegates per the Constitution [ ] fixing bugs in packages that no one else will fix [ 6 ] cash fundraising [ ] acquiring donations of bandwidth, equipment, and hosting [ ] mentoring other developers Comments: 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 2 ] Bdale Garbee [ 2 ] Ben Collins [ ] Bruce Perens [ ] Ian Jackson [ ] Ian Murdock [ 1 ] Wichert Akkerman Comments (why did you rank these people as you did?): 3. True or false: the New Maintainer system is still broken. True Comments: We're still having flames about the brokenness of the New Maintainer System. So I think it's still broken. It might just be a backlog or bad communication about changes to the better. I havn't really read the discussions. 4. True or false: we should place more emphasis on architectures that have a lot of users. False. Comments: I believe Debian has techncal gains from having to support as much architectures as posible. We might want to review the idea about releasing all architectures at the same time though. 5. True or false: release management in this Project is a big problem. False Comments: I would like to see shorter release cycles with no infrastructual changes in Debian. 6. True or false: there are too many inactive developers. False Comments: The only problem with truly inactive developers is if we fails to meet some quorum---but this is more a problem with the constitution (IMHO). [ Another problem would be if inactive developers used their developership to become contributing members in SPI---but this is not our (Debian's) problem. ] Quite another problem is that there might be to many people discussing problems but to less solving problems. I don't think this is solvable by revoking developerships. 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. N/A Comments: 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True (I guess) Comments: I think there are a lot of packages where it wouldn't make sense but otherwise true. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. I have no idea. Comments: 10. True or false: the Debian Project is biased against people who do not speak English fluently. True Comments: A project where almost all communication is based on a single language would be biased against those not speaking/writing this language fluently. But I thinks a cure whould be worse than the disease. 11. True, false, or not applicable: there is not a lot that we can do about the Debian Project being biased against people who do not speak English fluently. True Comments: 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ ] build consensus among a small group [ X ] build consensus among the whole Project [ ] take unilateral action 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left
Re: QUESTIONNAIRE: Debian Project Leadership
* Branden Robinson [EMAIL PROTECTED] [2003-02-02 17:58]: To that end, I am soliciting specific feedback by means of the questionnaire below. If you have perspectives and opinions you would like to communicate to me on the subjects addressed below, please reply to me privately and GPG-sign your message. I hope you can post a summary. I found many questions very interesting since you touch the question of the role of the DPL. I think it would be interesting for other candidates (and for the community as a whole) to hear what people expect from the DPL. -- Martin Michlmayr [EMAIL PROTECTED]
Re: QUESTIONNAIRE: Debian Project Leadership
On Sun, Feb 02, 2003 at 05:58:40PM -0500, Branden Robinson wrote: 1. Rank the following possible functions of Debian Project Leader in [snip - ranking system] [ 2 ] attending trade shows and conferences [ 1 ] resolving disputes internal to the Project [ 2 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 2 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 1 ] appointing delegates per the Constitution [ ] fixing bugs in packages that no one else will fix [ 3 ] cash fundraising [ 3 ] acquiring donations of bandwidth, equipment, and hosting [ 4 ] mentoring other developers Comments: Letting the CTTE/others resolve disputes where applicable, procedure definitions shouldn't be made by the DPL alone, but perhaps by a delegated committee (or such) 2. Rank the following past and present DPLs in order of greatest Comments (why did you rank these people as you did?): No experience with any DPLs except bdale... 3. True or false: the New Maintainer system is still broken. True 4. True or false: we should place more emphasis on architectures that have a lot of users. False Comments: Architectures with a lot of users (i386) already get a lot of attention. 5. True or false: release management in this Project is a big problem. True 6. True or false: there are too many inactive developers. True 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. True 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True Comments: .. partly, not all packages need this. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. False ... Comments: ... but Debian needs to remain a whole, and maintain a 'uniformity'(sp) 10. True or false: the Debian Project is biased against people who do not speak English fluently. True Comments: Not much compared to others, normal in the computer world. 11. True, false, or not applicable: there is not a lot that we can do about the Debian Project being biased against people who do not speak English fluently. True 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ ] build consensus among a small group [ X ] build consensus among the whole Project [ ] take unilateral action Or, where applicable, the people affected. 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left of the item. Leave blank items you consider as having no bearing on the role of DPL. [ A ] a high level of visibility as a regular developer on internal Project mailing lists [ A ] a high level of visibility as Project leader on internal Project mailing lists [ ] a high level of visibility in Debian-related IRC channels [ ] a preference for reading prepared statements over extemporaneous presentations at public gatherings [ L ] a preference for brokering agreement behind the scenes between conflicting parties [ A ] a preference for brokering agreement in public between conflicting parties [ A ] a sense of humor 14. True or false: the Debian Project Leader should attend as many trade shows and conferences as possible for him or her. False... Comments: ... unless he wants to. He should feel free to, of course. 15. True, false, or not applicable: Debian Project funds should be spent on getting the Debian Project Leader to as many trade shows and conferences as possible when corporate sponsorship is unavailable. False 16. True or false: the Technical Committee is operating as intended under the Constitution. False 17. True or false: a simple majority of voting Debian Developers should be sufficient to modify the Debian Free Software Guidelines. False Comments: Being the basis for the Debian project, I'd expect at least a qualified majority (I do not recall the size, but 3/4ths seems reasonable to me) 18. True or false: a simple majority of voting Debian Developers should be sufficient to modify the Debian Social Contract. False Comments: See above. 19. Should decisions about DFSG-compliance be made on the
Re: QUESTIONNAIRE: Debian Project Leadership
[Reposted to -vote, so interesting parties, such as other maybe-DPL-candidates can benefit from my answers, or have a good laugh at my ignorance, etc, etc, appropriate thing should be underlined. By the way, I would be interested in what other people answered, so please Cc the list too!] 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 3] attending trade shows and conferences [ 2] resolving disputes internal to the Project [ 1] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 2] drafting and implementing internal procedures for the Project that aren't already well-defined [ 2] appointing delegates per the Constitution [ 9] fixing bugs in packages that no one else will fix [ 9] cash fundraising [ 4] acquiring donations of bandwidth, equipment, and hosting [ 9] mentoring other developers 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 2] Bdale Garbee [ 2] Ben Collins [ ] Bruce Perens [ ] Ian Jackson [ ] Ian Murdock [ 1] Wichert Akkerman 3. True or false: the New Maintainer system is still broken. True. Well, this is not entirely true... There _are_ shortcomings, but it is not as broken as some seem to think, methinks. 4. True or false: we should place more emphasis on architectures that have a lot of users. False. 5. True or false: release management in this Project is a big problem. False. It is a problem, just not a big one, IMHO. 6. True or false: there are too many inactive developers. True. 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. True. But they should not get dropped, as in userdel, but their accounts should be deactivated. Like an Active: [True|False] field in LDAP or the like. 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True. Provided that it is not mandatory. Co-maintainership already exists, and more and more people seem to realise its benefits. On the other hand, there are packages for which a group to maintain is plain overkill (think tama :). 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. False. Policy is not a beating stick, and BTS-tennis sucks. If a maintainer does not want to cooperate despite the fact he is clearly doing his job wrong, there is the TC, which should handle the case, methinks. ..or public humiliating on -devel or another appropriate mailinglist might have a good effect too :] 10. True or false: the Debian Project is biased against people who do not speak English fluently. False. 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ X] build consensus among a small group [ ] build consensus among the whole Project [ ] take unilateral action 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left of the item. Leave blank items you consider as having no bearing on the role of DPL. [ A] a high level of visibility as a regular developer on internal Project mailing lists [ L] a high level of visibility as Project leader on internal Project mailing lists [ A] a high level of visibility in Debian-related IRC channels [ A] a preference for reading prepared statements over extemporaneous presentations at public gatherings [ L] a preference for brokering agreement behind the scenes between conflicting parties [ L] a preference for brokering
Re: QUESTIONNAIRE: Debian Project Leadership
Martin == Martin Michlmayr [EMAIL PROTECTED] writes: Martin * Branden Robinson [EMAIL PROTECTED] [2003-02-02 Martin 17:58]: To that end, I am soliciting specific feedback by means of the questionnaire below. If you have perspectives and opinions you would like to communicate to me on the subjects addressed below, please reply to me privately and GPG-sign your message. Martin I hope you can post a summary. I found many questions Martin very interesting since you touch the question of the role Martin of the DPL. I think it would be interesting for other Martin candidates (and for the community as a whole) to hear what Martin people expect from the DPL. I agree with this. I'd also like to see other candidates publically answer a version of this questionnaire that had the Branden-specific bits removed. I found answering the questionnaire a thought-provoking experience.
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 02:44:37PM +0100, Martin Michlmayr wrote: I hope you can post a summary. I found many questions very interesting since you touch the question of the role of the DPL. I think it would be interesting for other candidates (and for the community as a whole) to hear what people expect from the DPL. It is my intention to post a summary. I didn't address this point in the original mail because I wasn't even sure very many people would reply. But so far response has been very positive (in that people are responding, and offering a lot in the way of comments) so I am hopeful that over the coming week or so I will eventually gather a fairly decent sample. Originally I planned to incorporate whatever feedback I received into my Platform, but now I'm less sure that's the right way to go. I think we should be having discussions about some of the issues I raised in the questionnaire (note that -project is the proper list for such things), especially since there are some interesting differences and confluences of opinion in the Project that I wasn't quite expecting to see. One hazard I can see with incorporating a summary into my Platform (AlGoreshould I decide to run/AlGore) is that people might incorrectly extrapolate from my personal positions to a majority of the questionnaire feedback. That would be a reckless assumption because I reserve the right to disagree with the majority of Debian Developers. :) (If I do so with respect to many issues, though, it's probably not worth running for DPL.) The hazard with not incorporating a summary into my Platform is that people may assume that I'm trying to give the impression that the questionnaire feedback will have had no impact on it, which would of course be perceived as disingenuous and negative. Of *course* the feedback is going to have an influence on my thinking. That's the point. Anyway, one way or the other, yes; you'll have your summary. I am going to try to resist the temptation to perform much in the way of quantitative and statistical analysis, because 1) I'm not experienced with such matters and 2) I strongly suspect that my survey is going to have some skew problems with regards to sampling. I am probably more likely to get responses from people who are neutral to sympathetic to the notion of my DPL candidacy, and less likely to get responses from my potential opponents or people who are very uncomfortable with the thought of me being elected to DPL. After all, the latter group, if it exists, won't want to give me ammunition with which to make myself a better candidate, because they'd rather I lose. :) Still, I'd welcome an earnest response even from someone who is outright hostile to me. If such a person wants to wait until after the nomination period or the election, that's fine. The most important thing is that we as a Project have the self-knowledge we need to make good decisions in the future. With luck, my little[1] questionnaire will be a modest step in that direction. [1] well, there is some dispute on that very issue -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgpkrUUp7f01S.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
* Branden Robinson ([EMAIL PROTECTED]) [030203 17:05a: I find your questions relevant to the overall understanding of the debian project and the position of the DPL. I wish we would see discussion on this and i propose to discuss this at debconf in some form or an other in great(er) depth. 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 60 ] attending trade shows and conferences [ 10 ] resolving disputes internal to the Project [ 51 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 3 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 50 ] appointing delegates per the Constitution [ 1000 ] fixing bugs in packages that no one else will fix [ 53 ] cash fundraising [ 52 ] acquiring donations of bandwidth, equipment, and hosting [ 1 ] mentoring other developers Comments: I try to reflect my opinion that your choices represent totally differnt classes of activities. I see mentoring as any leaders first goal, and since one person allone scales realy badly in the context of debian, the dpl should focus on sub-leaders (which are not formally defined yet), and who in turn should mentor and coach their sheep and subleaders. what you left out as an option and what i would have voted for as #2 is develop and realize visons and modifications to debian as a whole to keep the project on track and keep it fit to meet coming challanges. 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 20 ] Bdale Garbee [ 20 ] Ben Collins [ 3 ] Bruce Perens [ 2 ] Ian Jackson [ 1 ] Ian Murdock [ 10 ] Wichert Akkerman Comments (why did you rank these people as you did?): 1- he founded the project, 2- he wrote the constitution, 3- he wrote the DFSG these three created something lasting for debian, and moved it a good deal forward by doing so. again i try to express different classes of leadership. the letter ones seem(ed) to excell by passivity. 3. True or false: the New Maintainer system is still broken. Comments: neither. it is allready improved a good deal, but can become even more integrated into the debian community. 4. True or false: we should place more emphasis on architectures that have a lot of users. true Comments: 5. True or false: release management in this Project is a big problem. false Comments: Debian is of limited value to companies, a gradual improvement could make a real difference here. 6. True or false: there are too many inactive developers. true Comments: 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. true Comments: 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. very much true Comments: i think there should form smaller groups of developers with common interests, and if possible in local/closer proximity (and/or irc) maintaining a little pool of packages and meet regularly (increase web of trust, decrease developer flux). New maintainers can look at different smaller groups and start working gradually. the group could recomment people after half a year or year to become full-blood developers. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. true Comments: 10. True or false: the Debian Project is biased against people who do not speak English fluently. true. Especially you, branden seem to look down on people who make errors in their english, ignoring the fact that *they* are making the effort to communicate in a foreign language, which you can not even begin to understand. Comments: My above idea of local
Re: QUESTIONNAIRE: Debian Project Leadership
Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. You realize that interpreting what is and is not free according to the DFSG is not formally a question of law? And that, so long as the ftpmasters take the advice dispensed on debian-legal, you don't really get a choice wrt listening to debian-legal as regards the operations of Debian? -- Steve Langasek postmodern programmer pgpnRG7kBfFki.pgp Description: PGP signature
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. I have an almost opposite opinion: if a license cannot be understood without paid legal advice, then it is not Free. There's no point in software licenses that cannot be understood and applied by programmers. Richard Braakman
Re: QUESTIONNAIRE: Debian Project Leadership
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Feb 03, 2003 at 10:05:37AM -0800, David N. Welton wrote: Andreas Schuldei [EMAIL PROTECTED] writes: 19. Should decisions about DFSG-compliance be made on the debian-legal list, or should we have a more formalized body for making such decisions? debian legal has the experts, they should know and feel responsible and decide Since when are they 'experts'? Frankly, I want to see some law degrees, or the equivalent work experience in the legal field, before I start listening to most of those people. You realize that interpreting what is and is not free according to the DFSG is not formally a question of law? Doesn't it really come down to deciding if, under a given license, you can or cannot do certain things with the software? That would require interpretation of the license, something that a professional would be much more qualified to undertake. -- David N. Welton Consulting: http://www.dedasys.com/ Personal: http://www.dedasys.com/davidw/ Free Software: http://www.dedasys.com/freesoftware/ Apache Tcl: http://tcl.apache.org/
Re: QUESTIONNAIRE: Debian Project Leadership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ---CUT HERE- 1. Rank the following possible functions of Debian Project Leader in order from most important to least important by placing a digit between the brackets to the left of the item. Use 1 as the most important item(s), with larger integers reflecting less important items. You can give two items the same number to reflect a tie. Leave blank items you consider unimportant or not appropriate for the role of DPL. [ 5 ] attending trade shows and conferences [ 2 ] resolving disputes internal to the Project [ 4 ] representing Debian to trade associations, businesses and NGOs (non-governmental organizations) [ 3 ] drafting and implementing internal procedures for the Project that aren't already well-defined [ 1 ] appointing delegates per the Constitution [ ] fixing bugs in packages that no one else will fix [ 6 ] cash fundraising [ ] acquiring donations of bandwidth, equipment, and hosting [ ] mentoring other developers Comments: 2. Rank the following past and present DPLs in order of greatest effectiveness to least effectiveness (use 1 for the most effective leader(s)). You need not have been a Debian Developer during the term a Leader to express an opinion here (though knowing who they are and what they did as DPL definitely helps). You can give two people the same number to reflect a tie. Leave blank people about whom you feel you cannot form an opinion. [ 2 ] Bdale Garbee [ 2 ] Ben Collins [ ] Bruce Perens [ ] Ian Jackson [ ] Ian Murdock [ 1 ] Wichert Akkerman Comments (why did you rank these people as you did?): 3. True or false: the New Maintainer system is still broken. True Comments: We're still having flames about the brokenness of the New Maintainer System. So I think it's still broken. It might just be a backlog or bad communication about changes to the better. I havn't really read the discussions. 4. True or false: we should place more emphasis on architectures that have a lot of users. False. Comments: I believe Debian has techncal gains from having to support as much architectures as posible. We might want to review the idea about releasing all architectures at the same time though. 5. True or false: release management in this Project is a big problem. False Comments: I would like to see shorter release cycles with no infrastructual changes in Debian. 6. True or false: there are too many inactive developers. False Comments: The only problem with truly inactive developers is if we fails to meet some quorum---but this is more a problem with the constitution (IMHO). [ Another problem would be if inactive developers used their developership to become contributing members in SPI---but this is not our (Debian's) problem. ] Quite another problem is that there might be to many people discussing problems but to less solving problems. I don't think this is solvable by revoking developerships. 7. True, false, or not applicable: the Debian Project Leader should see to it that inactive developers are placed on notice that they will be dropped from the Project, and then if they do not become active, expire them from our ranks. N/A Comments: 8. True or false: the concept of one maintainer per package is outmoded, and packages should be maintained as more of a group or communal process. True (I guess) Comments: I think there are a lot of packages where it wouldn't make sense but otherwise true. 9. True or false: the Debian Policy Manual and Bug Tracking System should be used together as a stick with which to compel uncooperative maintainers to change the way they maintain their packages. I have no idea. Comments: 10. True or false: the Debian Project is biased against people who do not speak English fluently. True Comments: A project where almost all communication is based on a single language would be biased against those not speaking/writing this language fluently. But I thinks a cure whould be worse than the disease. 11. True, false, or not applicable: there is not a lot that we can do about the Debian Project being biased against people who do not speak English fluently. True Comments: 12. Should the DPL attempt to build consensus among a small group of experts or among the whole project before taking a major action, or should he go it alone? Mark one. [ ] build consensus among a small group [ X ] build consensus among the whole Project [ ] take unilateral action 13. Rank the following possible traits of Debian Project Leader as assets (with an A) or liabilities (with an L) between the brackets to the left
Re: QUESTIONNAIRE: Debian Project Leadership
On Mon, Feb 03, 2003 at 06:32:45PM +0100, Andreas Schuldei wrote: * Branden Robinson ([EMAIL PROTECTED]) [030203 17:05a: I find your questions relevant to the overall understanding of the debian project and the position of the DPL. Ugh. We have a three week campaigning period. Can we leave this 'til then, rather than dragging the flamewar out even more? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
