On Aug 31, 2018, at 4:07 AM, Paul Moore <p.f.moore@gmail.com> wrote:

On Fri, 31 Aug 2018 at 01:52, Donald Stufft <donald@stufft.io> wrote:
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[1], 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” [1] 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 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.