I have been thinking that it would be worthwhile to change the README to give a tour of some of the unique functionality in the library (e.g., computing and displaying pseudospectra, fast computation of nonsymmetric eigenvectors, lattice reduction of complex bases via BKZ, and arbitrary-precision sparse Second-Order Cone Programs)
I also don't particularly care about Gitter vs Slack, though I find Gitter to be a bit lighter weight and like openness. But I do think that having too many mechanisms just causes dilution, reducing the chance that people will connect and find the community vibrant and supportive. But I'm not very active with Elemental so this comment shouldn't carry much weight.
So don't feel like you need to poll this medium; it is targeted at people perusing github that have a question
There is a lot to be said for HBR avoiding a sense of "us" vs. "them"
Does HBR require Jack to log his internal monologue while developing Elemental? The "no private (substantive) discussions" clause of HBR may place an undue burden upon projects that have a small number (especially one) of contributors. Specific to me, do Sayan and I have to publicly document every substantive design discussion we had about RMAxpy for a related pull request to be in compliance with HBR?
Yeah, I think it's a very rare project for which a strict HBR is necessary/desirable. But the principle that not just decisions but also the data used to justify the decisions take place in a public forum is important if you want a community to feel open and a meritocracy in which anyone can influence decisions to the extent they bring solid data and rationale to the discussion. If you want community members (that may be developers or future developers) to feel disenfranchised, just make decisions in private and wave your hands about private information. Note that many users may be fine with this approach; they need only trust that you know what you're doing and have all the information. But it stifles the kind of thinking and curiosity that fuels an active and enticing developer community.
In the spirit of HBR, the next major step that I'm planning in finishing the development of the Aggressive Early Deflation Schur decomposition in https://github.com/elemental/Elemental/blob/47489373a0f632e48935af81ab4533b4ee08ccce/tests/lapack_like/HessenbergEig.cpp
The callstack maintenance has just been greatly improved and simplified via the usage of a macro
DEBUG_CSE which creates a CallStackEntry via DEBUG_ONLY(CallStackEntry cse(EL_FUNCTION)), where EL_FUNCTION maps to __PRETTY_FUNCTION__ if it is available and __func__ otherwise: elemental/Elemental@bc0cb4a
Jack: If you want to automate testing with the Intel toolchain, https://github.com/nemequ/icc-travis (https://github.com/jeffhammond/icc-travis) has details. I will try to work up a PR...
(there is now sequential and distributed arbitrary-precision SVD via a custom bidiagonal QR algorithm implementation in the style of Demmel and Kahan's hybrid zero-shift approach)