Document where we are so far.

[blueridanus]

A number of potential approaches to GUI, potential problems and potential solutions have been raised in discussion. Those need to be documented for reference.

[shivshank]

We could perhaps create a file such as gui_concerns.md that collects and summarizes these issues.

Some topics and questions I've seen come up so far:

• is the use of a scripting language or DSL justified?
  • leads to discussions of overhead, iteration time, code generation/reflection/introspection and barriers to entry
• what about html/css vs other formats and methods for describing layout?
• event flow: callbacks, futures, streams, oh my
• imperative vs retained state API

I think it's best to present everything as a discussion of the various options (as opposed to "choosing" what we think are the best trade offs to make, since everyone will ultimately disagree).

Edit: We can discuss more general project direction stuff here. See #4 for more about concerns/approaches.

[pythoneer]

I think it would be a good idea to list (mostly) everything we have so far and try to categorize it and try to look what background the project has. But i don't know really how to start. Should me make one tracking issue and several others for every one to discuss it? I have a list with some projects worth looking at https://github.com/pythoneer/areweguiyet/wiki but i think we need to dig in there as a starting point.

[shivshank]

Your list is excellent! I think an issue for each item is reasonable, so that it is easy to follow discussions. We can create issues as we work through them.

I would like to make the CLI interactive so that anyone can quickly create a PR to add a crate.

I think for each crate, this is what I am currently thinking we should collect:

• A rough/general "status" such as "Stable," "Emerging", "Prototype," "New/Young," and "Inactive."
• @pythoneer you suggested to me, and I really like the idea:
  • List of a few projects that use it, with screenshots (call them "featured projects" maybe?)
• List of pros and cons/use cases
• Any chat rooms and forums (IRC/Discord/Gitter) used by the maintainers
• Link back to the discussion issue for the crate
• When our information/pros/cons was last updated.

Let me know if there's more we should do or if I forgot anything!

What I would like to add to the "crate cards" on the web page:

• Badges/shields for stars/forks (maybe we should sort crates by this); I think this is the best way to list this information so that we don't have to host a back end server anywhere for the site.
• By default I think the cards should show badges, links, and crates.io crate description, and then a "read more" button if we have more info about the crate (pros/cons/featured projects).
• Add a search bar powered by client side Javascript to search by tags/name.

For the things I mentioned in my first post in this issue (I'll add an edit): things that are not about specific crates I think will go in an "approaches" section, to be designed/built. I'll create a separate issue for that and we can discuss how and if we still want to do that.

[pythoneer]

This sounds great. I would start to process the list and turn it into issues. I am just wondering how to effectively collect a "result". I could imagine two ways that would depend on how to actually create an end result on the page. The main problem with collecting stuff inside the issue is that the information gets scattered across multiple post inside of it. So either we have a wiki page for each issue in which we constantly collect and update information as we go and turn it into content for the webpage if we feel confident. The other way would just start out corresponding PR's. I think creating PR's is the appropriate way.

So that leads me to the question how do i actually crate content? How far is your tool or should we start by manually crate content to start. What exactly do i have to do to make this happen. I glimpsed over the website code and i would guess the ecosystem.json looks like the right place.

EDIT: Forgot to mention. The reason i mentioned wiki pages is because the current state of json does not reflect all the information you i and want to be inside of it for each crate. I agree with the points you listed above and i think they will change over time as we go but this looks like a good starting point. But that is a point that speaks against PR's and start with wiki pages until we have the infrastructure to represent all the information we like.

[shivshank]

The tool is not very far along. I will try to improve it a little more this week, hopefully. There are a few crates that should help with making CLIs, and I would like to try them out.

I think in addition to what is there already, below are some examples of how we can extend ecosystem.json:

{
    name: String,
    description: Option<String>,
    docs: Option<String>,
    repo: Option<String>,
    tags: Vec<String>,
    // new stuff:

    // We may want to enforce that these follow some kind of pattern, i.e, official links only for each
    // chat platform, like discord.gg for Discord, for instance
    chats: Vec<String>,

    // A paragraph that appears in the card following the crates.io description
    // (will get cut off if it is too long, and there will be a "read more" button)
    extended_description: Vec<String>,

    // use cases described in bullet points
    use_cases: Vec<String>,

    // these will become a list of bullet points
    pros: Vec<String>,
    cons: Vec<String>,

    // see my earlier post for what this enum could support
    status: ProjectStatus,

    last_updated: String,
}

ecosystem.json is the correct place to make the changes for now. Once the changes are made, doing cargo run from the cli directory should "just work," although I know it failed for at least one person. It is not very robust.

I agree that information will get scattered in issues. PRs should work well, since the ecosystem.json should be easy enough to read, assuming it is formatted well. PRs will allow people to comment easily on changes.