Add dedicated field for ELIXIR node

[unode]

Include a dedicated field to specify the ELIXIR node affiliation.

This is being proposed as a follow up of elixir-europe-training/ELIXIR-Training-SPLASH#132 where node affiliation was being specified with an arbitrary (and inconsistent) style across different contribution sections.

[bedroesb]

@unode Thanks a lot for your contribution! I was wondering making the node look visually different than the Affiliation instead of adding a break line would be nice? In its current shape the card gets higher by default when a node is added. Second though: is for non ELIXIR people clear what the word "node" means? The theme is also used in for example Australian BioComons

[unode]

I initially named the field elixirnode but seemed unnecessarily verbose. Do you think it would be clearer? Perhaps with an underscore: elixir_node?

As for style, I played around with the badges like currently used for author/editor role but didn't really find a visual that I liked. Ended up going with the simplest option that could be further modified if necessary. Do any visuals come to mind straight away?

I also played with the idea of having a built-in link to the node or a flag but not all nodes are countries (e.g. Hub and EMBL-EBI). Also went back and forth between full node name and short code. The last seems to be most frequently used and some nodes (e.g. UK) don't use a long version at all.

[bedroesb]

I have been looking at this from a distance and I have to admit that I am not sure whether this is an improvement. As seen in https://rdmkit.elixir-europe.org/contributors it would really make almost all rows taller. Not putting a new line does not add much besides consistency IMO. Could the consistent use of delimiters not be enforced by the editors of a repo? This way it is more versatile because many of theme have besides a department and elixir node, also a university/institute affiliation and they all better get delimited consistently anyway.

[unode]

The problem is not the consistent use of a delimiter but that using it (more than using it inconsistently) causes some issues - See for instance Renato Alves that shows up multiple times.

Looking for ways to make progress here, if the issue is simply one of style, can we explore other visuals that allow displaying the information without the concern that the rows become taller?

[bedroesb]

The problem you describe is not related to the affiliation? This person just described himself 2 times with different names. It is not only a style thing, but more that the problems are caused by not having a "style guide" that is enforced onto the repo. The fact that Renato Alves put his node in his name should never have been merged in the first place. That is just wrong ....

[bedroesb]

The fact that Renato Alves did not use the affiliation in the first place, means that having an elixir_node attribute would not solve this particular problem. Sorry I just try to understand the reasoning here :)

[bedroesb]

I see now the problem. The name attribute is wrongly used as a way to also add the affiliation. This is not allowed and described in the CONTRIBUTORS file:

# reference maintainers/contributors by their name used in contributors metadata section on the pages.
# Extra metadata that is possible to add:
# Full Name:
#    git: github id
#    email: email adress
#    orcid: ocrid id
#    role: the role of the contributor
#    affiliation: affiliation
#    image_url: absolute path to image (default image from github)

And make sure you always use the same name in the metadata of the page (the list of contributors) and in the CONTRIBUTORS file. This explains the doubles. https://elixir-belgium.github.io/elixir-toolkit-theme/page_mechanics#possible-metadata-attributes-of-a-page also describes:

contributors: List here all the contributors that helped in establishing the page. This will be the full name of the person. Make sure that the person name that is listed can be found in the CONTRIBUTORS.yaml file in the _data directory if you want to link the github id and other contact information.

[unode]

Hi Bert, there are a few different assumptions and points or diagnostics that are perhaps worth mentioning or clarifying:

1. In the use of this template I mentioned above more than one group of people contributed to the creation of different pages. Several of those pages were created at different points in time. Different levels of knowledge of about the template, among other reasons, likely led to the slightly different styles and conventions across pages.

2. One of the aspects causing issues was the presence of an ELIXIR node identifier. In an attempt to consolidate contributor information and identities, I tried to extract the elixir node into a field of its own. The decision to create a dedicated field came from the fact that, as far as I could ascertain from the different files, there were different interpretations of what affiliation meant. For some it meant their organization, for others their ELIXIR node, for others both, separated by a dash - or a comma , and with variations around the spelling (ELIXIR Belgium vs ELIXIR BE). How the node information was to be displayed was also not clear which lead to the multiple ways by which this information was included. Note as well that in that pull-request I am only a contributor and do not have any responsibility over the project.

3. Related to 2. there were also multiple spellings of some contributors. Some were typos, some nicknames. Here the relation between the contributors as shown in the individual page and the complete contributors page was probably not known. The individual page still looks correct, but the aggregate page ends up showing multiple identities. I understand this behavior has been documented, but clearly the documentation wasn't consulted in detail when the content was created.

Given the above, the focus of this pull-request was merely to introduce a field elixir_node to disambiguate affiliation from elixir_affiliation. The field could then also be validated in the template to ensure it matches an existing node (would solve the Belgium vs BE situation mentioned above). As this is an ELIXIR specific template, it seemed adequate to include a dedicated field which would also help address part of the issue linked in the first post of this thread.

While some of the points have to do with how the template is being used, correctly or incorrectly, the inconsistency is something that the template could try to protect from. One solution here could be to fail to build if contributors in individual pages are not present in the global CONTRIBUTORS.yaml file. The current solution assumes that the user ensures this is done. As seen in the use of the template I came from, this may be an unrealistic assumption. That said, I would consider this a separate issue from the one I am trying to address with this pull-request.

So trying to be pragmatic:
4. Do you consider acceptable to include an elixir_node in the template?
5. If yes, and the style included in this pull-request is not acceptable, can you suggest alternative visuals that could be?
6. If adding an elixir_node attribute is not acceptable, how do you suggest we should include this information? If under affiliation, how should it be formatted? If it helps to make things clearer, please provide an example.

PS: There's a minor typo in the CONTRIBUTORS file # orcid: ocrid id probably meant to read # orcid: orcid id

[bedroesb]

Thanks a lot for your extensive insight. I do have some remarks:

1. This is the whole purpose of this theme, community driven contributions to one website. The theme is very actively used in even bigger communities than Splash, but off course with an editorial board in place doing polishing of every pull request, to prevent the exact problem.

This is also related to the other points you mention. I do not believe that without a style guide that is enforced by editors, the problem will be solved. People can still have affiliations in any form or shape, since it is free text. for example INSTRUCT-ERIC / National Center for Biotechnology (CNB-CSIC)

5. I would not make use of the newline for reasons I described before. And the problem with another separator is that it will look the best when it is the same style as the other separators used in the affiliation, coming back at my first point.

Let me have a look in a way of adding the node in a less space taking way. But this does not take my opinion away that the biggest problem is the lack of decision in the community how the contributors should describe their affiliation and enforcing it, hence the creation of this issue ;)

[bedroesb]

Thanks for spotting the type, will correct it now!

[unode]

Thanks Bert, I'll keep an eye on this PR/issue and modify the upstream PR once there's a final decision and implementation here.

Let me know as well what you think about the idea to fail to build if fields (or other content) are not used in the intended way.