Hi, While I agree that Debian needs change if we want to face the future, and that the idea of Project Scud might be the change we're looking for, I still have a few reservations, mainly situated around the status the team, as proposed by Project Scud, will have in the Debian Project's structure.
As we all know, the Debian Constitution does not define the DPL's function as a team; it only defines the DPL's function, that of the Project Secretary, the Technical Committee, of Delegates, and of the Project's Developers. By excluding the bodies that are not of relevance to the DPL's position, there are only two options: * The members of Project Scud (other than the DPL himself) do not actually have any real power, except that the DPL will stand by them if any of their decisions are challenged (thus, their power will only exist de facto); * The members of Project Scud (other than the DPL himself) will be formally appointed as delegates (thus, they will have real power, backed by our constitution). Both have their problems. The first option leaves us in a situation that, IMHO, feels very awkward; should the DPL seriously disagree with some of the team members, it may jeopardize the whole undertaking. While I understand the intention of Project Scud is to avoid this, the possibility is still there, and I feel very uneasy at the thought. I am also not so sure it is a good idea to create the sort of semi-official body this team would end up being, if it is to make decisions of great importance to the whole project. The second option has some procedural problems; I understand the idea of Project Scud is to share the whole of the DPL's responsibilities amongst a group; however, that is in conflict with the phrasing as it exists in section 5.1, first point, of the Constitution, specifically, " The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. " because, if the intention is indeed to share the whole responsibility of the DPL among a group of people, then to "define an area of ongoing responsibility" is exactly what the Project Scud-DPL will not be doing ("make the decisions the DPL will usually be making" does not qualify) Another concern is what will happen if Project Scud's experiment is successful. Will the team remain the same, or will other people be appointed? If the former is true, what guarantees are there to make sure that accusations of it being some sort of 'cabal' will not be grounded in truth? If the latter is the case, how will this be done? Will the team simply cease to exist, leaving the next DPL to make up his own team, or will the team choose new members among the existing developers? Or will we have a 'DPL Team Election' next year, rather than a 'DPL election'? I would appreciate it if Project Scud members (not just those that are DPL candidate), would address my concerns. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]