Prepare community feedback

[sdruskat]

• Identify what feedback we want to get from the general community, and
• how we will collect this, along with
• communication materials around this.

Also,

• Gather taxonomies here as well

Feedback collection

Similar as for #47, decide governance/decision processes for definition draft and feedback, i.e., how feedback will be

• filtered,
• used, and
• credited.

Also see Types of feedback in #47.

Publicization of invitation to give feedback

To be distributed through ReSA.

It may be worth distributing this via additional organizations that have reach, e.g.:

• FORCE11 (working on research communication)
• RDA (large), e.g., via Software Source Code IG
• RSE Associations (the impacted group)

[sdruskat]

Ask community to:

• describe their project and describe how it would handle authorship
• Should the following activities count towards authorship?
  • funding acquisition
  • training
  • publicity
  • community work
  • Vice versa: are there any contribution roles / activities that cannot count towards authorship?
  • What are "criticality" thresholds for specific contribution roles to be considered authors?
    • give examples and ask if the community agrees, e.g.
      • has a PI who has been integral in making sure that the different parts of the software were implemented met criticality for authorship?
• Check if wording in criterion 2 ("implementation of software") works for them or if there are better terms
• Check if wording in criterion 1 ("needs ideation/assessment") works for them or if there are better terms