[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal - Project infrastructure team procedures

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.


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.


[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.

Reply to: