Discussion: Policies for add-on tools

[icefoxen]

@ozkriff is working on making a GUI and scene manager that work with ggez, and brought up a couple good questions on IRC:

• Are the names ggez-zgui and ggez-zscene okay?
• Do we want to have a list of "blessed" crates?

My gut feeling so far is:

• We should politely discourage people from using "ggez" in crates unless they're officially part of ggez. I worry about it leading to the situation we currently have with piston and gfx, where there's ten million different crates, some official, most unofficial, and most unmaintained and experimental. We makes it hard for new users to figure out what the heck is actually going on. On the other hand, ggez specifically exists so that we don't need more than one crate to get new users started, and it's unlikely to get confused with anything else, so maybe in our case it's no big deal.
• A list of "official" or "blessed" third-party crates is a maintenance burden I don't want to have to deal with. I'm happy to list whoever's tools in the docs/Projects.md file with no guarantees implied, but doing more than that sort of suggests some sort of commitment to maintain said tools as ggez evolves, and that's just something I can't handle. If we wanted to do this I would also want a procedure for "un-blessing" crates (deconsecrating?) that have become unmaintained, based on objective guidelines that can be followed without needing a judgement call or hurting peoples' feelings. In practice, I also think that any high-quality ggez-based tool that gets made is going to become popular on its own merits, without ggez having to commit to maintaining it. I'll happily pimp other people's projects. 😁

This has nothing to do with ozkriff's efforts specifically, I'm just trying to think about general policies. I like policies, 'cause we can write them down and then never again have to think about how to make decisions until we decide the policies need changing. 😛

I hadn't really thought about these sorts of things before now though, and want people's inputs. Discuss.

[anderspitman]

I think a simple list of libraries people are successfully using alongside ggez would go a long way. A wiki page or dedicated md would do it. Don't know if you'd need an official "deblessing" procedure. Could just keep the top (subjective, I know) 2-3 projects for each type of library (ECS, scene graphs, UI, etc).

[Ratysz]

I'm in favor of the "gently discourage" naming policy, despite being guilty myself (in my defense, I was going to change the name before it got anywhere close to being published). All the names ever add is discoverability, and even then it's rather redundant: crates can have tags associated with them, and descriptions inevitably have to mention ggez as well.

A list of supplementary libraries and projects to look at would be nice to have indeed, even as a "what's next?" paragraph at the end of tutorial/introduction. Although, it has to be done in such a way that it's maintenance from ggez side is nigh non-existant. Perhaps, divide the list into two sections: "confirmed to be working on latest ggez version" and "potentially outdated" (or something less damning), and, upon new ggez release, move everything from the former to the latter. Crate authors, maintainers, or even users, will then have to PR to move the link "back to top".

[dannyfritz]

Before Love2d had a wiki page for it, all libraries were shared in the forum.

A wiki page in the ggez repo might work too.

[ozkriff]

People will name their crates using ggez- prefix anyway as it's a pretty natural thing to do for small crates that want to be a part of ggez's ecosystem. It's just hard to find a good standalone name for small helper library. And there's no way you can actually forbid people from uploading whatever thay want to crates.io - so newbies still have a pretty good chance of stumbling upon such crates.

I love @Ratysz's suggestion with "moving" list of projects as it mostly moves maintenance burden to crate maintainers - at least we don't need to manually filter-out unmaintained projects. docs/Projects.md in devel branch already does something very similar.

Anyway, I find it hard to image how ggez's ecosystem can function effectively without some kind of such list of helper libraries and tools. And this list automatically solves the problem with ggez-prefixed third-party crates.

[icefoxen]

Yeah that was pretty much the intention of the Projects.md in the first place. I do like the idea of a wiki page though, because just editing a wiki page is easier/faster than making a PR to update a file.

[obsoke]

As a user of ggez, I think a wiki page with a suggested list of helpful crates would be nice. IMO, one of the biggest issues within the Rust crate community is discoverability; there are so many cool crates out there but it can be hard to come across them. It doesn't need to represent a set of officially sanctioned & supported crates; just a list of crates that users have found helpful.

I agree with @ozkriff that preventing people from prefixing crates with ggez- seems like an impossible task. From what I understand, Cargo does not support crate namespacing which is unfortunate as that could have been helpful to separate 'official' crates from user-created/3rd party ones.

[anderspitman]

@obsoke I'm a little embarrassed to admit I just discovered this, but the "Dependent Crates" (example) link on cargo has been very helpful for me when it comes to discovery.

That's only for published crates though. I'm sure a lot of people would find a list of up-and-coming github projects useful as well.

[icefoxen]

Outlined these decisions in the FAQ in commit 693f3a5.

Not sure that's the best place for them, but it works for now.

[ozkriff]

How about some "unofficial prefix"? Because I really can't come up with standalone names for these little crates. Something like ggwp-*: ggwp-zgui and ggwp-zscene (I'm not good at gamers' slang)?

[icefoxen]

@ozkriff If you want, sure!

[icefoxen]

Aha, the perfect official-unofficial prefix: glhf. Good luck, have fun. Pretty much the exact opposite sentiment of ggez. :-P