SciPy 2015 developer meeting

Logistics: the main meeting will be July 7 (the second day of tutorials, the day before the conference proper starts) at the ATT Center (same place as the conference), where we have a room reserved for 15-20 people with a whiteboard and TV with audiovisual hookups. (Many thanks to Jill Cowan and the SciPy organizers for arranging this!)

Notes towards agenda (please add to this!):

• Project / organizational stuff:

  • We should formalize our relationship NumFOCUS (requires paperwork etc.)
  • Should we be formalizing our governance more generally? (E.g. procedures for decision making, assigning commit bits, etc.)
  • Release process -- is it doing what we want? Can we do better?
  • Getting more developers / maintainers
    • "If we had money, what would we spend it on?"
    • Jaime suggests GSoC as a potential source

• Managing change:

  • Clarifying our policy on API compatibility -- official guidelines on what/how to deprecate, especially with regard to the C-API. How do we balance the trade-off between progress and compatibility.
  • ABI compatibility plans (cf. #5888)
    • Is there any way to get out of the 100%-locked-in ABI we currently have without causing unacceptable collateral damage? (Example of something to aspire to: Python itself breaks ABI on every release but it's no big deal.)

• Code-related questions:

  • Possible 2-5 year roadmaps:
    • Continue on as we have been?
    • Focus on putting down the shades and locking up to make way for another project?
    • numpy2?
    • Alternatives?
      • Nathaniel will sketch out a possible roadmap about decoupling arrays (data container) / dtypes (data type) / ufuncs (data operations), with the general goal of making it possible to swap in new container types, write new dtypes, and have ufuncs more flexibly work with both, with the general goal of letting import numpy remain the main API entry point even as new types of array libraries come into prominence?
  • using Cython in the NumPy core?
  • Making np.random implementation evolveable
  • Possibilities for making vectorized indexing less confusing (e.g. the idea of an .oindex attribute)
  • Future of the Matrix class. Have an official position on the future of the Matrix class.
  • Ditto for masked Arrays. (Chuck says: Masked arrays are an important part of the scipy stack and we should modernize them and make them more maintainable. I like the idea that masked arrays should be a container class, which probably means that either the current inheritance from ndarray needs to be hidden, or possibly a new implementation needs to be done. This also ties into the numpy_ufunc discussion.)