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.