On 18 June 2016 at 10:36, Ethan Furman <et...@stoneleaf.us> wrote: > One of the big advantages of a SIG is the much reduced pool of participants, > and that those participants are usually interested in forward progress. It > would also be helpful to have a single person both champion and act as > buffer for the proposals (not necessarily the same person each time). I am > reminded of the matrix-multiply PEP brought forward by Nathaniel a few > months ago -- the proposal was researched outside of py-dev, presented to > py-dev when ready, Nathaniel acted as the gateway between py-dev and those > that wanted/needed the change, the discussion stayed (pretty much) on track, > and it felt like the whole thing was very smooth. (If it was somebody else, > my apologies for my terrible memory! ;) > > To sum up: I think it would be a good idea.
I'm coming around to this point of view as well. import-sig, for example, is a very low traffic SIG, but I think it serves three key useful purposes: - it clearly indicates that import is a specialist topic with additional considerations to take into account that may not be obvious to developers touching the import system for the first time - it provides a forum to collaboratively craft explanations of proposed changes that should make sense to folks that *aren't* specialists - anyone that wants to become an "import system expert" can join the SIG and learn from the intermittent discussions of proposed changes distutils-sig is an example at the other end of the scale - while distutils-sig and python-dev subscribers aren't a disjoint set, those of us that fall into the intersection are a clear minority on both lists, and can act as representatives of the interests of the other group when needed. As far as names go, my vote would be for "paranoia-sig" - it nicely avoids any risk of folks submitting security bugs there instead of to the PSRT, and "We're professionally paranoid, so you don't need to be" is an apt description of good security sensitive API design in a general purpose language like Python :) Cheers, Nick. P.S. Hopefully we could get some of the Python Cryptographic Authority folks to sign up, just as distutils-sig is a point of collaboration between python-dev and PyPA. "Secure software design in Python" covers a lot more than just the standard library, since in many cases you really want to reach beyond the standard library and grab something like cryptography or passlib, or delegate the problem to a domain specific framework like Django or the relevant components of the Flask or Pyramid ecosystems. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
