Skip to content
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

Proposed workflow #1

Open
abbycabs opened this issue Nov 20, 2014 · 7 comments
Open

Proposed workflow #1

abbycabs opened this issue Nov 20, 2014 · 7 comments
Labels

Comments

@abbycabs
Copy link
Member

We're currently testing this proposed workflow for the Contributorship Badges project:

  1. Once an article is published, the publisher notifies the badging system and authors.
  2. Authors will fill out their roles based on the contributor taxonomy.
  3. Badges, crediting authors for the work they contributed, will appear next to the authors names and link to their ORCID page.
  4. The ORCID page will display all badges earned by that particular author.

We would love to hear your feedback below! We want to make sure this process is positive and beneficial at each step. We will be continually refining this workflow and experience as we go through the prototyping process.

@danmaclean
Copy link

I think there's a delay here that could be bad for getting the notice that junior authors deserve. By only notifying the badging system after the paper is published there is a potential lag. Presumably a large number of interested people will pick-up on and grab the paper as soon as it pops up on their radar, if the badges haven't gone on yet, the authors won't be recognised by that reader unless they go back to the paper/website.

I think step 1 and 2 should happen at submission, step 3 and 4 on acceptance/publication.

@abbycabs
Copy link
Member Author

@danmaclean - good point. We've discussed 1) happening upon acceptance, before publication.

@mellybelly
Copy link

Would be great if the badges could generate triples/linked data that can be used in support of transitive credit, evidence, and reproducibility. Can help with this.

@abbycabs
Copy link
Member Author

That sounds great @mellybelly, thanks 👍

@dwhly
Copy link

dwhly commented Jan 2, 2015

I'd like to explore the notion that these roles are not assigned exclusively by publishers. Why shouldn't the badging taxonomy be mostly complete before the article is submitted? Most of these roles are ones that are involved in getting the paper to submission, and only a few post-submission. The paper could be submitted with credit already given for who did what work.

Here are a few reasons why that might make sense:

  • Pre-print services such as arxiv are not "traditional" publishers, but papers should be still able to be submitted to arxiv with the roles assigned already, and then those roles can be passed through when and if the paper gets ultimately published by a journal--instead of later being reassigned in duplicate by them. In that way, the roles can be seen and associated with the paper even if its never "published", and one's ORCID bio could reflect the work that was done by the individual regardless of its eventual publication status.
  • There's no reason why different roles cannot be assigned by different authoritative entities at different points in the lifecycle. Authors could assign their roles prior to submission (one time regardless of how many times a paper is submitted) and editors and reviewers could then assign their roles via a publishers badging system later. All roles associated with a paper could be fetched at the point the paper is read, potentially asserted by multiple badging systems (?).
  • Often times a paper is simply posted on the author's academic webpage, perhaps as a PDF. With the emerging capabilities (particularly of annotation systems) to simply provide layers over documents wherever they are, there's no reason that roles and badges shouldn't be discoverable on any version of the paper wherever it is, so long as the paper can be uniquely identified (by DOI, arxiv ID, unique PDF fingerprint, google Scholar reference or whatever technique).

The recent article in nature, here, seems to hint that assigning badges could be done during the process of "developing" the paper (though by "manuscript-submission software"). I assume this could include authoring systems such as Overleaf (nee WriteLaTeX) or Authorea, etc.

I'm curious too: Badging an article sounds an awful lot like an annotation. I'm wondering if it makes sense to explore how annotation systems could also allow people to ex-post claim a certain role in a paper, or for others to assert the same.

(@zimeon may have thoughts from arxiv's perspective, @lpaglione from ORCID's)

P.S. I'm here because this article suggested this issue was the right place to comment about workflow.

@lpaglione
Copy link

Hi Dan,

Yes, you're right. In some workflows it makes sense to assign these roles significantly before submission or completion of scholarly activity. In fact, during the MozFest one thing that was discussed a bit was how to best engage researchers in this role assignment. One suggestion was to have a tool that helped people carry out their roles, perhaps in the form of team management, project management or reporting update, which would necessitate assignment of roles as part of the process of working in a team to do the research itself (vs reporting roles at the end, or even once the research is done and the authoring process has begun.) The idea would be that such a model would have roles assigned because it helps get the work of research and discovery done, which may have more uniform value to the individual researchers than reporting roles as a part of a post-publication attribution process, where individuals may value role assignment differently based on their personal perceived benefit in assigning and confirming the roles. (For example, the first author may perceive no additional benefit from participating in role assignment, while someone whose name will not appear in the author list, but participated in the work may perceive a greater value in role assignment.)

Specific to ORCID - I think there is benefit in recognizing roles no matter when the roles are assigned, and regardless would encourage the inclusion of an ORCID iD with individual's names to help with name disambiguation.

Interesting comment about the badges being like an annotation system. I guess they are like a very specialized one. Since badges are so often tied to achievements, I think they may have an advantage in individual recognition over a more general annotation system. That said, I'm guessing that there are practices used in annotation that could be applied to badges in an interesting way for this specific use of contributor roles.

@dwhly
Copy link

dwhly commented Jan 4, 2015

Interesting comment about the badges being like an annotation system. I guess they are like a very specialized one. Since badges are so often tied to achievements, I think they may have an advantage in individual recognition over a more general annotation system. That said, I'm guessing that there are practices used in annotation that could be applied to badges in an interesting way for this specific use of contributor roles.

Also: Web annotation systems consider annotations as things that attach to a target (like a journal article). The notion that there are often multiple copies, and even multiple versions of that target is likely common to both annotations and badges. Annotation systems will also increasingly integrate annotations from multiple sources on the same target, in the same way that there might be multiple sources of badges for any given article (via authors and publishers). There are differences between them too, but enough similarities that some of the same mechanisms (like matching different copies of an article) might be shared.

aid29 added a commit that referenced this issue Jul 10, 2015
Try to fix the environment variable load pbm
Alicole added a commit that referenced this issue Sep 2, 2015
badges-mozillascience-org.herokuapp -> badges.mozillascience.org
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants