• curated topics
• check last merge into main + https://api.github.com/repos/github/explore/deployments
• uncurated topics (needed for #25)
  • contributed repos
  • related topics
  • organization repos
  • starred repos
  • subscribed repos
• etag

• web worker
• API throttling
• Log
• Messaging
• Promise.all()/Promise.allSettled()
• queueMicrotask
• Toasts
• Progress
  • Per page
  • Per collection item
  • Per queue entry

• pin button
• sorting
• add note?

Current behavior

Currently, topics are sorted by the total amount of repositories that have said topic. That might indicate "valuable topics", but not necessarily those, the user is knowledgable of—something, this tool actually aims for but potentially fails to deliver at this point.

Intended behavior

• Combine multiple sorting options
• Offer user to control which sorting options are included

Sorting options

Sort by

• total amount of repositories (= valuable topics*)
• amount of own repositories (= knowledgable topics*)
• amount of contribution to own repositories? (= knowledgable topics*)
  1. https://api.github.com/repos/{org]/{repo}/commits?author={username} → total count
  2. https://api.github.com/repos/{org]/{repo}/commit/{sha} → stats.*
• Name
• Followers (not implemented yet)

Sort direction

• ASC
• DESC

Filter

• good choice
• okay-ish choice
• poor choice
• without PR only

• ^{* Put this into the legend}

Unit tests

• str
• api
• dom
• github
• ui
• reactivity
• queue

User stats

• value score
  • number of topics added
  • number of topics contributed (added + edited)
  • number of repositories with curated topics added (with and without aliases)
• topic stats
  • score per topic (x/12 properties (including body + image (property and file count as one)) added or edited)

https://explore-feed.github.com/feed.json

• CI/CD

• List view
• Table view (legend above, collapsed → needs #7)

• LocalStorage entry per page for hidden topics (Currently, there's only one entry for all pages)
• Update counter in heading
• Refresh tooltip (should be closed after reinitializing)
• Filter counter for only the hidden topics from the current page's result set
• Add "x of y" to filter dropdown (#2)

Current behavior

If you want to share a user's uncurated topics, you have to copy the URL. This can have multiple disadvantages:

• Not everyone might know about this
• The URL doesn't know if it is in global state (without username query param) or in search state (with username query param)
• We might add URL query params in the future, we might not want to share alongside the username

Intended behavior

With a button that can be disabled as long as no username is entered, we can circumnavigate this.

Share options

• copy link
• Share on twitter
• share on facebook
• share on mastodon
• share on telegram

• methods with parameters or return type other than any
• typedef
• ambiguous variables

Current behavior

• Uncurated topics by contributes repositories

Intended behavior

Based on user

• Uncurated topics by contributed topics (related topics)
• Uncurated topics by starred repositories
• Uncurated topics by starred topics
• Uncurated topics by subscribed
• Uncurated topics by user's organisation's repositories

Global

• Uncurated topics by most wanted topics (most total repositories)

Aliases (#12)

• British vs American
• Acronyms (only by dash-separated topics with min. three-letter acronyms)
• Sanitized (with and without dashes)
• Numeronym (if exists)
• Common suffixes (js, db, etc.)
• Abbreviation (development → dev)

URLs

• GitHub URL ()
  • repo
  • org
  • user
• Wikipedia URL

Misc.

https://query.wikidata.org/sparql?query=SELECT * WHERE { SERVICE wikibase%3Amwapi { bd%3AserviceParam wikibase%3Aendpoint "[www.wikidata.org](chrome://devtools/content/webconsole/www.wikidata.org)"%3B wikibase%3Aapi "EntitySearch"%3B mwapi%3Asearch "MongoDB"%3B mwapi%3Alanguage "en". %3Fitem wikibase%3AapiOutputItem mwapi%3Aitem. %3Fnum wikibase%3AapiOrdinal true. } %23%3Fitem (wdt%3AP279|wdt%3AP31) %3Ftype } ORDER BY ASC(%3Fnum) LIMIT 20

• Remove aliases from related in favor of official topic name since list of related is limited

• static
• dynamic (needs #7)

• publisher
• subscriber

• UI changes
• PUT request → doesn't seem to work properly
• Suggest alias

• Show which topics are related to each other
• Show if the relation is mutual or unidirectional
• Show how many outgoing connections a topic has
• Show how many incoming connections a topic has
• Don't show orphaned topics (less noise)

• webmanifest
• static assets (static/?)
• pages
• sitemap

Current behavior

Currently, if there is already a PR for a new topic, we don't know and would create another one so that the two would compete, which is undesired.

Intended behavior

Show if topic already has open PRs next to the topic in the list.

• like "top choice"
• diff latest artifact?
• caching
• contributed repos
• related topics
• organization repos
• starred repos
• subscribed repos

Same as with #16, can be reused in #10

Current behavior

Currently, you create all information of a topic by creating a new markdown file with YAML frontmatter. Validation and autocompletion can only be done via GitHub actions and their results need to understood in case of errors.

Intended behavior

With a view like the actual topic page, including a form with separate input for each information, validation and autocompletion can be done in place for a more rich editing experience.

Tasks

• Autocompletion and multi selects
• Validation rules
  • static
  • API
• Primer layout and design
• API request to save

• ES Modules
• Web components (#24)
• ?

Current behavior

Currently, due to GitHubs API rate limits, the process can drag on quite a while, so its only natural, people go to other browser tabs while waiting instead of staring at the screen for a couple of minutes—and might forget about the tab.

Intended behavior

When done, there could be multiple indicators of that status change:

• Change of the <title />
• Notification
• Email ("I don't want to wait. Just shoot me an email")