-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scope limit to datalad-core? #1
Comments
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. |
@bpoldrack This makes sense to me too! |
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 ;-) |
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. |
it seems the agreement was reached: datalad (core) + mentioning of related extensions and other components in the "ecosystem". feel welcome to reopen if there is more to discuss |
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.
The text was updated successfully, but these errors were encountered: