To me, no new process is being invented here, on purpose, and so we should just rely on whatever governs any large JIRA or vote, because SPIPs are really just guidance for making a big JIRA.
http://apache.org/foundation/voting.html suggests that PMC members have the binding votes in general, and for code-modification votes in particular, which is what this is. Absent a strong reason to diverge from that, I'd go with that. (PS: On reading this, I didn't realize that the guidance was that releases are blessed just by majority vote. Oh well, not that it has mattered.) I also don't see a need to require a shepherd, because JIRAs don't have such a process, though I also can't see a situation where nobody with a vote cares to endorse the SPIP ever, but three people vote for it and nobody objects? Perhaps downgrade this to "strongly suggested, so that you don't waste your time." Or, implicitly, that proposing a SPIP calls a vote that lasts for, dunno, a month. If fewer than 3 PMC vote for it, it doesn't pass anyway. If at least 1 does, OK, they're the shepherd(s). No new process. On Mon, Feb 27, 2017 at 9:09 PM Ryan Blue <rb...@netflix.com> wrote: > I'd like to see more discussion on the issues I raised. I don't think > there was a response for why voting is limited to PMC members. > > Tim was kind enough to reply with his rationale for a shepherd, but I > don't think that it justifies failing proposals. I think it boiled down to > "shepherds can be helpful", which isn't a good reason to require them in my > opinion. Sam also had some good comments on this and I think that there's > more to talk about. > > That said, I'd rather not have this proposal fail because we're tired of > talking about it. If most people are okay with it as it stands and want a > vote, I'm fine testing this out and fixing it later. > > rb > >
