Goal of this A&P document/process

[danielskatz]

Based on discussion in Section 1 of A&P google doc

• What's the goal of this document? And how does this related to the software citation principles document? Are we creating an updated set of principles? Determining the work the FORCE11 group now needs to do? Adding detail beyond what's in the software citation principles?
• Perhaps think about this as the next layer of the discussion?
• List of challenges? Guidance for the group on how to address challenges?
• A way to organize guidance that we provide to others? (and to explain where we still have questions and uncertainties)
• Ultimately it should prove a number of case studies where examples from different communities, software projects in different languages manage to get the software citation principles as closely implemented as possible. (Ilian)

[AlastairKelly]

I think primarily it is that fourth bullet point: A way to organize guidance that we provide to others, and to explain where we still have questions and uncertainties. I think community-specific examples will be part of that. (fifth bullet)
For our working purposes, it organizes the guidance we need to develop and write.
(Secondarily, it seems to also be helping clarify our scope and unify our language!)

[moranegg]

I believe the document should be next step after the software citation principles on how to cite software. In the principles a couple of citation use cases are described an a set of guiding principles were defined.
Still we lack specific tools and recommendations.
As a next layer, guidance to different actors on what's already available and what needs to be discussed and developed.

i agree with @AlastairKelly, that it will be also great to unify our language with this document, even if we don't agree on the usage of every term, we will have some clear definitions.

[ghost]

I suggest that we have a subsection of the Introduction (Section 1) called "Purpose and Goals of this Document". The idea would be to help readers identify who should read this document and how they should use it.

For example: software developers: they will use this document to stay up to date on practices they should be using. Editors of journals or peer-reviewers: they will use this document to see if the software used in publications is being cited properly. And so on.

There is currently some info about this in Section 6.1 (still in list rather than narrative form).

[npch]

On the call, @lkellogg @dbouquin @npch and @danielskatz suggested that the document should be aimed primarily at those stakeholders who had a level of expertise or championing that was above that of the "ordinary" person who wished to understand how to do a specific software citation use case (these people would be pointed to other slimmer, more specific primers).

These people might be those at communities, institutions or journals who support researchers, or software citation champions.

It would present a view of the current state of software citation practice and enable these stakeholders to get up to speed with the current practice of software citation, the language and terminology that is being used, and the challenges that are still to be addressed.

(NB: I think of this as being the difference between user documentation and developers documentation)

[danielskatz]

Another question is where this document goes, what we do with it, and how updates/follow-ons are made:

Options

• web page
• wiki
• paper
• preprint
• series of preprints

Ideas:

• communities might build further documents based on this, more specific for their communities
• later versions of this will need be written, maybe with small changes

[dbouquin]

@dbouquin will try drafting purpose statement along with Issue 65

[dbouquin]

Draft:
Principles to guide software citation practices have not fully mitigated issues that impact software citation implementation. This document provides an explanation of current issues impacting scholarly attribution of research software, organizes updated implementation guidance, and identifies where best practices and solutions are still needed.

[ljhwang]

Some questions to consider: Are we comfortable that Closed Source is always associated with a Company? In both cases is “entity” (or another term) perhaps a better generalization? Similarly, are we comfortable citing specific technologies? For example, is Software Heritage the only or just best method to achieve goals? Best, -Lorraine ***************************** Lorraine Hwang, Ph.D. Associate Director, CIG 530.752.3656

…

On Dec 4, 2018, at 7:08 AM, Daina Bouquin ***@***.***> wrote: Updated diagram <https://user-images.githubusercontent.com/5713878/49451115-78ec7c80-f7ac-11e8-8c53-f95690d886e2.jpg> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AESQX22ghZY8xgeIvjc9Z85H9lcuva0Nks5u1o_TgaJpZM4XIMmy>.

[danielskatz]

Are we comfortable that Closed Source is always associated with a Company? In both cases is “entity” (or another term) perhaps a better generalization?

I don't see what you are referring to, can you tell me what section(s)? In general, I agree with you.

Similarly, are we comfortable citing specific technologies? For example, is Software Heritage the only or just best method to achieve goals?

Good question - right now, it seems like the only way, but we should probably generalize a little too.

[ljhwang]

wrt "Company" - The comment was probably tied to your comments in section 3.1 from the point of naivete on what else may fall under this category and how they may track releases. Are there noncorporate entities that have closed source software?

[danielskatz]

I feel like the "perhaps" language makes this ok. If you have something additional to suggest to make this clearer, please make a suggestion in the document.