On Mon, 19 Nov 2018 at 11:24, Nathaniel Smith <n...@pobox.com> wrote: > Thanks for raising this. It's an important issue and one where I've > been struggling too. > > I'll put my conclusion first. My suggestion: > > - We do allow changes to the PEPs until the actual voting starts, but > not afterwards > - We leave it up to the PEP authors' judgement what changes they want to make > - The PEP authors will work together to maintain a single shared > changelog summarizing every change that's made to the PEPs after Nov. > 16, no matter how trivial, and including links to the relevant commits > so you can easily see the actual text > - We'll include a link to this changelog prominently in the voting > instructions etc. > > This is easy to implement, avoids messy subjective judgements about > which changes are "too big", allows the PEPs to be tweaked and > clarified through the review period, and would mean that so long as > you read the PEPs at least once during the review period and then > check the changelog before voting, you're guaranteed that you won't > miss anything.
I agree, this is a really difficult question to get right. My feeling, however, is that the PEPs that are having the most trouble with this are the ones that are trying to pin down too much detail. Sure (to pick a random example), it's ultimately going to be important that a council have a clear idea of how they reach agreement on banning a core developer, should that situation come up. But is it really going to be so critical to establish that detail *right now* that someone would change their vote **to a completely different governance model** if the number of votes was set at 3 or 4? And is the proposal explicitly denying us the chance to change that number based on experience going forward?[1] I realise this is precisely the point you made about subjective judgements, but I think it needs to be taken in context. I have a maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm interested in the overall "shape" of the proposal (leader or group who decides vs community voting for example) and the "tone" (is it concerned with pinning down lots of details, does it assume we'll trust each other to work in good faith, is it bureaucratic, is it well-established or novel, etc). The sorts of changes you're talking about in the examples you give mostly leave me with a feeling of "this proposal is prone to getting bogged down in details, it's overspecified", and that's what will affect my vote rather than the actual detail being debated[2]. > It's possible PEP 8016 is particularly prone to this because a design > goal was to be small and explicit enough to encourage > <del>nitpicking</del>detailed review, but I'm not just suggesting this > because "my" PEP has special needs. I'd characterise this more as "PEPs that try to specify too much detail are prone to this because they encourage 'detailed review'"... ;-) > - Steve Dower is considering withdrawing PEP 8014 entirely [4], which > if it happens would be a major substantive change to PEP 8014 that > voters would want to know about! Knowing about it - definitely. But more importantly, I'd like to know *why*! If Steve no longer considers his proposal worth voting for, what is his logic, and what does he consider a reasonable alternative for people who *did* want to vote for it? Personally, I'm not that worried as that wasn't one of my preferred proposals, but I do think that if you have created a proposal, you have a certain level of responsibility to the people who liked it to give them information on what you view as the "migration path" from what they voted for to where you are now (and "not being able to vote for it" is a pretty extreme case of that!) > - In the course of a discussion that Paul Moore started about > processes for promoting core devs, I realized [5] that there's (what > feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about > how much power the Technical Leader or Trio would actually have – > specifically I'd been assuming one thing, but realized that the texts > actually don't say either way. I hope Barry and Mariatta will clarify > what they intended before the vote starts. No matter which way they > clarify things, it may feel like a substantive change to some people, > depending on how they read it originally. And yet, I hope they don't, as a key point for me about their proposals is that they *don't* try to specify everything up front, but rather they allow for the leader/council to make judgements as time goes on. If you feel that as a result their proposals are underspecified, by all means vote for something else. > In this last case, I *guess* as the co-author of a competing PEP I > could be like "haha, PEP 8001 says it's too late for substantive > changes so your PEP loses", and then they could be like "no these > changes aren't substantive because we're just clarifying what we meant > all along", and then I could be like "well as a voter it feels > substantive to *me*"... but this sounds like a miserable way to live. So is forming an opinion by viewing the proposals, and then hoping that no-one publishes a rewrite that means you have to rethink your position at the last minute. It doesn't really help that you have a way of being notified about major changes, the point is that we don't want them to *happen*. (Yes, "major" is subjective once again, I know.) > I'd really rather Barry and Mariatta have the chance to clarify their > PEPs before the vote, so that we all know what our options are and > that those options are the best they can be, and that we skip any > pointless arguments about it. Assuming that we'll deal with things when they happen is also an option, IMO. I'd prefer it if we didn't reach a point where no proposal offered that option. And frankly, changing from a relatively underspecified position of "give some people authority, and let them make the decisions" approach to one more like "elect a group/individual to implement the set of rules we state here" is *definitely* a substantive change, so one I'd oppose allowing now that the review period has started. > The changelog approach is simple, unambiguous, easily enforceable, > allows the PEPs to be clarified, avoids intrinsically subjective > arguments about what counts as "substantive", and makes it easy for > Antoine to know exactly what he's voting on instead of having to trust > that everyone else's definition of "minor tweak" matches his own. ... but means that in theory, *anything* could change right up to the start of the voting period, which makes the introduction of an explicit review period pointless - we could just as easily have started the voting period on the 16th in that case. [1] It's possible that it *is* that important for some proposals. That says to me that those proposals don't have enough built in flexibility to react to unexpected situations (e.g., they have no mechanism for deciding on a decision making system for an unanticipated event). [2] And yes, that does mean that I'm currently inclined towards particular governance models based more on how they are presented, rather than on how they are structured. I'm not going to apologise for that, or even accept that it's wrong. Any system can work if it's implemented in a sufficiently flexible and sympathetic manner, conversely any system can fail if it gets bogged down in bureaucracy and over dependence on rule-book solutions. Paul PS I wrote this without going back over the PEPs, apologies if I've misremembered or misrepresented anyone's proposal as a result of that. PPS It's quite possible that my comments here aren't 100% consistent with what I've previously written. I'm still forming my opinions and they are changing over time - as well as not being super-precise in the first place (I'm judging a lot of this on "gut instinct" that I can't always put into words). So apologies for that as well. _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
