Thoughts on Github structure

[bs]

Thoughts on github.com structure

Goals

• Easy to discover, access, and dive into all of our projects
• Clearly recognize all contributors (code or otherwise) by following the all contributors specification
• See the p5.js project as a great example of what we should strive for

Current

github.com/earthspecies

• earthspecies/getting_started

  • currently a place for collecting ideas
  • suggests adding to the library

• earthspecies/roadmaps

  • our ideas of projects

• earthspecies/esp_library

  • /example_public_species (some public implementations of projects on different public domain datasets)

• earthspecies/a_public_species (macaque)

• earthspecies/a_private_species (sperm_whale)

• earthspecies/an_experiment_or_tool

Suggested

github.com/earthspecies

• earthspeices/project (replaces getting_started has /roadmaps as a subfolder)

  • Title
  • Community
  • Getting Started
  • Learning
  • Contributions
  • /roadmaps
  • /wiki (should just use github wiki?)

• earthspecies/library

  • Title
  • Community
  • Getting Started
  • Issues
  • Learning
  • Contributions
  • /a_dataset_and_code? (See below for musings on this)

• earthspecies/a_tool_or_project_in_progress

  • examples: hyperresolution_spectrogram, raven_change_path, decoder_head

• earthspecies/an_education_or_unique_resource

  • example: from_zero_to_DSP, raven_change_path

• earthspecies/esplib

  • for common and reusable bits

Questions

Where to keep each 'species project' code?

As subfolders in the library

It seems like this is the way the organizational structure is drifting. @radekosmulski and @pcbermant ... what are your pros/cons?

Pros

• all in one place ... easy to find
• better knowledge transfer across species ... easier to do comparative analysis
• more activity in one place ... easier for community
• simple to reference someone who's part of the ESP but does not want or cannot have data hosted on Archive/Github, could very cleanly create a link here
• makes it easy to see the benefits of open+library

Cons

• Could a collaborator want more separation from other projects? Need to test-ask.
• conversations could get confusing

As separate repos

Pros

• clean to have each current species that we're working on as a project
• see which species are getting the most activity via commit graph

Cons

• activity spread out and could start feeling like everyone's working in a vacuum
• lesser visibility for contributors?
  • could simply toss an contributor tile in the 'project' repo

Meta

[aza]

Thanks for all this thinking, @bs! I'd opt for (at the beginning) subfolders in library for all the pro's you listed and in particular: "more activity in one place ... easier for community"