On Fri, Feb 23, 2001 at 12:02:42PM +0100, Wichert Akkerman wrote: > Previously Branden Robinson wrote: > > [please follow-up to debian-project@lists.debian.org] > > No, follow-up to debian-vote, it was created for this purpose. I thought it was supposed to be confined to the mechanics of actual voting, which DPL campaigning is not, but I'll take your word for it. > > I cannot at present find a canonical list of current delegates. > > I'm offline at the moment and the exact URL escapes me, but this list is > on www.debian.org and was created about 2 yaers ago. It being presently inaccessible is a problem, in my opinion. Also, it may have been *created* 2 years ago, but is it up to date? > > Delegates should serve for a term of one year, or until the > > next DPL begins his term. > > I really have to object to this: a change of DPL should not mean that > every delegate suddenly needs to be re-appointed and the whole project > does not know what is going to happen. A delegate is someone the project > should trust, and a change of DPL is no reason to make that trust > suddenly disappear and require the new DPL to reappoint or appoint > another delegate. In talking about this with people I'm starting to thing a two-year term for delegates is more appropriate, because I do want to avoid the situation you get with U.S. Presidental Cabinets, where everyone gets fired as soon as the new guy takes office. Any delegate (except Project Secretary) can still be removed or replaced by the standing DPL, even if that's not the same DPL who appointed him, as I understand the current rules. I do think we need a backup mechanism for replacing the Project Secretary (the current one requires the DPL and sitting PS to come up with a new one together), but what do you do if the sitting Project Secretary is unavailable and/or unresponsive? This is, of course, a wildly hypothetical scenario... > > serve out his or her year-long term even across a DPL transition, but > > I also believe that delegates must derive their status from the > > sitting Debian Project Leader, since this only makes sense. > > Can you explain why? Compare it for example with judges in (afaik) all > legal systems. They are also not changed when the government changes > after an election. As I said before, I've modified my position on this. I agree, it smacks too much of an executive cabinet. My reason for wanting the short term was so that the delegate's performance would have to be considered with greater frequency. However, it is likely more appropriate to roll this into the accountability mechanisms that I also proposed having. > > At the very least, I believe the current DPL delegates of Project > > Secretary, Release Manager, Debian Account Manager, and Debian System > > Administrators should be completely formalized under this process. > > Release manages is, ever since Richard Braakman became release manager > about 2 years ago. If you look at the URL I mentioned above you will see > the exact delegation notice. The URL you mentioned above which is offline, and which escapes you? What good is that going to do anyone? > > My recent experience with LinuxWorld Conference & Expo, New York, 2001, > > gave me a few ideas about we can better handle this issue. In a nutshell, > > we had no one representing Debian with the coordinators of this event until > > less than two weeks before it occurred; as a result, Debian very nearly > > went without a booth at a major trade show. I do not consider this a good > > thing, since we had Debian developers in attendance and willing to > > represent us at the booth, answer users' questions, and otherwise put a > > face on the Project. > > You did manage to pick the one bad apple here, in general things go a > lot better, and for the next LWCE arrangements are already being made. I want to do what I can to make sure it doesn't happen again. Aside from assuring me that things will come together every time in the future, do you have any objections to my proposal to delegate regional Event Coordinators? > > As Debian Project Leader, I intend to get into personal contact with as > > many board members of SPI as possible and attempt to persuade them to > > populate their board with people who are able to give some attention to > > their duties. > > As you should know, the DPL is automatically an advisor on the SPI > board. (and I've been trying the same thing for some time as well fwiw) Yeah, I know. I'll get as aggressive as I have to. > > V. REVISION OF THE DEBIAN MACHINE USAGE POLICY > > > > When I first read the DMUP[6] I felt it was a poor fit in places for > > Debian. I was told that many of its terms were lifted verbatim from an > > ISP's Acceptable Use Policy (AUP). As DPL, I'd like to appoint a team, > > including at least one representative from the Debian System Administrators, > > to draft a new one. > > Didn't you volunteer to do that a while after it was introduced? I > remember nothing came of that. The team I assembled was not very responsive, and there was absolutely no delegation of authority from you of any kind. You basically told me to go off with these guys and come up with something, and were given no assurances that anything at all would be done with the resulting document. I think that had something to do with the level of apathy. I can dredge up the emails if you want, but I personally was far and away the most active participant in that revision process. I think a better way to handle it would have been to delegate authority for revising the DMUP first. That way the team knows that the people in charge of making it official won't just let it gather dust in a corner. Lord knows that *never* happens in this Project. As I recall, you never did explain to me why you were unwilling to delegate anything having to do with this subject. > > VII. THE #DEBIAN-DEVEL IRC CHANNEL > > > > As DPL, I'd like to see this channel's status officially recognized, and a > > position on the two subjects above formally stated. If #debian-devel is > > not to be substantively different from #debian, that is fine; a new channel > > can be created to serve the needs that (in my opinion) #debian-devel > > currently does, and with some access controls in place. > > I'll object to this. What specifically do you object to? Did you actually read what you quoted? * the channel's status should be officially recognized * the rules of admission to the channel should be formally stated * whether topics from debian-private may be discussed there should be formally stated * a new channel can be created, with some access controls in place Your sentences in support of your objection do not follow from the text of mine you quoted. > #debian-devel should be like the debian-devel list: > open for developers, not closed. That is the way it has been since the > very beginning and I hate to see that change. Make #debian-private if > you want. No, that's not correct. Not when I first started hanging out there in early 1998. I wasn't welcome in there before I was a developer, and subjects from the debian-private mailing list were very frequently discussed (and still are, from time to time). -- G. Branden Robinson | Religion is something left over from the Debian GNU/Linux | infancy of our intelligence; it will branden@debian.org | fade away as we adopt reason and science http://www.debian.org/~branden/ | as our guidelines. -- Bertrand Russell
Attachment:
pgpnSysuaFa4W.pgp
Description: PGP signature