Roadmaps:  kdb+ WG and larger Data Tech.  Any demand for new WGs?

Sam hopes to put the Roadmap up on the Wiki when time permits.

No suggestions for new working groups under the Data Technologies program were suggested.

Alvin reiterated that a Knowledge Graph WG might be interesting once some of the key ideas around SRD are nailed down.

Alok: Python + q could benefit from a unified ecosystem.

Jason: Could look to Python best practices and borrow.

Sam: Wanted a standard for how "diamond dependencies" should be handled.  (Any special implications if going cross-language such as through embedPy or PyQ?)

Alvin: Stressed the difference between simple-to-configure environments for individual users vs. strong versioning for reproducible builds / deployment / integration.

Aaron: We should make note of fundamental incompatibilities between q and Python and which practices can't be carried over in a practical fashion.

Alok: Offered an example of Python supporting import of individual functions.  Would be like making q load a subset of a script.

Aaron: Similar effect could be achieved if the script is responsible for the namespace creation rather than the module loader.  Standard to have scripts use only local names and allow \d (backslash d) to set the namespace?

Alvin: The \d idea won't work with q in its current form since it only allows one level of namespace.  i.e. \d .foo works.  \d .foo.bar does not.  Will bump the namespacing thread on the data-tech-kdb mail group for the benefit of the new joiners.

Getting some code into GitHub?

Alvin: Continuing to chip away at qdoc so that it meets various criteria set forth by the internal OSS gatekeepers.

Sam: Suggested logging might be low-hanging fruit.

Alvin / Aaron: Logging can get complicated, such as supporting: logging from plugin code, log file rolling capability, logging from slave threads or Multi-Threaded Input Mode.

Sam : Revisit security handlers for standardization?

Alvin: Will send out an email to kick off discussion about that.

Aaron: Has extensions for dbmaint.q that he's willing to offer.

Alvin: Will check with FINOS about the logistics of forking dbmaint.q.  HDB consistency checker also a possibility.

Aaron: Standard "getopt" could be useful.

Peter S.: Also suggested looking at TorQ for ideas.  (He was once an AquaQ employee.)

Sam: Any untested ideas should go on an "incubating branch", not master.

Alvin: Will check with help@finos.org about whether any special setup required for that.

Sam: Thinks I should be able to do it myself on GitHub.

Sam: We should have a CONTRIB.md which includes info on getting an ICLA.

Alvin: Will check with help@finos.org on that.