[cc:ing debian-devel so -announce doesn’t get swamped — apologies and please suggest a better list (or none) if I chose poorly ….] Thank you for laying out the context. I will put in a few questions as I look at how I want to contribute to Debian community. If this triggers early discussion, so be it. Re: proposal #2: How does the Committee currently handle “hey this is fundamentally non-technical and out of our scope”? (eg refer to Debian Project Leader to re-delegate) Does this really suggest forming a Non-technical Committee? (maybe even constitutionally mandating) Re: proposal #5: Why must sending implicit/out-of-scope duties elsewhere require disbanding TC? If such implicit/out-of-scope duties accreted, it seems like not by Constitution, so can DPL delegate/distribute those away from TC? Re: TC as nuclear option, proposal #4: What’s done currently to mitigate? Perhaps this encourages forming a well-known lesser body, formal or informal, to give advice and serve as a rally-point for hammering out proposals and encouraging design work. (Or two, one for advice/review and one to track/encourage the actual work.) In many US-based non-profits, the past heads of organization as a group visibly serve such a role. For instance, in Toastmasters International, past District Managers serve as this “council of grey-beards”, along with the explicit mandate to help mentor prospective and future leaders for their respective districts. A naive translation of this idea would propose all past TC members together be asked to fulfill this role. Re: no design work: What prevents the TC from visibly tabling a matter pending further design work? Perhaps with specific advice/observations/suggestions for designers to consider? Maybe even in conjunction with DPL/someone designating specific folks to create proposal(s)? Re: advisory body: What prevents TC members (acting as an informal group which is not the TC) from being that advisory now? Thanks! Joseph —— Joseph Beckenbach
|