I’m OK with this as a general proposal, but see below for some detailed comments.
I just skimmed that discussion and it seems like it covered a whole load of stuff that doesn’t seem to be related to the proposal linked above (such as debates about face to face discussions). I really don’t have the time or inclination to go back over that whole thread (governance discussions bore me senseless) so can someone please summarise that discussion here? Maybe after summarising, we can say that it was all off-topic for the “Lightweight Governance Model” (which as far as I can tell makes no comment about real-time discussions), but I think we need to bring the content of that discussion here, in the spirit of “closing the loop”.
I really don’t care much. I’m not honestly sure what problem is being solved here, beyond “the Python PEP process has changed, so we can’t use it any more” and for that I’m happy with anything that provides:
- Somewhere to host our standards (we have that, in the packaging guide).
- Some means of reaching consensus (I’m not sure we need more than discussions here plus the existing BDFL-Delegate role).
But if others want additional process, I don’t object (unless it adds extra workload for me that I’m not able/willing to take on).
Some other points on the proposal that I just noticed.
(Hmm, I really don’t know how to easily do a review of a document on Discourse. I’ll limit myself to a few copy&paste bits with comments and hope I dont miss anything).
Creation of a Request for Comments (RFC)
We need something on who can create such an RFC. The current PEP process makes it (deliberately) quite hard for non core devs to raise a PEP. I’m not sure we want to make it too easy for random community members to raise RFCs, or it’ll end up being a route for feature requests. But equally we don’t want to block ideas from the community. I have no good answer here. For an example, see this proposal which is mostly stalled, because of a lack of a sufficiently broad audience to get a critical mass of people to move it through the process. I’d like it if whatever new governance process we had didn’t leave proposals like this
Comments period … as comments on the pull request
I find “comments on PRs” to be a horrible way of discussing changes. I’d much rather that we used some form of proper communication tool (whether Discourse or email, I don’t really care) and limit PR comments to things like grammar corrections and wording details.
If the RFC falls under a specific Interest Area, then the corresponding Interest Area Authority will review the proposal and decide whether it should be accepted or rejected.
We should allow for Interest Area Authorities to delegate decisions if necessary. There will be cases where the IAA doesn’t have the right knowledge to make a final decision, but going to a vote (which means putting it to a group who communally have even less specialised understanding) is the wrong way to go. That should probably simply be “IAAs can appoint a delegate to make the decision if they feel that’s appropriate”.
Conversion of the RFC into an Architectural Decision Record (ADR)
This seems to be replacing the process we’re currently moving to, of having the specs in the packaging guide. Is there a reason for doing this? I don’t think we should repeatedly change the canonical location of standards without good reason (I’m still referring to PEPs rather than the guide ).
Also, there’s no provision for updating agreed specs. Adding one moves us yet further from a “lightweight” model, so I don’t really want to get into endless debate, but we want our standards to move with changes in circumstances, not be locked into stone (“document 0076 as modified by 0089, 0093, 0210 and the addendum in document 0130” )
There may be more, but that’s about as much “governance” discussion as I can cope with for today