Closed TildeWill closed 8 years ago
Oh man, so many options. Rookery
?
You should invite @knu and @dsander to this effort too.
Done
In general, I want to see more of the Huginn analogy extended to the code and UI. Something like
Then I think the mythology of this directory would fall out pretty cleanly
I like creative naming of products, but I'm very hesitant to name internal concepts based on the analogy. My experience is that it can get pretty confusing. (For example, the naming in Concourse takes it way too far, in my opinion.) On Sun, Feb 7, 2016 at 11:49 AM Will Read notifications@github.com wrote:
In general, I want to see more of the Huginn analogy extended to the code and UI. Something like
- Scenarios --> Flight Plans/Journeys
- Agents --> Pitstops/Depots/Oasis/???
- Events --> Messages/Findings/Briefings/Chronicles
- Credentials --> ???
- Services --> Informants/Guides/Advisors
Then I think the mythology of this directory would fall out pretty cleanly
— Reply to this email directly or view it on GitHub https://github.com/omniscopeio/flight-plans/issues/1#issuecomment-181093752 .
For me the problems arise when the domain naming overrides strong convention. fly
instead of concourse
for the CLI makes it hard to adopt. But Chef with recipes
and a collection of recipes called cookbooks
helps adoption. knife
takes it too far IMO.
Un-thread-jack: So far we have
It will also be better if we can figure out how to cleanly variables and compose Scenarios.
Adding "Midgard", the land covered by Huginn and Muninn
Not bad! You should probably post on the Scenario host issue on Huginn and invite people to post here?
I like Muninn/Midgard for the mythology angle, Huginn Community for simplicity.
Construct (A construct of bots.)
Agency (An agency of agents.)
Thanks @virtadpt, I've added them to the list
I don't know what the plans for the project are, could/would it also be used it as the project home page for huginn? If that would be the case I'd vote for something simple like "Huginn Community".
As for the site name, I'd prefer Huginn Community, for it'd be one of the top phrases people would search for. When it comes to the name for the central repository, it could be The Book Of Huginn, Huginn Agency, or whatever.
@dsander and @knu, what did you have in kind for the project home page? Is it static? Would Github pages be appropriate? I'd encourage someone to use Github's Name Squatting Policy and get the huginn username so that pages would work as http://huginn.github.io/.
@TildeWill Not sure, just for the project home page a static site would be enough. I thought we could combine the scenario directory with the public site and maybe expand it with some kind of knowledgeable later?
I think I'm leaning towards a Huginn Community just to be very clear.
I do think that a directory of scenarios should also be used as a community site with tutorial links, etc. Maybe there's some way that we can use GitHub static pages as a scenario sharing site with pull requests?
I disagree that one Github repo should represent two things: the scenario repo AND the community site. If we want to glue those two things together via how we deploy/URLs or some other device so it's easy for the world to consume, I support that. Experience tells me we're going to be happier if we have one repo for one service.
That's fine with me. I was mostly asking if we can find a smart way to use GitHub as the Scenario backing, but a custom site may be much more usable for our users.
Communin little word play on community and munnin?
I dont know, from personal experience it's better to don't care about the name until you have an MVP anyways.
Maybe we could use github as an easy-plugin for developers to publish Scenarios, a la oh-my-zsh, maybe we could make it easier too to add dependencies/agents (some published agents, may be somewhat useless without other dependency agents.) from a repo url, a la https://rubygems.org, but using github.username/github.repo. If all files expected are there and some tests pass, add the agent to the huginn instance.
I don't know, that would made really easy later to have a /packages endpoint or on settings page to discover/manage/install/uninstall/access-settings of new packages a la Atom.app. and apm
I see this hasn't been discussed for a while, is still needed some help on this?
a README.md file should be enought to fetch data from the agent author to the package-manager/web-community.
I also like how alfred.app manages it's packages with packal.org at least on the frontend/web I don't really know how it works in the back.
@agustifernandez your timing couldn't be more perfect. I was just dusting off this project earlier today. I'm declaring "Communnin" a winner. I think I'd still like to try building a place where exported scenarios are uploaded and versioned by the creator.
Rookery or Huginn Community are my favs, but Communnin is cute too. (Just hard to spell, like Huginn itself, and hard to Google.) But this is your project @TildeWill, so you can pick the name.
Nice, didn't expect so much success! Since I already helped with the name, let me know if I can help with something else for the project.
https://domainr.com/communn.in?q=Communnin
Communn.in is available fwiw.
Updated list of ideas so far: