Structure for expansion of "Ultimate Geography" about ultimate-geography

[axelboc]

1. Repos

IMO, it's important that the maintainers of a repo be willing to maintain the whole content of that repo and not just a part of it; otherwise, we risk ending up with dead parts. This is already a bit of a problem with translations: we, as core maintainers of UG, end up having to translate content ourselves any time there's a change; otherwise, translations would lag behind. Everything is coupled together, which means everything has to be updated at the same time.

With multiple repos and proper versioning, each repo can evolve at its own pace. Of course, we could imagine a monorepo set-up of sorts, with "packages" versioned independently from one another. However, I do believe that supporting multiple repos would be more scalable and really help create an anki-geo community. People could build their extension repos at their own pace, choose their own maintainers and contribution guidelines ... completely independently from us.

2. Decks

The sky's the limit here. We can easily provide any number of Brain Brew configs, or configs for the selection system that @ohare93 talks about, in order for people to generate the various decks they're interested in learning.

3. Selection system

This is definitely the key to the whole thing. People need to be able to generate their own decks, with the notes, fields/models, templates, and translations they want. Each part of those "franken-decks" should be versioned so that they can be updated deterministically. People should be able to add/remove parts and back-up their "franken-deck" configurations.

The way I see it, each extension repo could contribute various things to the ecosystem: notes, note models, templates, translations, decks, etc. So there should be a common way to declare these "contribution points".

Suffice to say, this will be very complicated to implement.

4. Note models

Multiple notes in a deck can use different note models, right? If so, then I kinda feel like their should be different note models for different types of content. I find that our own note model is already a bit weird to use with some entities like water bodies. Why restrict ourselves and try to fit a square peg into a round hole? UG could very well have different note models, templates and data files for states, territories, water bodies, etc.

Then it's a matter of making note models extensible so extension repos can add fields to notes from other repos.

5. Overlapping notes

To me this is a problem for the selection system, not for the HG repo (cf. below).

6. Replacing existing content (capital hints, flag similarities)

I guess extension decks could contribute "content overrides", for instance:

- noteId: <abcd>
  fieldName: Capital hint
  value: <New hint>

I could imagine this being useful also to fix outdated or missing content in case a repo stops being maintained, or even to replace content people disagree with (for instance if someone wants to make a repo that follows another source than Wikipedia.)

Then users could ask the selection system to process a configuration such as this (EDIT this is more of a user-facing mental model than a realistic implementation):

1. Take all the notes from UG.
2. Apply all the content overrides from HG.
3. Add all the notes from HG.
4. Generate cards from all the notes based on UG's main note model (i.e. with templates Country - Capital, Capital - Country, etc.)

---

Thinking out loud, I think Brain Brew is really not far off from being that "selection system" that we're talking about. Obviously, we'd need a UI on top of it, ideally in the form of an Anki add-on, but Brain Brew's concept of recipes is exactly what we need.

One thing that's definitely missing is a standardised way to declare "contribution points" in a repo. This could be a file at the root named "contributions.yml" or simply a standardised file structure similar to UG's. This is so the selection system knows where to look for notes, fields, templates, note models, etc.

---

I recommend attacking the problem from existing needs, of course, rather than to imagine a complete solution with all the bells and whistles: what deck do we want to generate and how to we get there:

• the extended deck = need a way of contributing templates and selecting them when defining the note model in the "selection system";
• the translations = need a way of contributing notes and generating a deck from those notes only.
• the hardcore/supreme deck = need a way of contributing notes and generating a deck from those notes combined with notes from another deck.

Other popular user needs that could be good starting points too:

• Replacing/modifying a template with one that shows auto-generated content (e.g. link to Wikipedia, text-to-speech, etc.)
• Adding a new field and replacing/modifying a template to show the content of this new field (e.g. IPA or audio pronunciation in a given accent)
• Adding a new field and a new template to generate cards based on this new field (e.g. currency, spoken language, geographical coordinates of capital so it can be shown automatically on a map in the template, etc.)

[ohare93]

(AAAHHH I wrote a reply and new hit Comment 🙈 Most parts have been addressed by @axelboc but here's what I wrote anyways)

Quote away, good sir! 👍

Seems to me like we need to consider there being 4 types of additions that an extended deck can provide:

1. Completely new notes using existing note models
   • Examples
     • New territories
     • American states
   • Must use the same fields that currently exist
2. New notes with new Note Model
   • Examples
     • Perhaps the American states should be formatted different and/or have more fields
   • No issue here with adding in these extra fields, as they exist in another note model
3. Change existing fields for existing notes
   • Add extra info that does not exist yet
     • Capital of Hong Kong / Java / Melilla / Ceuta
     • Capital info/hint where you believe there should be one
   • Change an existing field
     • Add a state flag alongside the existing flag (combine)
     • Capital name
   • This can be handled the same way we do currently for translations: another csv with this extra data
     • Though the "add extra info" flow does not exist, but it could easily be added into Brain Brew to join together two fields into one 😄
4. Completely new fields for existing cards 😨 🤩
   • As useful as it is daunting! The hail mary long term plan!
   • Not something I believe #602 is asking for, but just something to take into account
   • Data format is not an issue, it is the same as the current setup: a separate csv for each new field, with only the filled in countries mapped