Not much to add that hasn’t been said... I think Nathaniel’s picture would be great explanatory material to accompany any announcements.
With regard to everything but the vote happening on github I find myself mostly with Paul, although I think if we had a broader solution for internal and intraproject communication (the first thing we had discussed) this would be a bit easier. Github has advantages that I acknowledge and per Paul’s points which I’m sure at least in part refer to the process of moving pipenv into the pypa, putting those kinds of conversations on github would at least give the community a more obvious place to participate.
From my experience so far, though, even though those discussions were public, people who didn’t participate still feel angry at us or at the pypa in general for ‘hiding the process’ or ‘recommending’ anything that doesn’t work all the time. Packaging is a core, central use— when someone sits down to begin doing some python thing, they start with <insert pypa tool> as a builder or installer or whatever. When those things don’t work, it’s not even possible to begin your python, so while we can move to an RFC process and such, I expect this is going to be seen as an implementation detail where people’s frustration is probably more about oversight and collaboration (why does pipenv reimplement pip things and sometimes not fix them whenever pip fixes them etc, per the recent discussion on distutuls-sig).
Dan Ryan // pipenv maintainer gh: @techalchemy
On Aug 31, 2018, at 8:45 AM, Paul Moore firstname.lastname@example.org wrote:
On Fri, 31 Aug 2018 at 12:49, Donald Stufft email@example.com 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 _______________________________________________ PyPA-Committers mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/