texture
texture copied to clipboard
substance
Author names
Description
The displayed name for each member of the author list.
User stories
Author
- (1) As an author, I want to be able to see which parts of an author name have been designated first name(s) + initials, and which surname(s) so that I can make sure this has been done correctly.
- (2) As an author, I want to be able to edit the first name(s) + initials and surnames for authors so that I can correct any mistakes.
- (3) As an author, I want to be able to add a prefix/suffix to an author so that I can ensure they are distinguishable from a parent or child with the same name (e.g. Fred Smith Jnr).
- (4) As an author, I want to be able to remove a prefix/suffix from an author so that I can correct any mistakes.
- (5) As an author, I want to be able to check the order the authors appear in the full author list so that I can make sure this information is correct.
Production staff
- (6) As production staff, I want to be able to change the author order so that I can correct mistakes on behalf of the author.
- (7) As production staff, I want to be able to add a new author so that I can include any missing authors.
- (8) As production staff, I want to be able to remove an author so that I can update the authorship of the article if required.
But what if . . . ?
Considerations
- Some authors only have one name. eLife has accommodated this by making first names optional.
- eLife only allows suffixes for authors and then only a select few (we don't allow PhD or MD for example, just Roman numerals, Jnr and Snr). Other publishers may allow other suffixes and may also allow prefixes.eLife will control for their own requirements via Schematron validation outside the scope of Texture
- We are not putting a
<role>in for authors to indicate they are authors (eg<role>Author</role>; any person listed in the author<contrib-group>will be assumed to be an author.
XML requirements
Authors are tagged as <contrib> elements in a <contrib-group content-type="author">.
Contrib must have a child <name> which in turn must have a child <surname>, and can have a <given-names> and a <suffix> or <prefix>. In rare instances string-name[@content-type="alias"] may be used as an additional alias (additional to the name).
<article-meta>
…
<contrib-group content-type="author">
<contrib>
<name>
<surname>Gilbert</surname>
<given-names>James F</given-names>
<prefix>Dr.</prefix>
</name>
...
</contrib>
<contrib>
<name>
<surname>Atherden</surname>
<given-names>Frederick P</given-names>
<prefix>Captain</prefix>
<suffix>III</suffix>
</name>
...
</contrib>
<contrib>
<name>
<surname>Zoolander</surname>
</name>
...
</contrib>
<contrib>
<name>
<surname>Tucholsky</surname>
<given-names>Kurt</given-names>
</name>
<string-name content-type="alias">Peter Panter</string-name>
</contrib>
</contrib-group>
….
</article-meta>
Mock ups
Proposal
We are not putting a
in for authors; any person listed in the author will be assumed to be an author.
think this does not belong here. Otherwise the requirements are clear.
eLife only allows suffixes for authors and then only a select few (we don't allow PhD or MD for example, just Roman numerals, Jnr and Snr). Other publishers may allow other suffixes and may also allow prefixes.
this is possible, but is it really MVP? we would suggest to move such things into separate feature-request tickets to be addressed in later iterations.
this is possible, but is it really MVP? we would suggest to move such things into separate feature-request tickets to be addressed in later iterations.
We've agreed to sign off on all eLife requirements by end of July so we are not splitting out MVP from eLife production ready. If you want to split out the development of this feature so it's done later down the line of what you agree with eLife for a timeline, that's fine for us. We need it to go live.
I don’t understand why you require this to go live. Typing out PhD in a text field and do quality checking works.
Having auto suggestion is a convenience, that could be something agreed with other journals (the values) and delivered after the eLife launch?
On Fri 26. Apr 2019 at 13:07, Melissa Harrison [email protected] wrote:
this is possible, but is it really MVP? we would suggest to move such things into separate feature-request tickets to be addressed in later iterations.
We've agreed to sign off on all eLife requirements by end of July so we are not splitting out MVP from eLife production ready. If you want to split out the development of this feature so it's done later down the line of what you agree with eLife for a timeline, that's fine for us. We need it to go live.
— You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/substance/texture/issues/1252#issuecomment-487019612, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAAW42447QEHMZSO3VWFS3PSLO6JANCNFSM4HGTKDAA .
@michael can you explain what you mean by auto suggestion? This is not mentioned here in our ticket. We've not asked for it here. We're being explicit about what we allow/do, but not expecting Texture to limit the field. Does that clarify?
@Melissa37 I'm referring to this consideration.
eLife only allows suffixes for authors and then only a select few (we don't allow PhD or MD for example, just Roman numerals, Jnr and Snr). Other publishers may allow other suffixes and may also allow prefixes.
Think Texture should allow any free form text, for suffixes (since everything could be used in theory). However auto suggest can help putting consistent terms. In order to enforce eLife's rules the validator would be used displaying a warning if the value is not allowed. I wonder however if auto-suggest and the validator are required to be part of the first production-ready version, or if they could be added in a later iteration, making the QC process faster. Just trying to find the minimal scope for author names to be implemented.
Agreed. We're happy to restrict this in our Schematron validation outside of Texture. As a vanilla tool, Texture should not be a restricted tool.
Sorry, it's a communication issue, that's what I meant when I said:
We're being explicit about what we allow/do, but not expecting Texture to limit the field. Does that clarify?
We're happy to restrict this in our Schematron validation outside of Texture. As a vanilla tool, Texture should not be a restricted tool.
Makes sense. Thank you! Can you maybe remove those considerations from this ticket for brevity, and create a separate feature request which we can pick up later? Because the idea for auto suggestion and validation during editing is good i think.
Can you maybe remove those considerations from this ticket for brevity
I'd rather update the considerations to indicate eLife will deal with that requirement in our own validation tools. That way it's covered in the open so others wanting to use the tool would know the expectation and eLfe have tracked what we've agreed to! Let me know if that's OK and I'll update.
and create a separate feature request which we can pick up later? Because the idea for auto suggestion and validation during editing is good i think.
We'll leave this for now, we're maxed out doing the user stories so we can come back to it later. Also, it's editorial style specific whether publishers would want, eg Prof, Prof., Professor or Jnr, Junior etc
Thanks!
Ok, update is fine too. :)
We are not putting a
in for authors; any person listed in the author ` will be assumed to be an author.
But <role> will be used for contribution roles right (CReDiT taxonomy stuff)? See Roles section in the proposal: https://github.com/substance/texture/issues/1269
Have updated the consideration to be clearer as to what we mean:
We are not putting a
<role>in for authors to indicate they are authors (eg<role>Author</role>; any person listed in the author<contrib-group>will be assumed to be an author.
For editors we add a role to indicate what their role in the paper is, eg `
Use of
@michael
Updated consideration: eLife only allows suffixes for authors and then only a select few (we don't allow PhD or MD for example, just Roman numerals, Jnr and Snr). Other publishers may allow other suffixes and may also allow prefixes.eLife will control for their own requirements via Schematron validation outside the scope of Texture