Re: Questions for candidates -- Debian's Organizational Structure
On Thu, Mar 04, 2004 at 07:49:10AM +0100, Martin Schulze wrote: Out of curiosity, do you plan to only formally make the people working in these departments delegates? I plan to extend formal delegate status to everyone currently serving in those roles. It is possible that one or more of those people would be unwilling to accept formal delegate status in one or more of those positions. In that case, I will try to find out why, report my findings to the developers, and solicit advice. If there is someone in that list who appears to no longer be active with the Project, or who refuses to get back to me regarding the delegation issue specifically, I will consult with other members of the same team (where applicable), report my findings to developers, and solicit advice. If not, do you plan to fill the roles with different people than today? I do not intend to ask for anyone's resignation without offering them formal delegate status first (and not afterwards, either, without some buy-in from the developers). In summary: 1) I have no plans for a purge. 2) I am not going to make any single individual a campaign issue[1]. Do you believe the Tech Committee is effective in its role for the project? I suspect not; as I stated in my platform[2]: I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized. I wonder why reviving the CTTE has to wait until you become the project leader. The Debian Project Leader is empowered by clause 5.1.6 of the Debian Constitution[2] to seat and remove members of the Technical Committee. The Project Leader may: [...] Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) I cannot exercise this power unless I am elected. The current DPL can, if he chooses. Furthermore, if it is the case that the Technical Committee is a dysfunctional or ineffective body, the Constitution should be amended to dissolve it. The DPL has augemented power to initiate and manage General Resolutions (Constitution 4.2.1, 5.1.5, 5.1.7, and 5.1.8). If the Technical Committee should be replaced -- and I do not presume that to be the case -- then the Project Leader has the authority to inaugurate a new body accountable to him through delegation (Constitution 5.1.2), or by instantiating an independent group throu the General Resolution process (see above). I do not act on these matters at present because I perceive them as the Project Leader's prerogative. [1] With what should be the understood exception of the other candidates running for DPL; we almost have to discuss each other to some extent for purposes of contrast. Neverthess I have no intentions of divesting Martin Michlmayr or Gergely Nagy of any responsibilities they may currently possess as a result of my election as DPL, should that happen -- apart from the office of DPL itself, of course. [2] http://www.debian.org/devel/constitution -- G. Branden Robinson| There's no trick to being a Debian GNU/Linux | humorist when you have the whole [EMAIL PROTECTED] | government working for you. http://people.debian.org/~branden/ | -- Will Rogers signature.asc Description: Digital signature
Re: Questions for candidates -- Debian's Organizational Structure
* Branden Robinson [EMAIL PROTECTED] [2004-03-04 06:47]: I wonder why reviving the CTTE has to wait until you become the project leader. The Debian Project Leader is empowered by clause 5.1.6 of the Debian Constitution[2] to seat and remove members of the Technical Committee. The Project Leader may: [...] Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) I cannot exercise this power unless I am elected. Your attitude seems to suggest that nothing in the project can be achieved without explicit authority given by the constitution. This is in contrast to how I perceive how the project works. I see that much authority is gained through work; for example, I started looking for inactive maintainers on my own, without the backing of the constitution or the DPL, and now I am perceived as the authority in this area. There are many other examples. In the specific case of the Technical Committee, you could have: - raised your concerns on -devel or the -tech-ctte mailing list - raised your concerns with the DPL - started a GR and possibly others. While you cannot exercise the power of clause 5.1.6 without being DPL, there seem to be other ways to approach this problem. -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
Branden Robinson wrote: I think the following roles should be formally delegated: FTP Archives Release Manager Release Manager for stable Bug Tracking System Mailing Lists Administration Mailing Lists Archives New Maintainers Front Desk Developer Accounts Managers Keyring Maintainers Security Team [3] Web Pages [3] System Administration LDAP Developer Directory Administrator DNS Maintainer (hostmaster) Hardware Donations Coordinator Accountant It's possible some of the above roles should be condensed into one. Out of curiosity, do you plan to only formally make the people working in these departments delegates? If not, do you plan to fill the roles with different people than today? Do you believe the Tech Committee is effective in its role for the project? I suspect not; as I stated in my platform[2]: I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized. I wonder why reviving the CTTE has to wait until you become the project leader. Regards, Joey -- Linux - the choice of a GNU generation.
Re: Questions for candidates -- Debian's Organizational Structure
On Thu, Mar 04, 2004 at 07:49:10AM +0100, Martin Schulze wrote: Out of curiosity, do you plan to only formally make the people working in these departments delegates? I plan to extend formal delegate status to everyone currently serving in those roles. It is possible that one or more of those people would be unwilling to accept formal delegate status in one or more of those positions. In that case, I will try to find out why, report my findings to the developers, and solicit advice. If there is someone in that list who appears to no longer be active with the Project, or who refuses to get back to me regarding the delegation issue specifically, I will consult with other members of the same team (where applicable), report my findings to developers, and solicit advice. If not, do you plan to fill the roles with different people than today? I do not intend to ask for anyone's resignation without offering them formal delegate status first (and not afterwards, either, without some buy-in from the developers). In summary: 1) I have no plans for a purge. 2) I am not going to make any single individual a campaign issue[1]. Do you believe the Tech Committee is effective in its role for the project? I suspect not; as I stated in my platform[2]: I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized. I wonder why reviving the CTTE has to wait until you become the project leader. The Debian Project Leader is empowered by clause 5.1.6 of the Debian Constitution[2] to seat and remove members of the Technical Committee. The Project Leader may: [...] Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) I cannot exercise this power unless I am elected. The current DPL can, if he chooses. Furthermore, if it is the case that the Technical Committee is a dysfunctional or ineffective body, the Constitution should be amended to dissolve it. The DPL has augemented power to initiate and manage General Resolutions (Constitution 4.2.1, 5.1.5, 5.1.7, and 5.1.8). If the Technical Committee should be replaced -- and I do not presume that to be the case -- then the Project Leader has the authority to inaugurate a new body accountable to him through delegation (Constitution 5.1.2), or by instantiating an independent group throu the General Resolution process (see above). I do not act on these matters at present because I perceive them as the Project Leader's prerogative. [1] With what should be the understood exception of the other candidates running for DPL; we almost have to discuss each other to some extent for purposes of contrast. Neverthess I have no intentions of divesting Martin Michlmayr or Gergely Nagy of any responsibilities they may currently possess as a result of my election as DPL, should that happen -- apart from the office of DPL itself, of course. [2] http://www.debian.org/devel/constitution -- G. Branden Robinson| There's no trick to being a Debian GNU/Linux | humorist when you have the whole [EMAIL PROTECTED] | government working for you. http://people.debian.org/~branden/ | -- Will Rogers signature.asc Description: Digital signature
Re: Questions for candidates -- Debian's Organizational Structure
Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? None of them, because none includes my tama, who is an aspiring conqueror, a wanna-be ruler of the world (who wants to start with Debian for some strange reason... maybe because Debian is the only place it is packaged). The obvious change is to alter our Constitution to let a tamagotchi be our DPL, and let Yamm do his duty. Do you believe the Tech Committee is effective in its role for the project? They didn't criticise tama yet, so yes, they're probably doing everything all right. -- Gergelybrush Nagywood, on behalf of World Dictator Yamm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
* Pascal Hakim [EMAIL PROTECTED] [2004-03-03 16:48]: Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? Before answering this mail, I talked to Pasc on IRC for a while. Pasc was added as a listmaster during my term as DPL, and has done excellent work, especially with helping users with list related matters. I asked him if he, from his point of view, considers himself a delegate. He said he did not know. My question next question was, Has this been a problem so far, working with me and others?, and Pasc answered, it has never been a problem for me. I was truly wondering about the answer to this question because I'm in quite regular contact with him about listmaster matters, and our communication is working very well. Anyway, I take a very pragmatic approach on this. Some of it is outlined in http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00041.html In general, I don't care about the status of people (also see the question about women; I don't discriminate based on sex/gender, nationality, or delegate status). In free software, we usually don't carry around big titles (the DPL being one major exception). What I care about is getting work done. I care about creating the best free operating system out there! If there is a problem, it has to be fixed -- no matter if that person is a delegate, a developer or a sponsored person. I stay in contact with many people in the project to see how their work is going, and how I can help them getting their work done. If there are problems, any kind of problems in the project, I, as the DPL, see it as my responsibility to make sure those problems are being addressed. In summary, I think we should ask questions like is the work by these people or in these areas being performed properly, is their work documented properly and transparent rather than wondering about the status. But if you do care about titles, then, yes, I consider all of these people as delegates (with the exception of the Technical Committee, see next question). All of them perform duties in the spirit of a delegate as defined by the constitution. Do you believe the Tech Committee is effective in its role for the project? No, I am extremely disappointed with the role of the Technical Committee. I actually talked to Peter Palfrader [EMAIL PROTECTED] about this at FOSDEM two weeks ago. While I think that we should in most cases come to a consensus by discussing matters on our mailing lists, I think it's important to have a healthy Technical Committee just in case. When I became DPL last year, I wanted to use my delegation power to re-active the committee, but found out that the Technical Committee is exempted as per the constitution. Of course, if you read what I wrote above, you'll see that this is a bad excuse for not fixing the problem - the problem has to be fixed even if they are not delegates. I admit I didn't do that, which was partly because there were more important things to handle and fix. However, as time goes on and the Technical Committee becomes even more stale, it has become a priority for me to do something about the situation. Having people on the Technical Committee who don't have a single package in the archive or whose packages have been orphaned because they were not maintained is simply not how it should be! -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
On Wed, Mar 03, 2004 at 06:16:20PM +, Martin Michlmayr wrote: No, I am extremely disappointed with the role of the Technical Committee. I actually talked to Peter Palfrader [EMAIL PROTECTED] about this at FOSDEM two weeks ago. While I think that we should in most cases come to a consensus by discussing matters on our mailing lists, I think it's important to have a healthy Technical Committee just in case. When I became DPL last year, I wanted to use my delegation power to re-active the committee, but found out that the Technical Committee is exempted as per the constitution. Of course, if you read what I wrote above, you'll see that this is a bad excuse for not fixing the problem - the problem has to be fixed even if they are not delegates. I admit I didn't do that, which was partly because there were more important things to handle and fix. However, as time goes on and the Technical Committee becomes even more stale, it has become a priority for me to do something about the situation. Having people on the Technical Committee who don't have a single package in the archive or whose packages have been orphaned because they were not maintained is simply not how it should be! That would be me. Note that I am open to the idea of dropping my membership in the technical committee in favor of someone else. However, I'd want this someone else to be someone I could feel good about [both in terms of participation, and background]. But I'd want to be extremely careful about stepping down... A few things to keep in mind: [*] The technical committee gets stuck with the really bad issues. Normally, issues are resolved by the proper developers. Things don't go to the technical committee until they've really messed up. The best thing for the technical committee members to do, here, is to act in their capacity as normal developers to keep things from getting that screwed up. [And, obviously, this isn't something that only TC members can do.] [*] People are going to be unhappy with technical committee decisions. This is fallout from only dealing with really bad issues. It's also fallout from having override power on the normal decision making processes, and only being authorized to use that power in contentious circumstances. [*] In general, an inactive Technical Committee is a good thing. A stale technical committee means that there aren't any really bad issues to be dealt with. However, to improve response time when there is a bad issue it probably would be a good idea to occasionally do something -- the problem is finding something that isn't just a waste of time. Superficially, it might be nice to see that the technical committee is doing something. But, really, other than dealing with things that shouldn't have happened in the first place, and bureacratic tail chasing, what is there for the TC to do? One answer, perhaps, would be to maintain a section of the web site explaining past decisions and issues. If someone did a good job putting something like this together, and then also expressed an interest in participating, and the other TC members agreed with me that this would be a good thing, I'd be happy to step down in favor of that person. More generally, if you have good ideas for the TC [general you, not specifically Martin], it would probably be a good idea to act on them. Discuss if in doubt, or if you need help or cooperation, of course, but ... what's disappointing is seeing people criticize the TC, over and over, for doing what it's supposed to be doing. Maybe if it had been called Technical Garbage Service instead of Technical Committee people who can't be bothered to digest what the constitution has to say about it would have a better idea of what it does. [Also, for people who haven't read the relevant bits of the constitution: it's not the member stepping down that chooses new members.] I do recognize that my own financial and technical situation [which has resulted in me not maintaining any packages -- and which currently means that I'm not in a position to sign anything [again]] isn't the best thing for the TC, but I hope that the above gives a bit of an idea of where I stand on the issue of improving the technical committee. [Further aside: I currently have a machine which I've designated as a debian development machine. It can sign packages. However, to communicate it either needs to use pppoe [and the pppoe package I have installed isn't working] or a router [and I appear to have a problem with my kernel where the only kernel version that will talk to the router has some other serious problems]. I don't know enough about the situation, yet, to know whether this is a hardware problem, a kernel problem, or a bug in one or more debian packages. But it's just a matter of time until I find out.] Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
On Wed, Mar 03, 2004 at 04:48:01PM +1100, Pascal Hakim wrote: Hi, Which of the groups/people on [1] do you consider delegates? Why or why not? Formally speaking, I guess only two are. The Release Manager, and the Hardware Donations Manager. Martin can probably tell us if he's made other delegations on that page. Would you change this? Yes, as I stated in my platform[2]: We need to respect the delegate process, or amend it. I don't think every particular task in the Project is the same as maintaining a package. The roles of archive administrator, project keyring maintainer, and project system administrator are important. In practice, we distinguish these roles from that of package maintainer in many ways. They are of particular importance and merit special attention. I do not think they can reasonably be lumped into the same category as the individual package maintainer. They have special powers and should be treated specially. The concept of the delegate in the Constitution was drafted with such roles in mind. That no previous DPL as taken the obvious step is a disappointment to me. [...] I will take the obvious step described in the previous section, and formalize the delegate status of the many important people who do critical work for our project who do not already enjoy delegate status. In the event I cannot do so, or am persuaded that this is a bad idea, I will explain to the entire project why I cannot, and then, if necessary, propose a General Resolution amending our Constitution to reflect the facts of Debian's organization. I think the following roles should be formally delegated: FTP Archives Release Manager Release Manager for stable Bug Tracking System Mailing Lists Administration Mailing Lists Archives New Maintainers Front Desk Developer Accounts Managers Keyring Maintainers Security Team [3] Web Pages [3] System Administration LDAP Developer Directory Administrator DNS Maintainer (hostmaster) Hardware Donations Coordinator Accountant It's possible some of the above roles should be condensed into one. Do you believe the Tech Committee is effective in its role for the project? I suspect not; as I stated in my platform[2]: I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized. [1]: http://www.debian.org/intro/organization [2] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml [3] It's probably only necessary to delegate a head, who then has authority to appoint other members, much as the current Release Manager has appointed deputies. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Questions for candidates -- Debian's Organizational Structure
* Bob Hilliard [EMAIL PROTECTED] [2004-03-03 17:53]: However, as far as I recall, no DPL has ever publicly appointed delegates to positions. http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg5.html -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
* Pascal Hakim [EMAIL PROTECTED] [2004-03-03 16:48]: Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? Before answering this mail, I talked to Pasc on IRC for a while. Pasc was added as a listmaster during my term as DPL, and has done excellent work, especially with helping users with list related matters. I asked him if he, from his point of view, considers himself a delegate. He said he did not know. My question next question was, Has this been a problem so far, working with me and others?, and Pasc answered, it has never been a problem for me. I was truly wondering about the answer to this question because I'm in quite regular contact with him about listmaster matters, and our communication is working very well. Anyway, I take a very pragmatic approach on this. Some of it is outlined in http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00041.html In general, I don't care about the status of people (also see the question about women; I don't discriminate based on sex/gender, nationality, or delegate status). In free software, we usually don't carry around big titles (the DPL being one major exception). What I care about is getting work done. I care about creating the best free operating system out there! If there is a problem, it has to be fixed -- no matter if that person is a delegate, a developer or a sponsored person. I stay in contact with many people in the project to see how their work is going, and how I can help them getting their work done. If there are problems, any kind of problems in the project, I, as the DPL, see it as my responsibility to make sure those problems are being addressed. In summary, I think we should ask questions like is the work by these people or in these areas being performed properly, is their work documented properly and transparent rather than wondering about the status. But if you do care about titles, then, yes, I consider all of these people as delegates (with the exception of the Technical Committee, see next question). All of them perform duties in the spirit of a delegate as defined by the constitution. Do you believe the Tech Committee is effective in its role for the project? No, I am extremely disappointed with the role of the Technical Committee. I actually talked to Peter Palfrader [EMAIL PROTECTED] about this at FOSDEM two weeks ago. While I think that we should in most cases come to a consensus by discussing matters on our mailing lists, I think it's important to have a healthy Technical Committee just in case. When I became DPL last year, I wanted to use my delegation power to re-active the committee, but found out that the Technical Committee is exempted as per the constitution. Of course, if you read what I wrote above, you'll see that this is a bad excuse for not fixing the problem - the problem has to be fixed even if they are not delegates. I admit I didn't do that, which was partly because there were more important things to handle and fix. However, as time goes on and the Technical Committee becomes even more stale, it has become a priority for me to do something about the situation. Having people on the Technical Committee who don't have a single package in the archive or whose packages have been orphaned because they were not maintained is simply not how it should be! -- Martin Michlmayr [EMAIL PROTECTED]
Re: Questions for candidates -- Debian's Organizational Structure
On Wed, Mar 03, 2004 at 06:16:20PM +, Martin Michlmayr wrote: No, I am extremely disappointed with the role of the Technical Committee. I actually talked to Peter Palfrader [EMAIL PROTECTED] about this at FOSDEM two weeks ago. While I think that we should in most cases come to a consensus by discussing matters on our mailing lists, I think it's important to have a healthy Technical Committee just in case. When I became DPL last year, I wanted to use my delegation power to re-active the committee, but found out that the Technical Committee is exempted as per the constitution. Of course, if you read what I wrote above, you'll see that this is a bad excuse for not fixing the problem - the problem has to be fixed even if they are not delegates. I admit I didn't do that, which was partly because there were more important things to handle and fix. However, as time goes on and the Technical Committee becomes even more stale, it has become a priority for me to do something about the situation. Having people on the Technical Committee who don't have a single package in the archive or whose packages have been orphaned because they were not maintained is simply not how it should be! That would be me. Note that I am open to the idea of dropping my membership in the technical committee in favor of someone else. However, I'd want this someone else to be someone I could feel good about [both in terms of participation, and background]. But I'd want to be extremely careful about stepping down... A few things to keep in mind: [*] The technical committee gets stuck with the really bad issues. Normally, issues are resolved by the proper developers. Things don't go to the technical committee until they've really messed up. The best thing for the technical committee members to do, here, is to act in their capacity as normal developers to keep things from getting that screwed up. [And, obviously, this isn't something that only TC members can do.] [*] People are going to be unhappy with technical committee decisions. This is fallout from only dealing with really bad issues. It's also fallout from having override power on the normal decision making processes, and only being authorized to use that power in contentious circumstances. [*] In general, an inactive Technical Committee is a good thing. A stale technical committee means that there aren't any really bad issues to be dealt with. However, to improve response time when there is a bad issue it probably would be a good idea to occasionally do something -- the problem is finding something that isn't just a waste of time. Superficially, it might be nice to see that the technical committee is doing something. But, really, other than dealing with things that shouldn't have happened in the first place, and bureacratic tail chasing, what is there for the TC to do? One answer, perhaps, would be to maintain a section of the web site explaining past decisions and issues. If someone did a good job putting something like this together, and then also expressed an interest in participating, and the other TC members agreed with me that this would be a good thing, I'd be happy to step down in favor of that person. More generally, if you have good ideas for the TC [general you, not specifically Martin], it would probably be a good idea to act on them. Discuss if in doubt, or if you need help or cooperation, of course, but ... what's disappointing is seeing people criticize the TC, over and over, for doing what it's supposed to be doing. Maybe if it had been called Technical Garbage Service instead of Technical Committee people who can't be bothered to digest what the constitution has to say about it would have a better idea of what it does. [Also, for people who haven't read the relevant bits of the constitution: it's not the member stepping down that chooses new members.] I do recognize that my own financial and technical situation [which has resulted in me not maintaining any packages -- and which currently means that I'm not in a position to sign anything [again]] isn't the best thing for the TC, but I hope that the above gives a bit of an idea of where I stand on the issue of improving the technical committee. [Further aside: I currently have a machine which I've designated as a debian development machine. It can sign packages. However, to communicate it either needs to use pppoe [and the pppoe package I have installed isn't working] or a router [and I appear to have a problem with my kernel where the only kernel version that will talk to the router has some other serious problems]. I don't know enough about the situation, yet, to know whether this is a hardware problem, a kernel problem, or a bug in one or more debian packages. But it's just a matter of time until I find out.] Thanks, -- Raul
Re: Questions for candidates -- Debian's Organizational Structure
On Wed, Mar 03, 2004 at 04:48:01PM +1100, Pascal Hakim wrote: Hi, Which of the groups/people on [1] do you consider delegates? Why or why not? Formally speaking, I guess only two are. The Release Manager, and the Hardware Donations Manager. Martin can probably tell us if he's made other delegations on that page. Would you change this? Yes, as I stated in my platform[2]: We need to respect the delegate process, or amend it. I don't think every particular task in the Project is the same as maintaining a package. The roles of archive administrator, project keyring maintainer, and project system administrator are important. In practice, we distinguish these roles from that of package maintainer in many ways. They are of particular importance and merit special attention. I do not think they can reasonably be lumped into the same category as the individual package maintainer. They have special powers and should be treated specially. The concept of the delegate in the Constitution was drafted with such roles in mind. That no previous DPL as taken the obvious step is a disappointment to me. [...] I will take the obvious step described in the previous section, and formalize the delegate status of the many important people who do critical work for our project who do not already enjoy delegate status. In the event I cannot do so, or am persuaded that this is a bad idea, I will explain to the entire project why I cannot, and then, if necessary, propose a General Resolution amending our Constitution to reflect the facts of Debian's organization. I think the following roles should be formally delegated: FTP Archives Release Manager Release Manager for stable Bug Tracking System Mailing Lists Administration Mailing Lists Archives New Maintainers Front Desk Developer Accounts Managers Keyring Maintainers Security Team [3] Web Pages [3] System Administration LDAP Developer Directory Administrator DNS Maintainer (hostmaster) Hardware Donations Coordinator Accountant It's possible some of the above roles should be condensed into one. Do you believe the Tech Committee is effective in its role for the project? I suspect not; as I stated in my platform[2]: I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized. [1]: http://www.debian.org/intro/organization [2] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml [3] It's probably only necessary to delegate a head, who then has authority to appoint other members, much as the current Release Manager has appointed deputies. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Questions for candidates -- Debian's Organizational Structure
Pascal Hakim [EMAIL PROTECTED] writes: Hi, Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? Since I am not a candidate, I cannot answer the question as asked. However, I can add a data point. When the draft constitution was first proposed, I pointed out to Ian that the important positions of ftp admins, release manager, and other core functionalities were not mentioned. Ian's response was that these positions were all intended to be delegates. However, as far as I recall, no DPL has ever publicly appointed delegates to positions. The constitution is silent on the process of appointing delegates. IMNSHO, such appointments should be announced publicly. Regards, Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: Questions for candidates -- Debian's Organizational Structure
* Bob Hilliard [EMAIL PROTECTED] [2004-03-03 17:53]: However, as far as I recall, no DPL has ever publicly appointed delegates to positions. http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200305/msg5.html -- Martin Michlmayr [EMAIL PROTECTED]
Questions for candidates -- Debian's Organizational Structure
Hi, Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? Do you believe the Tech Committee is effective in its role for the project? Cheers, Pasc [1]: http://www.debian.org/intro/organization -- Pascal Hakim+61 4 0341 1672 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Questions for candidates -- Debian's Organizational Structure
Hi, Which of the groups/people on [1] do you consider delegates? Why or why not? Would you change this? Do you believe the Tech Committee is effective in its role for the project? Cheers, Pasc [1]: http://www.debian.org/intro/organization -- Pascal Hakim+61 4 0341 1672
