Community Directory

[NickSto]

This is a central issue for all Community Directory ideas.

This was the subject of a GCC 2021 CoFest project. Here are some meeting notes, and here are some mock-ups people made.

This issue is a WIP. For now, here are my notes from the GCC 2021 CoFest discussion:

Person collection

Lets you link to people from other pages (like events)

Can generate dynamic pages that are lists or sublists of Persons

• Like a "Contributors" page (priority)
• Also: Working groups, Steering committees, IUC, IWC

Where the data is stored

A Markdown file per person

metadata contains links to Github, Gitter, Twitter, etc
content is optional, but can be designed how the person wants

• people can still have their own, customized "profile page"

On build, we can go fetch any content we want from other sites using the metadata.

Or maybe after build - just do it on the client

• Hervé points out that could complicate searching based on things found elsewhere

GraphQL query

Each profile page should include a list of each person's contributions on the Hub

events, pages authored, etc
Basically, I'll need to do a join between the person and all their articles.

• I think this will have to be done with a custom resolver?
  • https://stackoverflow.com/questions/51805890/how-to-do-a-simple-join-in-graphql

Other Hubs

Each person could have a "home" community whose Hub publishes them

Include the metadata as JSON+LD so other Hubs can grab them

Galaxy Profile Pages

See proposal: galaxyproject/galaxy#10920

Our metadata could link to any number of Profile Pages on any number of Galaxy instances

If present, we could grab data from there too

External personal pages

There could be a metadata field for any external url that people want

If it's there, it means to redirect to there instead.

• That's their preferred profile page
• This could literally just be redirect

Opt-in

People must only be listed if they actively choose to be

And only the data they want listed

Methods of opting in

They can always submit a pull request directly
Even better, we could make a Google Form (or similar user-friendly interface)

• They submit which info they want to include
  If Galaxy Profile Pages ever get deployed, we could include a checkbox there
• "Allow community sites to include this in their community directories"
• These pages will likely include metadata like social media, so it could be a source of that
  • People might only take the time to fill out their Galaxy profile OR their Hub page
    • Either way, we'd get it (if they check the box)

Updates / Opting out

Could use the same Google Form to change/remove things

Could even embed a link in the profile page

• Ideally we'd pre-fill all the current info and they can just change what they want.
  Can we include a "special" update link in the email they get after filling out the initial form?

Fields to show

Github contributions

Maybe just highlight the projects they've most contributed to?
https://docs.github.com/en/rest/reference/repos#list-repository-contributors

Galaxy creations (workflows, tools, etc)

from Galaxy Profile Pages

GCC presentations

could source from Sched

Hub pages

Community groups they're in

Working groups, Steering committee, IUC, IWC, etc

Bio.tools annotations?

Home city?

Could let us show a big map of where all community members are based

• Let people know potential collaborators they're near

"groups" or "interests"

give hint about what they work on & let us link together people working on the same thing
could just be a freeform field of keywords people can include

• or could be selected from a pre-made list of options

"badges"

for different activity
one could be "active in the last month" or 6 months or whatever

Inspiration

Document with examples

GTN

listing page: https://training.galaxyproject.org/training-material/hall-of-fame
profile pages: https://training.galaxyproject.org/training-material/hall-of-fame/beatrizserrano/

ORCiD

profile pages: https://orcid.org/0000-0002-9970-6657

Galaxy Profile Pages

Proposal: galaxyproject/galaxy#10920

nf-core

listing page: https://nf-co.re/community

Galaxy Europe Hub

listing page: https://galaxyproject.eu/people
implementation: https://github.com/usegalaxy-eu/website/blob/master/_data/people.yml

Parallel Tasks

Hub implementation

It might be tricky querying all the related data across the Hub like authored pages & stuff

• One thing that could help: it seems you might be able to query within the JavaScript(!)
  • See the computed property here: https://gridsome.org/docs/guide-search/#using-local-graphql-data

Designing the UI

Figuring out the external APIs we need to interact with

Figuring out the Google Form

[NickSto]

Metadata keys

Brainstorming the sort of metadata each file will contain (with @assuntad23).

key	description
name
subsites	How we group them
affiliations	A list of dicts with two keys: id (e.g. psu) and name (e.g. "Penn State"). Will probably link to a page about that place.
image	profile photo
title	.eu has this
email
phone
website	Personal site or whatever
github
orcid
gitter
matrix
linkedin
twitter
google-scholar
researchgate
galaxy_help	User id on the Discourse site.
galaxyadmin?	galaxyproject.eu has this. Do we need it? What does it do?
location	Make it structured, like EU's event locations. Would allow us to show a map of where everyone is.
groups	Any sort of grouping like working groups, iuc, iwc, steering committee (e.g. iuc, wg-goats)

[NickSto]

Person identifier

One of the purposes of the directory is to be able to link people across the Hub. E.g. the "contacts" on a post can be a list of identifiers linked to Persons. So how do we manage these identifiers?

Option 1: An id key in the metadata

The naive solution would probably be to just add a metadata field named id to each Person, and make up any string there. One issue with that is it could actually be tricky to use it to link to peoples' pages.

Option 2: Take it from the url path

A simpler solution might be to just use the path the page lives at. E.g. if the page is at /people/dannon/, then Dannon's id is just dannon. It makes deciding on a url and identifier the same problem instead of two problems, and it makes it super simple to link to a person.

[NickSto]

Groups pages

Each person is able to list groups they're a part of, which will become a list of links to the pages to those groups. The flip side of that is that we can then automatically list the members of each group on the group's page. But currently the pages for these groups are scattered or nonexistent.

If we touch the groups pages we'll have to decide whether to standardize their locations or try to conform to their existing locations.

For example, some current groups and where they live:

Group	Path	Notes
IUC	/iuc/
Steering Committee	/community/steering/
GOATS	/community/wg/goats/	Doesn't exist yet, but /community/wg/ does, so this would make sense.

Should we add some mapping to config.json to maintain these, or just standardize it to /groups/{group_id}/?

[NickSto]

All Contributors bot

@tnabtaf pointed out this project which made a bot to automatically compile a list of contributors to a repo. By default it adds an HTML table to the repo's README.md, but it looks like we could get it to write to a yaml file (using the files and contributorTemplate configuration keys). The main catch is probably that there's many Galaxy repos we'd like to count contributions to, and even if we enabled this bot on all of them, I'm not sure you can have it write to a separate repo.

[NickSto]

How to connect identifiers with objects from other Collections?

It's great that this project includes creating actual, structured objects for things like people, groups, and institutes. But a fundamental issue I keep running into is that we want to be able to refer to them by simple identifiers like assuntad23 or psu, then use those to obtain the full metadata about each object. In the case of the Community Directory, that mostly means we'll have those identifiers in the metadata of a page, and then want to show properties of those objects in the page.

But we can only do one GraphQL query per .vue file, so once we obtain the ids, we can't go back and ask for the full objects. GraphQL does provide a join-like functionality, but we don't have the necessary control over the schema to do it.

But Gridsome does provide a way to link objects in gridsome.server.js. Hopefully we'll be able to use that, then add the object's properties to the main GraphQL query for each page.