On Mon, Sep 06, 1999 at 02:01:18PM +1000, Anthony Towns wrote: > They're not, after all, all *that* bad. Sure, we had a whole bunch of > problems with /usr/doc, amongst which were: > * 'twas a complicated issue with no elegant solutions > * everyone didn't really know how to work with `formal objections' > * no one really knew how to work with the technical committee (IMHO > the -policy group looked on it as an easy way out, then a month > or so later realised they didn't have their act together either) > * we'd made a major change in policy that made no explicit consessions > to backwards compatability
This seems reasonably accurate. I think, however, that "no elegant solutions" should be a warning flag that we're doing something wrong. > We've come up with solutions (or at least countermeasures) to most > of these. First, `formal objections' definitely should be able to > be responded to, and withdrawn. That didn't really happen with > this proposal, and if it had, I suspect we'd have managed to get a > consensus anyway, eventually. Second, the technical committee at least > has a working mailing list and a chair now. We even, eventually, got a > response. I think Wichert gets credit for getting the technical committee up and running. > Finally, we are at least considering making changes that say "the > current way is okay, but we'd prefer it if you did such-n-such", which > IMO would make changes like this one much easier to bear (witness the > `-g' proposal, for example. Ideally it wants major changes to every > package, but it doesn't complain about unmodified packages being non > policy-compliant). Yes, I agree that this is a good thing. > So I don't see a huge need for upheaval. I think the policy groups > (-policy and the tech ctte) are heading in the right direction. Hmm... I don't think I see a need for a huge upheaval either (someone was suggesting that there wouldn't be much point for the policy list, the more I think about it, the more I disagree with that point of view). I do think that the policy group needs to pay a bit more attention to their own resolutions/procedures/informal practices/whatever you call them. I do think that the policy group should consider actively soliciting the opinions of package developers [on the basis that package developers have some significant expertise in a variety of matters]. It is possible that some documents (proposal, constitution, etc.) need some fairly subtle edits. But huge upheaval? That's exactly what I'm trying to avoid. > > Personally, I'd hate to rewrite the proposal document without any > > input from the policy maintainers, and likewise, I'd hate to propose > > a constitutional change to match the current proposal document > > without even more input [enough to see that most developers are > > unhappy with the idea that technical decisions are better made by > > individuals than by large groups]. > > That's not quite the way -policy works though: it's not a "big groups" > versus "individuals" thing, it's a consensus thing. I'm not going to > attempt to define it more precisely than that: I'm sure I'd get it > horribly wrong and I think we've already got good enough means for > testing consensus anyway, and a definition would merely get in the > way. I think I understand, and I think I have a nit: consensus is a fine thing, but you have to be careful to distinguish between apathy and consensus. [Which is yet another reason to expect that soliciting the opinions of developers would be a good thing.] > In particular, the policy group *does* decide on technical matters > by consensus, whether those decisions conflict with other packages > or not. Yes, suggesting major changes instead of demanding them is > /better/, and I'm sure we'll take that into account in future, but > it's only really important in one of a dozen (</pretend_statistics>) > cases: we shouldn't redo the whole of the -policy mechanism about it. Yeah, sample size is too small for statistics to be very meaningful. However, an 8% failure rate isn't really acceptable for major policy decisions -- in my opinion. [Not unless you really do expect another group to comb through what you've approved for quality control purposes.] > What I'd like to see is the technical committee and the DPL ratify the > powers of the -policy group, rather than try to impose changes from > above. Please review section 3 of the constitution for an overview of the [constitutional] powers of policy maintainers. Like you, the constitution doesn't really define consensus -- but I think that the informal definition "as long as there's no formal objection" is completely inadequate. -- Raul
