On Aug 31, 2018, at 4:07 AM, Paul Moore
On Fri, 31 Aug 2018 at 01:52, Donald Stufft
I also know that Nick has a few concerns with accessibility to the wider community, which I believe I addressed in the other email thread, but to reiterate, I don’t think that the wider community cares one way or another, and I think the biggest benefit comes from being able to tailor this process to what we need. So we can adjust it as we go along to what makes the most sense to us, without having to go to python-dev and get them to change their process to fit our needs.
I don't think the wider community necessarily participates in discussions, but nevertheless I feel that the *ability* to do so is essential. There's already an undercurrent of feeling that the PyPA make decisions without considering the community, which I think we need to address. It's important to me that anyone in the community can comment on proposals and be heard (and that's not just "technically has the ability to", but rather it's "knows how to, and has the information they need to do so"). Currently, the PEP process is well known, and "everyone" knows how to participate (more accurately, they know they can, and that if they want to they can find out how to do so). Any new PyPA process *won't* be well known, by definition, and when decisions made using that process impact the public, there is naturally going to be a feeling that those decisions were made by an exclusive group. One way we can mitigate that is by pointing at a well-publicised, dirt simple process for people to contribute, plus a clear process of keeping "the community" up to date with progress of ongoing discussions. That's more than the current PEP process provides, but I think we *need* to provide more, simply to overcome the barrier of being an unfamiliar new process.
Yea I agree the ability to do so is essential, an early draft of this proposal had all discussion happening on pypa-committers IIRC, and I pushed for everything but the actual vote to happen on the PR, precisely so that literally anyone with a Github account could participate. I would say that the fact that the *current* process involves participating in distutils-sig actually makes it less likely that someone *does* participate in that discussion. I know that more than one time I’ve suggested that someone bring something up on distutils-sig, and they balked either because it was “another mailing list to subscribe to”  or because of the past history of distutils-sig and catalog-sig being very toxic places— even though I don’t think that’s the case *now*, the history is still very much in people’s minds, and they avoid it because of it still. We have the pypi-announce mailing list, and we have @ThePyPA and @PyPI on twitter, so one potential here is for accepted RFCs to be published using those communications mechanisms. Although that’s late in the process for someone who might want to participate in that discussion. One potential option I could think of, and I wouldn’t want to actually bake this into the RFC process itself but as something we could do, is setup a simple bot that anytime a new PR was opened on the RFCs repository (we could make it a bit smart, and have it only work on new RFCs) it would trigger a notification email to distutils-sig. That effectively gives us a similar level of visibility for distutils-sig subscribers, and prods people that hey, this new thing exists where we’re having discussions. Another option is if we do adopt this process/model is that we can write a short PEP, accepted by both yourself and myself (as the BDFL-Delegate for packaging standards and PyPI), formally transitioning authority over those areas to the new RFC process. That would be somewhat abusing the PEP process (since at that point it wouldn’t *really* be up for discussion) but would stand as a way for someone who knows/follows only PEPs to know that there is a new process for these specific types. It would also clear up any potential confusion about what process “owns” these things, since there’s a clear marker of “not me!” recorded as a PEP. I do think it is important that if we do things like notify distutils-sig or something like that, that those notifications are simple notifications, and not forking the discussion into multiple places. The discussion should live in a single place, and currently the proposal has that single place being on the PR proposing a new RFC. I think we should also make sure that we document how to write a RFC in packaging.python.org http://packaging.python.org/ somewhere, since that site acts as a really nice central hub for someone who isn’t quite sure where to go for a specific packaging thing. I don’t think a lot of these things need to be, or should be in the actual proposal itself unless there are changes to the actual process that we think should be added or changed to help this. However, I think we should do these extras if we do adopt it, to help with the transition.  With the move to MM3 it’s no longer actually required to subscribe to it to comment on an issue, but if you don’t subscribe you don’t get notification of responses. So you still have to subscribe to get notified of updates, otherwise you have to explicitly pull only, vs something that allows a user to selectively subscribe to threads they care about.