devops: adds some basic open-source structure

[rorybyrne]

What does this PR do?

Adds a basic directory structure for an open source project. Some features:

• Dependency files for Conda, Poetry, Pip, and Docker. Some are empty though, for now.
• Some code directories: ssl/ for well-ordered code, and notebooks/ for anarchy 🤘.
• Issue/Pull Request templates, found in .github/.
• A few standard open source files, like CONTRIBUTING.md, ARCHITECTURE.md, etc..

This is basically copy/pasted from some of my other projects, so we can (and should!) change things to make it more suitable for this particular project. If you have any changes you'd like to make then drop a comment here on the PR.

Closes #6

Why are we doing this?

To avoid anarchy.

Testing performed

Known bugs/limitations

(If anyone is wondering about the <type>: xyz format in the title/issue templates, I tend to follow the Conventional Commits style for issues, commits, pull requests, etc..)

[rorybyrne]

I don't know how to use Conda, so if someone could help with the environment.yml file and some basic instructions for how to install a conda project from environment.yml then I can add them into this PR.

[thesamovar]

Maybe just duplicate my environment.yml file from Cosyne?

[thesamovar]

File and install instructions here: https://github.com/neural-reckoning/cosyne-tutorial-2022

[rorybyrne]

Cool, done. Hopefully I did it correctly, but we can always fix it in a later commit if I messed it up.

[thesamovar]

Might want to remote that .lock file indeed. 😊

[rorybyrne]

Might want to remote that .lock file indeed. blush

The lock file actually should be in git, but it's not so useful for a project like this. It's handy when you build & deploy software to servers (happens 100s of times a day, in industry), to make sure that every build has the exact same dependencies installed.

It's part of poetry, so it needs to be here for anyone (if there is even anyone except me 😆) who wants to install via poetry.

[thesamovar]

Maybe ssl package should be renamed because I guess there is also a Python package with that name?

[rorybyrne]

Ah are we thinking about publishing this to PyPi as a real package? SSL is also the crypto protocol used all over the web so the naming isn't great.

Any ideas for a better name? Ideally something short so that typing it in .py files isn't a hassle.

[thesamovar]

I don't know, I just feel nervous giving it that name! How about snnsoundloc or something like that? Not too cryptic.

[rorybyrne]

What do you think of spikeloc? It shaves a few characters off (your fingers will thank you)

[thesamovar]

Sure!

[tfiers]

Only now have time to properly review, my apologies.

Overall great stuff.
Some thoughts:

• Architecture.md: love the idea. Currently nothing to describe so I'd delete the file and keep it in mind (also, maybe it oughta go into the shared code folder, if that's what it describes?)

• Contributors.md: what is the use when there's the repo's "Contributors" you can see?
  (There's also https://github.com/orgs/comob-project/people, and the Discord's members,
  but those aren't publicly visible). There'll also be the paper's authors.
  The markdown is another file to keep in sync. So I'd remove it for now.

Thoughts on naming and structure I've put in separate issues:

• naming & directories #19
• proposal: non-all-uppercase filenames #18.

[rorybyrne]

re: Architecture.md, the convention is for all meta-files to be top-level so that they can be found easily, and people know where to find them. If I was to open a repo that had its ARCHITECTURE.md file inside its source directory, I would just assume it doesn't have that file and possibly close the repo and move on to another. That would be unfortunate!

re: Contributors.md that's a good point. Traditionally projects keep such a file so that the record of who contributed lives inside the project itself, instead of relying on a third-party service to keep that record. What if Github or Discord dies? I don't think that's likely or important for our community (open source geeks are more into that kind of thing), so I'd be fine with dropping it.