updating

.github/workflows/deploy.yml

@@ -23,7 +23,7 @@ jobs:
 
       - name: Install dependencies
         run: |
-          pip install mkdocs  # or your theme/plugins
+          pip install -r requirements.txt
 
       - name: Deploy to GitHub Pages
         run: |

.gitignore

@@ -1,2 +1,4 @@
 .DS_Store
 .vscode/settings.json
+CLAUDE.md
+memory.md

docs/Policies/authorship_guidelines.md

@@ -0,0 +1,48 @@
+## Authorship Guidelines
+
+In a theory group, it's often difficult to tell who has contributed to a project enough to merit authorship. A lot of our work is conceptual, and progress often arises from ongoing discussions between people in the lab. Intellectual work is work, and should not be devalued relative to "hands on" work. Our work also uses code that, once developed, is shared widely — and good code can take many hours of work to develop. This is similar to the case of experimental work, in which datasets can take years of work to collect.
+
+Because of this, authorship in our lab isn't always obvious, and it's important that we talk about it openly rather than let assumptions lead to misunderstandings. For reference, the [NIH guidelines for authorship contributions](https://oir.nih.gov/system/files/media/file/2024-07/guidelines-authorship_contributions.pdf) are a useful reference for which types of contributions do and don't typically warrant authorship. Here are some guidelines for our group:
+
+### Guidelines
+
+**If you use someone else's code that has not been published, they get authorship.**
+
+**If you use someone else's code that has been published and shared,** they should be offered authorship if they contributed to significantly modifying or adapting the code to your project.
+
+We want to encourage the writing of good, reusable code. One way to do that is with the incentive that if your code is usable by others in the lab, you'll get credit for it.
+
+**If you've had significant discussions with someone that contributed to the conceptual development of your project,** they should be offered authorship. This is a grey area, and it's ultimately up to your discretion — but when in doubt, offer.
+
+**If you collaborate with experimentalists or use their data,** they get offered authorship. This includes discussions about interpretation of your results, which I highly recommend doing early in a project.
+
+**In general, err on the side of giving authorship rather than not.** The cost to existing authors is close to zero, and the value it creates — especially for early-career researchers — can be significant.
+
+That being said, we should also be thoughtful about the possible downsides of overly generous authorship. Research has shown that e.g. [women can be perceived as "less responsible" for papers with many authors than their male colleagues](https://www.journals.uchicago.edu/doi/abs/10.1086/711401). Authorship decisions should reflect real contributions, and we should be aware of how credit is perceived in the broader academic context.
+
+
+### Author Order
+
+Author order conventions vary across fields, but here's how it typically works in ours:
+
+**First author** — the person who did the bulk of the work on the project. In our lab, this is usually the PhD student or postdoc who led the project.
+
+**Last author** — the senior author, typically the PI. This position signals supervisory and intellectual oversight of the project.
+
+**Middle authors** — listed roughly in order of contribution, though this can be flexible. If you're unsure where you fall, ask.
+
+**Co-first authors** — when two people contributed roughly equally to the work. This is indicated with an asterisk or footnote in the paper. This is a bit of a grey area in the field - in theory it should be equal credit. In practice, some people see it as equal-but-unequal... But certainly being second co-first author is seen as better than second author. Personally, I think the value of a close collaboration usually outweighs the potential negative value of this impression, and I always try to cite co-first author papers as (Author*, Author*, et al).
+
+If you have questions about author order on a project, bring it up with me. I'd rather we have a slightly uncomfortable conversation than have anyone feel their contributions aren't recognized.
+
+
+### When to Discuss Authorship
+
+One standard piece of advice is to "discuss authorship early" — ideally when a collaboration or project begins, not when the paper is being written. To be honest, I find this a bit difficult because the nature of science is that projects grow and develop over time. If this feels useful to you, by all means go for it. Authorship expectations can change as a project evolves. If someone's role grows or shrinks significantly, revisit the conversation.
+
+
+### Before You Submit
+
+**Submit nothing without all authors seeing it and giving approval.** This is standard practice in academic science, but it's one of those things nobody explicitly tells you. No paper, abstract, or grant goes out the door without sign-off from everyone involved. Give your co-authors enough time to actually read and respond — don't send a draft the night before a deadline and expect approval by morning.
+
+

docs/Policies/code_software.md

@@ -16,7 +16,7 @@ Here's how we may format our code as a lab:
 ### Conventions
 Patrick Mineault's code handbook above is a must-read before you start coding. It reviews the best ways to set up your project, to maintain clarity and cleanliness, to test your code, and to document your code as well. The handbook is the best way to learn these conventions, especially when it comes to efficiency and testing, which rely on great examples. However a few helpful tips to get you started in the right direction
 
-- Use `git` often, often more than you think you should. See `Resources and How-Tos/basic_github.md` for additional information.
+- Use `git` often, often more than you think you should. See the [basic GitHub tutorial](https://levensteinlab.github.io/Lab-Handbook/Resources/basic_github/) for additional information.
 - Setup your repository correctly, from the beginning.
     - Mineault's base directory structure works really well to keep the inputs and outputs of your code separate:
         - `data` folder: raw input data

docs/Policies/communication.md

@@ -0,0 +1,25 @@
+### How We Communicate
+
+Our primary communication tool is Slack. Day-to-day lab communication — sharing results, asking questions, posting interesting papers, coordinating logistics — all happens there. Email is mostly for communicating with people outside the lab (collaborators, departments, etc.), and I'll rarely email you about lab stuff.
+
+A few norms worth making explicit:
+
+**Reaching me.** You can always message me on Slack, and if my door is open, come on in. I try to be responsive on Slack during the workday, but I'm not always glued to it — if something is time-sensitive, don't hesitate to message me again or stop by. If you send me something that requires a longer or more thoughtful response, it might take me a bit to get back to you, but I will. If I haven't responded and you need an answer, please nudge me — I won't be annoyed, I'll be grateful.
+
+**Sharing results between meetings.** When you share plots or results on Slack, please include some interpretation with them. Don't just drop a figure — point out what you notice, what you think it means, and what you're thinking of doing next. A few sentences of context turns a plot into a conversation. (More on this in the [meetings page](https://levensteinlab.github.io/Lab-Handbook/Policies/meetings/#1-on-1-meetings).)
+
+**Off-hours messages.** I will sometimes message at evenings, or on weekends. Please do not think this means I expect you to act on, or even read, the message until the next workday unless it's specifically designated as urgent/time sensitive. It only means that I thought of something relevant to your project and didn't want to forget. If you'd prefer I not message you outside of working hours (unless urgent), please let me know and I'll schedule these for the next workday. (See also: [Hours & Remote Work](https://levensteinlab.github.io/Lab-Handbook/Policies/hours_remote_vacation/).)
+
+**Slack channels.** We have a few channels worth knowing about:
+
+- **#all-levenstein-lab** — lab announcements, logistics, and anything important for everyone to see
+- **#papers** — interesting papers you come across. Post freely here! Even if you've only read the abstract, sharing papers helps everyone stay aware of what's happening in the field. This channel also feeds our [journal club](https://levensteinlab.github.io/Lab-Handbook/Policies/meetings/#lab-meeting) paper selection.
+- **#lab-meeting** — coordination and scheduling for lab meeting (the schedule spreadsheet is pinned here)
+- **#lab-handbook** — discussion about development and changes to this handbook
+- **#code / #gen-ai-tools** — sharing coding tips, tools, and AI/LLM resources (see also: [GenAI guidelines](https://levensteinlab.github.io/Lab-Handbook/Resources/gen_ai/))
+- **#lunch** — coordinating lunch plans
+- **#seminars-events** — upcoming seminars, talks, and events worth attending
+
+**Handbook updates.** When changes are made to the lab handbook, a pull request will be submitted and all lab members will be requested as reviewers — you'll get an email notification and a message in #lab-handbook. Only one person needs to approve a PR, but the notification is a prompt for everyone to look over and discuss the changes. So: (1) when you get this notification, go look over the changes, and (2) if no one else has approved the PR yet, please approve it. For more on how the handbook works and how to contribute, see the [lab handbook page](https://levensteinlab.github.io/Lab-Handbook/Policies/lab_handbook/).
+
+**A general note on asking questions.** There is no such thing as a dumb question in this lab. If you're stuck, confused, or just want to think something through with someone, ask. Ask me, ask your labmates, post in Slack. One of the things I value most about being in a lab is that we can think together — and that only works if people are willing to say "I don't understand this" or "can someone help me think through this?"

docs/Policies/conferences_workshops.md

@@ -6,8 +6,18 @@ If you are presenting your work, the lab will fund your registration and travel
 
 Please plan to **send me a draft of your abstract one week before deadline**. This gives us enough time for a few rounds of edits and discussion, and to develop the story together. Your work, and your abstract acceptance rate, will thank you. I’ll note that you often feel like your project is not-quite-ready when you start writing your abstract, and that the abstract writing process is often when the project gets developed to the point where it’s ready to submit… long story short, don’t be afraid to write an abstract even if you feel you’re not ready :) 
 
-As with a paper submission, nothing goes out without all co-authors seeing and approving the final version.
+As with a paper submission, nothing goes out without all co-authors seeing and approving the final version (see [authorship guidelines](https://levensteinlab.github.io/Lab-Handbook/Policies/authorship_guidelines/)).
 
 The exact number of conferences you should expect to present at per year will depend on your career stage, and status of your project. IMO the best times to present are when you're halfway through a project, and trying to figure out what the story is, and just after you've posted a preprint.
 
 See [Resources - Travel](https://levensteinlab.github.io/Lab-Handbook/Resources/travel/) for information on booking travel.
+
+# Workshops/Summer schools
+
+If there's a summer school or educational workshop that would be good for your career/research, I'm quite happy for you to go and will support your application/pay for registration/travel/etc. Some common ones are the Woods Hole Methods in Computational Neuroscience course, Kavli Mathematical Methods in Computational Neuroscience, and Cajal course in Computational Neuroscience. Often these are most useful to take halfway through your PhD, or at the beginning of your postdoc to pick up new techniques. If you do attend, I only ask that:
+
+1) if they have the option to apply for grants to waive registration fees that you apply for them,
+
+2) that you take them seriously (they're a lot of fun, and you'll meet friends and colleagues you'll have for the rest of your career. but they're also a lot of material to learn in a short amount of time), and
+
+3) that you make an effort to think about how you can bring back the things you learn to your work in the lab. at the very least you'll have to give a "what I learned at summer camp" presentation in lab meeting 🏕️ (See [presentations guide](https://levensteinlab.github.io/Lab-Handbook/Resources/presentations/) for tips.)

docs/Policies/hours_remote_vacation.md

@@ -4,6 +4,6 @@ As our work is predominantly theoretical/computational, we have a lot of flexibi
 
 If it fits you, I would encourage you to plan one day a week where you work from home (or elsewhere out of office). This shift in perspective can be helpful for your work and I encourage you to take advantage of this time to think freely and critically about your project and current approaches. I do ask that you plan to attend lab meetings in person -- in my experience, remote attendance encourages people to listen (at best), rather than participate, in lab meetings. Also, I ask that you plan to be physically in lab 3-4 days a week. Of course, this can vary week to week and exceptions will be made to fit people’s circumstances.
 
-I will sometimes message at evenings, or on weekends. Please do not think this means I expect you to act on, or even read, the message until the next workday unless it’s specifically designated as urgent/time sensitive. It only means that I thought of something relevant to your project and didn’t want to forget. If you'd prefer I not message you outside of working hours (unless urgent), please let me know and I'll schedule these for the next workday.
+I will sometimes message at evenings, or on weekends. Please do not think this means I expect you to act on, or even read, the message until the next workday unless it’s specifically designated as urgent/time sensitive. It only means that I thought of something relevant to your project and didn’t want to forget. If you’d prefer I not message you outside of working hours (unless urgent), please let me know and I’ll schedule these for the next workday. (See also: [Communication](https://levensteinlab.github.io/Lab-Handbook/Policies/communication/).)
 
 I expect you will be taking vacations. I usually take off from the weekend before Christmas until the weekend after new years, a few days around thanksgiving, a week or two over the summer, and the various official 3-day weekends. I’ll lightly respond to emails during these times, do some reading, maybe some writing. But in general I like to use this time to recharge, spend some time with family and hobbies, and I encourage you all to do the same. For more about work-life balance in academia, please see [Work-life balance] **TODO: @dan include link**.

docs/Policies/lab_handbook.md

@@ -0,0 +1,28 @@
+### About This Handbook
+
+This handbook is a living document — it will evolve as the lab grows and as we figure out what works. I'll be honest: I have no clue how to run a lab aside from what I've seen and heard does and doesn't work. This handbook is part of a journey to facilitate the best lab environment I can, for its members and for the research, and I want it to be something we build together.
+
+That means every lab member is expected to contribute. If you find something out of date, poorly described, or missing, fix it. If you disagree with something, bring it up — in the #lab-handbook channel on Slack, in a 1-on-1, or in a PR comment. The handbook should reflect how we actually work, not how I imagined we would work when I wrote the first draft.
+
+### How to Make Changes
+
+The handbook is an [MkDocs](https://www.mkdocs.org/) site hosted on GitHub Pages. The source files live in the [Lab-Handbook repository](https://github.com/LevensteinLab/Lab-Handbook) on GitHub — each page is a markdown file in the `docs/` folder, and the site structure is defined in `mkdocs.yml`.
+
+To make a change:
+
+1. Create a branch and edit the relevant markdown file(s).
+2. If you're adding a new page, add it to both the `docs/` folder and the `nav` section of `mkdocs.yml` — otherwise it won't show up on the site.
+3. Open a pull request.
+    1. Request `Levensteinlab/lab-members` as reviewers (this also sends a notification to #lab-handbook on Slack).
+4. Once at least one person has reviewed and approved your PR, it can be merged.
+
+If you're not sure how to do any of this, see the [basic GitHub tutorial](https://levensteinlab.github.io/Lab-Handbook/Resources/basic_github/) or ask in #lab-handbook. Your first contribution is part of [onboarding](https://levensteinlab.github.io/Lab-Handbook/onboarding/) — you should have made at least one improvement to the handbook by the time you complete onboarding.
+
+### Reviewing Changes
+
+When a pull request is opened, all lab members are requested as reviewers. You'll get an email notification and a message in the #lab-handbook channel. Only one person needs to approve a PR, but the notification is a prompt for everyone to look over the changes. So:
+
+1. When you get this notification, go look over the changes.
+2. If no one else has approved the PR yet, please approve it.
+
+This is how we keep the handbook accurate and up to date as a team.