[EMAIL PROTECTED] (Andreas Barth) writes: > So, my question is: How can we streamline this?
I've had one possibly useful thought about this, that I'd love to have some feedback on from other committee members. What if we chose to divide along the boundary of whether a question directly affects the content that ends up in a Debian package, or on a user's system through other processes? Anything can have an indirect impact, and this may not always be a clearly black and white boundary, but it seems to me that it might be a good guideline? So, things like which options are used to build a package, what modifications to the code are included, how Debian-specific utilities and applications work, how the contents of different packages interact, which external standards the project chooses to adhere to, etc, are clearly all subjects the Technical Committee can be asked to take up. On the other hand, things like which developers have access to which project resources do not directly affect what ends up in on a Debian user's system and thus could be thought of as less technical and best taken up by the DPL. Does that help at all? Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
