Consider centralized sushi chef project / repo

[kollivier]

Currently, each sushi chef gets its own repo, but this is problematic for a number of reasons:

1. Lack of discoverability. Has someone working on another chef done something that could make my job easier? How often have sushi chef authors duplicated effort?

2. Lack of analytics. How many chefs do we have? How much code is in them total? What are our most common types of chefs? Can we create templates for typical site types / structures? Lots of questions it's hard to answer clearly without running analytics on dozens of different repos.

3. Copy and paste issues. It's common for chefs to duplicate code. If there is a bug in this code, we have to hunt down all the copies of it and update those as well.

4. No shared issue tracking. How many total issues are open in chefs? How do we determine how to prioritize chef work? IMHO the tech specs doc should really be a github issue template.

5. Management issues. If a new sushops manager is added, do we need to setup notifications for them on all sushi-chef repos? How do they get notifications of PRs and issues? How can someone jump in and fill a need if they can't see what the needs are?

For these reasons and more, I think we should consider having a repo for our sushi chefs, with maybe a couple special exceptions for particularly involved chefs. This way a new chef would just entail creating a new subfolder, and they could still have separate venvs. (Even nicer, venvs could be a special folder in the root, so we consolidate those too.) Root folder could have special commands to do things like create a new chef using cookiecutter, setup / manage / delete its venv, and even perform cool analytics like checking what dependencies are most common and why.

[ivanistheone]

I strongly disagree with the proposal for "monorepo" approach for chefs for the following reasons:

• chefs can be very complex
• separare-repo offers nice isolation (e.g. external org doing the cheffing)
• repos are a convenient way to track issues [need to use more + more integrations]

You raise a lot of important issues. Here are some ideas for how we could tackle:

Lack of discoverability. Has someone working on another chef done something that could make my job easier? How often have sushi chef authors duplicated effort?

It's @sushops job to "know about chefs" and offer recommendations for previous chefs from which code can be reused (sushi somellier?).

Also, I see this kind of tasks as @sushops responsibilities that would help with discoverability:

• maintain useful "code snippets" in ricecooker docs for reuse
• maintain useful "full-fledged" samples in https://github.com/learningequality/sample-channels
• write ricecooker.utils for solutions to recurring issues (e.g. youtube playlist downloader)
• could maybe have a "how to write a chef" channel with tutorials on specfic tasks (same stuff as in ricecooker docs but as video walkthrough to make it easier to follow)

Lack of analytics. How many chefs do we have? How much code is in them total? What are our most common types of chefs? Can we create templates for typical site types / structures? Lots of questions it's hard to answer clearly without running analytics on dozens of different repos. No shared issue tracking. How many total issues are open in chefs? How do we determine how to prioritize chef work? IMHO the tech specs doc should really be a github issue template.

Could a fab command + github API be used to compute these? Might be a good metric to report, e.g. number of sushi-chef-* repos, # of commits last month, etc.

Copy and paste issues. It's common for chefs to duplicate code. If there is a bug in this code, we have to hunt down all the copies of it and update those as well.

Yeah that's difficult to fix... hopefully over time most "shared" code can be moved to riceocoker and pressurecooker utils.

Management issues. If a new sushops manager is added, do we need to setup notifications for them on all sushi-chef repos? How do they get notifications of PRs and issues?

That's a tough one... Is there a way to make someone follow a repo via github API? Maybe can use fab to generate list of links to all chef repos and ask new sushops manager to follow the repos manually.

How can someone jump in and fill a need if they can't see what the needs are?

Ideally if repo is self-contained + good spec sheet, a new developer could quickly onboard themselves. Not obvious though ... since much of scraping is very ad-hoc so generally difficult to know what's going on if you didn't write the html-scraping calls.

[kollivier]

chefs can be very complex

By just about any metric I'm aware of for code, I think our chefs would score pretty low on the complexity scale. Lines of code, number of filed / open issues, number of committers / PRs.

separare-repo offers nice isolation (e.g. external org doing the cheffing)

What are the pros of said isolation? From my experience so far, it has meant me doing more setup work and more time spent trying to mentally pull together a big picture view of where our chefs are at. So far I haven't seen any ways in which it is simpler or less work than a centralized approach.

I think external orgs should also have external repos, so not part of LE's github. If they can't do that right now, that should probably be considered a bug.

repos are a convenient way to track issues [need to use more + more integrations]

When I read this, I was thinking about how convenient it would be to be able to see ALL the open sushi chef issues in one board rather than having to check numerous ones individually to get a full picture. It'd be easy enough to have issues follow the format of "[Khan Academy] Bug Title Here"

As I see it, we basically could improve things in one of two ways - consolidate chefs and streamline the management process, or build and maintain more integrations and tooling to get our chosen approach to work the way we want it to work. (And from your reply, it sounds like many of the things I could use would be pretty difficult to build out as features.)

For me, streamlining means being able to spend more time improving Studio itself and getting more content into it.