Josip Rodin wrote: > Anyway, I'd agree to stripping down the detailed procedure, but you still Sorry for not replying to this thread before. IMO it is definitely worthwhile to clarify the role of core teams within the project and to establish some kind of framework to ensure that continuity in the work of those teams can be better guaranteed, especially by ensuring that the existing team cannot hold the rest of the project "hostage" by structurally blocking any change in its membership or blocking access to resources [1]. My first objection to the proposal for which you asked for seconds was that it did not "read" like a GR. It was also not clear how the GR should be implemented after being passed: it proposed a detailed procedure without introducing some kind of permanent document to "hold" that procedure. I also felt that the original proposal was probably over-engineered and like the general idea behind the changes proposed by Lucas. > shouldn't strip these two ideas: > * the definition of infrastructure teams - add one clause saying that > the DPL decides which they are, so that we preclude any discussion > of the lack of applicability > * the mention of communication - add one clause saying that relevant > membership decisions have to be promptly and properly communicated > between the DPL and the teams, so that we don't have a lack of > transparency. I'd also charge the DPL to eventually inform the developer > body about the gist of all such matters. Agreed. I also to some extend agree with people who may feel that this proposal may be "too late" now as the problems are finally being addressed. However, IMO that should not prevent us from clarifying things for the future. Cheers, FJP [1] The case I have in mind here is debian-announce and related resources.
Attachment:
signature.asc
Description: This is a digitally signed message part.