Scope limit to datalad-core?

[mih]

Intuitively, I'd say we limit the scope to datalad-core. Leaving space for other focused publications. The notion of extensions is already in the manuscript. Just want to make this explicit.

[bpoldrack]

I think to some extent metalad should be an exception in so far, as there is a metadata layer in core. I think we would probably like to mention that there is an extension in development that basically aims to replace that approach. Not exactly sure how to point to it w/o diving into the topic really, but I'd rather make that point than pretending there's no such thing in core or make the impression that the approach in core is what we want.

[mih]

@bpoldrack This makes sense to me too!

[yarikoptic]

extensions should have a prominent mention in the paper (and some listing) as not only a way to extend but also to prototype functionality. So we should mentioned a good number of examples and metalad could be one with not yet decided destiny -- it might as well end up outside of the core (and builtin metadata functionality ripped out/migrated to metalad), and get its own joss paper ;-)

[bpoldrack]

Yes, metalad should get its own paper in any case, I think!

Otherwise I wouldn't spend a lot of space on existing extensions, just the notion and purpose of the concept itself. A supplemental listing seems sufficient to me.

[yarikoptic]

it seems the agreement was reached: datalad (core) + mentioning of related extensions and other components in the "ecosystem".
metadata handling is mentioned only very loosely, metalad for now listed as an extension where new functionality being "cooked" ;)

feel welcome to reopen if there is more to discuss