You added me as sponsor for the PEP, but I didn’t offer to sponsor it I’m sorry, but I don’t wish to be marked in CODEOWNERS as an owner of this PEP, which is apparently something that is required of a sponsor. (I’m happy enough with the other part of being a sponsor “provide guidance to the PEP author to help them through the logistics of the PEP process”, though).
And for the record, I don’t really have an opinion on the PEP itself, although that technically wouldn’t prohibit me from being a sponsor…
As a PEP editor I’d like to talk about this a bit more to understand your concerns and see if there’s something we can change on the peps side.
I feel part of the sponsor role is to make sure the PEP is something that at least one core dev can stand behind as a reasonable proposal (even if they may not ultimately agree with it). The technical consequence of the CODEOWNERS entry is that the PEP sponsor gets requested for review whenever the PEP changes, so the sponsor can make sure the changes are acceptable to them. It doesn’t mean that the sponsor “owns” the PEP, that’s just the terminology GitHub forces on us. As a PEP editor, I sometimes use my judgment to merge a PR without explicit sponsor approval, if the change seems noncontroversial to me and the sponsor has had some time to voice their concerns. (Though if the PEP sponsor requests I don’t, I would not merge such PRs.)
It’s not anything particular. I just don’t have the time to sponsor this PEP, and I’m not that interested in it. Sometimes I’ll be willing to sponsor anyway, as it’s usually not an onerous responsibility, but not this time. The point about CODEOWNERS is mainly just that I wasn’t aware that it’s something that a sponsor is expected to do, and I already get too many github notifications. In this case I was getting pings for every minor update and it was getting annoying.
My original wording put more emphasis on the CODEOWNERS matter than I really intended.
One thing that could hopefully help reduce this somewhat is that following python/core-workflow#460, triagers (and, theoretically, any Python org member) can now be marked as a “codeowner” and thus get automatically tagged on PRs that modify it, without having to give them the ability to push commits, create branches, merge PRs or otherwise touch the upstream peps git repository. So, at least in theory, we could decouple the Sponsor role from CODEOWNERS, if the PEP author was a triager or other non-core dev/PEP editor org member (which have a much lower bar for entry). But, we may want to keep that for the reasons @Jelle mentioned.
That, and to ensure the PEP had someone nominally connected/responsible for it tagged to review and/or merge PRs that propose changes to that PEP, as previously it wasn’t possible to mark non-core devs/PEP editors as CODEOWNERS, and there weren’t as many active PEP editors (like you) to help out with this.
Yeah, same. Typically I’ll review/approve but won’t merge unless the sponsor has or it’s sufficiently non-controversial and has been at least a week or two for them to respond.
Don’t do that on my account. Honestly, I feel this has blown out of proportion (as well as being offtopic for this thread).
My original comment should really just be read as “I don’t want to sponsor this PEP and you added me without confirming it was OK, can you please remove me?”. Which @fridex kindly did, so there’s really nothing more needed here.
Sorry about that—just to clarify, I didn’t mean to imply this is anything that we are currently actively pursuing, or would do for any existing sponsors without asking them first, just one possible option for the future if this does become an issue.
To that end, I’ve also added an explicit item in the new PEP checklist for PEP authors and editors that the PEP has a sponsor, if needed, that has confirmed they are okay sponsoring.
We just now deployed new PR templates with our review checklists that authors will see prior to submitting their PRs (as well as after); the first item for Standards-Track PEPs asks whether the PEP has already been discussed, refined, and generally agreed to be ready in an appropriate discussion venue first, and another item asks that the PEP has a sponsor who has confirmed they are okay with it first, if not authored by a core dev or PEP editor. This will hopefully help guide new PEP authors toward ensuring their PEPs are complete before posting them.
Initially, in the new checklist, that was the case. However, after multiple others suggested such, to simplify the process for both authors and reviewers, we tweaked it so new PEP authors are now instructed to just use the next available sequential number for their PEP instead of having one manually assigned post-facto, such that there’s no need to go back through and change everything assuming the PEP is merged and there’s no number conflict. However, as before, the number is not actually assigned to them until the PEP is merged, and is double-checked as part of the PEP editor review, and the checklist only recommends creating the official PEP discussion thread just before or just after it is actually merged.
I’m sorry, but I don’t wish to be marked in 