ortham / buddah Goto Github PK

The "Add A Project" button on the website takes me to a non-existing or unavailable url address.
https://github.com/WrinklyNinja/buddah/blob/gh-pages/CONTRIBUTING.md

What it says on the tin. BSAs and BA2s should be two separate sections, and Mod Managers can be a section in its own right. Sections can also be split into library and application sections.

A large number of projects have their repos hosted on GitHub, so the GitHub API could be used to fetch:

• description
• license
• homepage
• keywords (from topics, but this is in preview)

This would only happen if the given repo URL is a GitHub URL. For flexibility, these fields should not use whatever is returned by the GitHub API if they have values specified in buddah's JSON file.

Also, to reduce API requests, the response data should probably be cached client-side using offline storage.

An alphabetical, category-based list is a good way to present a collection of modding tools, but it's not so good as a way of storing them. What would be better is if the entries could be stored as structured data, as this would help handle cases of an entry belonging in more than one section, and also help store metadata like which are open source, which are "best of"s, etc. more robustly.

This could be done by having a JSON file (or several JSON files) containing data structures like (borrowing from Bower & NPM):

{
  name: String
  keywords: [ String ]
  description: String
  homepage: String
  repository: String
}

This data could then be XHR loaded and used to construct a list.

Github's new "Topics" allow you to discover networks of similar repositories in a completely new way. This new GitHub feature essentially does what WrinklyNinja/buddah already does but with a much broader scope.

What does this mean for future development on this project? Can these new GitHub features be leveraged to make this project better? Maybe it will make this project obsolete, though time will tell when the networks are more mature. I feel the tighter scope of "game modding" this project offers makes it still relevant and useful.

Here's to starting a discussion about this in case is was on anyone else's mind as well.
@WrinklyNinja

The repository hyperlink points to a user page on the CK wiki http://www.creationkit.com/User:DavidJCobb/Rotation_Library

Maybe the link worked at some point but now it redirects to the CK Wiki landing page. I searched around to find the link but my wiki foo is not strong.

The link is on line#625

Whenever a tag is selected it is added to the search field. If another tag is selected the first tag is replaced. Multiple tags can be typed into the search but it would be nice if it worked with clicking the tags too.

What do you think about this idea?

For the entry source and website would you change the links to open in a new tab?

There are a lot of entries that do pretty much exactly the same thing, and they are not all equal: some are at very early stages, some are very feature-rich, and there should be some indication of this: there's no point working off library X if library Y does the same thing but better.

I accidentally broke the site by making a JS error, and if I'd TDD'd that wouldn't have happened. The CI would run the tests and also validate the JSON against a schema.

• Validate JSON against schema
• Write tests for API
• Integrate Travis CI
• Require a Travis CI status check for merging into gh-pages

Open source utilities and libraries are more useful to developers as they expose how things are done, which can be insightful, so they may be preferable to a closed-source alternative of similar functionality.

Suggested by deaths_soul on the forum thread, could be quite helpful for the API entries.

Licenses should be given as specified for Bower. NPM's license key is a bit more complex and designed to work with a Node parser.

I need to decide also where to list the licenses...

Documentation is particularly important for libraries and APIs, as at least with a CLI there's generally a help command, and with a GUI you can just click things, but reading through the code to see what's going on is a pain. As such, it would be useful to differentiate between entries that have documentation and those that don't.

A search-based UI is more useful as the number of list items increases, and helps to better catch the complexity some tools can have, without duplicating them in several sections (which just increases the length of the page, giving you more to read).

The sections JSON key should be replaced by a keywords key, which will contain searchable keywords for an entry. The entry names will also be searched (but not the descriptions).

In the interests of giving people ideas on what to search for, it would be good for the default page to display a list of keywords in order of decreasing popularity.

The search function will be a bit tricky, as I'd like results to be listed in some kind of relevance-based order, with entries that match more keywords being listed higher up. The search terms will be split on spaces, excluding quoted substrings.

I've started this, but only with a first-come, first-serve result order, so I'm hoping to hook up a library that will provide a better search, and the UI for result entries needs some thought too.