repo orginization

[ddnsc]

I'm wondering if we're hitting a point with the repo where we should visit the idea of creating TheEvergreenStateCollege/upper-division-cs/students-[YEAR]/[student_name] (or something like that) and having people store their Dev-diaries and class assignments there (so all our work is in one place). Then we could link the diaries or assignments in places where it made sense (e.g. wiki_homepage --> student/dev-diaries/[diary]; assignment_page --> student/assignments/[assignment].

Here's how I imagine it would work: Start of this quarter: cd TheEvergreenStateCollege/upper-division-cs/students-2024/ mkdir ddnsc && cd ddnsc mkdir dev-diaries ai-sp-2024 sc-sp-2024 mkdir ai-sp-24/week01 sc-sp-24/week01 touch dev-diaries/ddnsc2024-04-01.md ai-sp-24/neural_net_activity.md Go to page where assignment (instruction page or Paul's lecture notes page or whatever) or dev-diary is expected to be and create link to the file or directory.

It might help contain some of the chaos to peoples respective corners if they're always pushing to their own directory and not in the stuff other students have to access as class resources. It might also make Paul Pham's life easier when he has to figure out where people are at with the course work or when cohorts change from year to year.

[learner-long-life]

Good suggestions, I'm open to this and other thoughts. If I understand correctly, it sounds like organizing by year first, students second, and courses third.

[AbyssalRemark]

I do definitely thing this absolutely needs some organization asap. I think primarily we need to make some decisions on what the design ideology of the mono repo is. It currently is A, a compilation of work though years and B, wants to be living continuous projects from people. I think doing both of these makes things strange. Unless, projects are not tied to classes.

Might I propose upper-division-cs/<subject>/<YEAR>/ maybe upper-division-cs/<subject>/<YEAR>/<quarter>/? or upper-division-cs/<subject>/<YEAR-quarter>/ ? My thought process is that the living"ness" of this repo is to create access to examples and learning going forward. for given subjects. So in the long term. the subjects is what we care about most, no? that way things that want to live longer then a quarter or a year even, they can exist in the broader scope of a subject.

With maybe an outer folder called projects that live as things on there own outside of a subject. If they are to be here at all. I don't particularly feel like they should. But if they were to continue to, that would possibly be the best idea.

I also think the use of sub modules is perhaps advantageous so we can connect projects and peoples work into this in a meaningful way but as we have experience this causes some complications, but at least then you wouldn't need to grab everything all the time as this expands. Its good to think through what the longevity of this should be, assuming it even can be. if its left to grow unchecked with any organization its going to become unusable faster rather then slower.

[learner-long-life]

@WinstonShine mentioned wanting subdirectories to organize our wiki pages.

We might consider self-hosting our wiki in markdown files with Gollum, which now supports folders.

https://github.com/gollum/gollum

[learner-long-life]

@ddnsc @AbyssalRemark this seems well thought out, thanks for the plan. would you and/or @AkinaSS like to gather more feedback from community members or if you feel ready, coordinate the migration?

I'm hearing the need to reduce conflicts between different individual students' work and also give collaborative projects and equal place to live. My request is to keep the work for a particular quarter together, perhaps with symlinks, so that students can read and understand each other's work. Contributing to the same source is an important skill, but one which can be deferred to independent study contracts or self-elected teams.

We've found a way to work with submodules and ignore spurious changes, so that could be a way to link related class projects.

The wiki files live in their own sibling repo currently, which has plusses and minuses.

[AkinaSS]

I don't know what's the exact thing that we need to do to solve but both of the previous ideas seem like a great option, albeit I'm just looking for reorganized small folders inside, but with the current work that we have, if we were to share this repo for next year then it's best to reorganize them by years and quarters?

[learner-long-life]

Thanks everyone for feedback.

Here are some (separation of) concerns I see while organizing the repo

• Minimizing conflicts between multiple users
  • someone else's change should not prevent me from pushing/pulling my work
• Archiving previous years and quarters
  • easier navigation
  • saving space
• Feeling part of a code community
  • learning from or gaining inspiration from previous quarters
  • building on a previous project

Here are some steps I see while learning git

1. Learn pushing and pulling in a one-user-one-repo main branch first.
2. Learn short-lived branching and git switching / checkout in one-user-one-repo, and merging 2b. advanced side-quest: learn about developing on long-lived branches and rebasing
3. Learn about single-user conflicts (for example, pushing-pulling between multiple devices)
4. In small groups of 2-3 users, learning push-pull-merge-resolve in a group repo.
5. Eventually, join a group monorepo with 4 or more users.

Here are the proposals I see to re-organize:

• Start a new monorepo for upper-division-cs next year, and archive this one.
• Move projects that gain a life of their own into a new repo
  • link it with submodules to monorepo if desired
• Move each quarter / year into a new repo, and link it with submodules to a monorepo
• Move each student's work into their own directories
  • or repos, link it with submodules to a monorepo
  • keep dev diaries and source code together, to avoid having to edit them separately