On Fri, 31 Aug 2018 at 12:49, Donald Stufft <donald@stufft.io> wrote:
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.
There *are* some people who argue that they won't participate because they specifically don't want to have a github account. But I think at this point, that's their choice to exclude themselves, and we don't need to worry too much about that. Just thought I'd mention it so it's explicit.
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 still have to think about this. Personally, I've found that I'm much *less* likely to get involved in debates on RFCs when they are on PR conversations than when they are on a mailing list. That reflects my personal workflow and how I choose to allocate my volunteer time, so again it's something of a "my choice" issue, but I will admit that it makes me feel excluded from decisions (I'm basing this on the odd Python PEP, and some packaging discussions, that I didn't get involved in, so the sample size is small, but it feels significant to me). I do feel it's harder to have subthreads, side debates and digressions on a github issue. And it's more or less impossible to start a second related but independent thread. There are plusses and minuses to this of course - rambling discussions can be the death of a proposal, but so can missing peripheral but important points. Also, I find the differences between github and email etiquette (specifically, the level of quoting of relevant context) makes complex debates much harder to follow on github. I'm not arguing *against* github, as such. More arguing that different tools have different strengths and weaknesses, and excluding certain tools can harm the process. Of course, so can having to monitor too many tools - but that argument works both ways (what's "yet another mailing list" to some people is "yet another github PR to track" to others).
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.
Agreed - but equally if the process is complex enough that people can't get it mostly right just by guessing, we've over-engineered it :-)
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.
Again agreed, but if they aren't in the overall governance proposal, then they should probably be in another separate proposal. I *don't* think it's OK for us to change our standards definition process without that change having the support and involvement of the community (even if it's only "we've decided on this new process, the discussions are over here in this public archive, before it's signed off shout if you have any objections" - at some point things get too recursive and we end up agreeing on how we agree on the process for agreement :-)) Paul