Streamline instructions for maintaining author pages

[nschneid]

Add new one-stop page with instructions for maintaining author pages. Originally #7315. Pertains to issue #7230.

[davidweichiang]

I feel that there might be other common cases not covered here. If I verify my author page, then file a split/disambiguate request, thus making my name ambiguous, then I write more papers without an ORCID, those papers will go to the unverified page, right? What kind of request is needed to fix that?

[mbollmann]

I feel that there might be other common cases not covered here. If I verify my author page, then file a split/disambiguate request, thus making my name ambiguous, then I write more papers without an ORCID, those papers will go to the unverified page, right? What kind of request is needed to fix that?

A request to the conference organizers to please include ORCIDs in their ingestion materials. :)

You would have to go to the unverified page and request to merge these papers with your author page. Scenarios like these are one reason I would like to get rid of the split/merge terminology.

[github-actions]

Build successful. Some useful links:

• Complete site preview: https://preview.aclanthology.org/info-author-pages
• Potential changes of interest: Info: author-pages, Info: names, Info: orcid

This preview will be removed when the branch is merged.

[nschneid]

This is true only if the name is known to be ambiguous (there are two verified authors with the name). We assume that most names are unambiguous, so papers missing ORCID info will match by default. To override this default and fend off future papers from other authors, a flag can be set for that author in the database.

[davidweichiang]

Sorry, my mistake. So the line "Afterwards, ..." as well as the sentence "This behavior can be fixed with a one-time request" should be deleted? Should it be documented that an author can request the flag to be set?

[nschneid]

Personally I'm happy to just omit this detail. It's an edge case that we can address by setting a flag if somebody notices a recurring problem with their page.

[nschneid]

Thanks @davidweichiang, this is great! My main concern is how this relates to the split and merge instructions on https://aclanthology.org/info/corrections/. Can sections of that page be simplified to link to this one? Or does it contain some complementary details?

[davidweichiang]

Sorry, I did not know about the instructions in info/corrections. I think this comes back to my earlier question about whether the instructions should be collected into one page or split across pages.

In principle, I think there's nothing wrong with redundancy between pages, but maybe some terminology needs to be made more consistent between the two pages (split/merge vs. add/remove)? After @mbollmann's comment about split/merge, I changed to add/remove. Since a person can now only own one page, I think it makes sense to think about changes as adding to and removing from that one page.

[nschneid]

I am fine with add/remove for a verified page (though if somebody has papers on two unverified pages under different name variants, "merge" seems like a natural label for that I guess?).

[nschneid]

Also: If we are giving instructions on info/author-pages, the bottom of info/verification can simply link to those instructions.

[davidweichiang]

I'll be happy with this as-is, but should we keep working on this PR until it resolves all the questions raised in #7230?

• I agree that the FAQ on "How can I submit corrections to papers?" could be reduced to a link to the corrections page. But perhaps a new FAQ should be added related to the transition, like "How do I verify my author page and submit corrections to it?"

• Regarding split/merge, as stated above, now that we have the category of a verified author page, all of our instructions should be written from the perspective that every author should verify if they haven't already, and only afterwards can they request corrections. (If I'm not mistaken, the corrections form requires an ORCID.) So add/remove makes more sense.

• explicitly state each person should have one, not multiple, ORCID iDs: agreed, I can add this somewhere

Regarding generally removing redundancy, there are three info pages about authors and author names (names, orcid, verification) and this PR adds a fourth, which wasn't my intent. Ideally I would think we'd have one page for user documentation about authors and author names, and one page for technical documentation.

Related question: where on the Anthology website are the links to all these info pages?

[nschneid]

Let's keep this PR to things related to authors and author pages. Other improvements to docs can go in another PR.

Current incoming links into these pages that I'm aware of:

• Corrections page linked in the menu bar at the top
• Blog post under News announcing the transition
• Icon on ORCID-less author pages
• GitHub issue template for author page corrections

There is also a secret directory to info pages:
https://aclanthology.org/info/

If we can keep this PR simple and add author-pages as the user-facing instructions, while making the orcid & names & verification pages the more technical ones, we could gradually consolidate the technical pages later.

[weissenh]

Regarding generally removing redundancy, there are three info pages about authors and author names (names, orcid, verification) and this PR adds a fourth, which wasn't my intent. Ideally I would think we'd have one page for user documentation about authors and author names, and one page for technical documentation.

I believe there are two points :

• transparent structure:
  • having multiple pages without an easy-to-view table of contents/structure on what pages are available at all
  • with adding inter-page and intra-page links with various link text it's less transparent where links will lead me to and how to navigate back (do all pages link back to author-pages.md?)
  • on a longer page we could also add a table of contents on the top or a sentence saying "This page tells you how to do A (link to §A), B (link to §B) and C (link to §C)
• redundancy as a risk: that information becomes out of sync, leading to confusion

If we can have just two pages, that's great. But the intent and structure of each page should be clear. If we have 7 small ones that's ok too, as long as they are easy to navigate and their title/link is descriptive enough.

re: author-pages.md: What I haven't seen so far is the mention of metadata corrections. Metadata corrections could also make papers "move around" and they are usually processed faster (with the upcoming change of author page templates this advantage might become smaller). So the answer to How to remove/add papers from your author page might be a metadata correction in some cases. Would it be ok if users are surprised/annoyed when I ask them to submit a metadata correction when they have just opened an author page request?

Is there an easy way to visualize the processes? Maybe a flow chart how it is decided for a newly ingested paper where it ends up (on unverified, on your or your namesakes verified page) answering "why has this happened?", and another on how to decide which action is needed to correct a problem with the author page answering "how do I fix this?".