New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

What categories should be available on crates.io? [BIKESHED ALERT 馃毑馃彔馃毃] #488

Merged
merged 35 commits into from Jan 17, 2017

Conversation

Projects
None yet
@carols10cents
Copy link
Member

carols10cents commented Dec 7, 2016

TL;DR

Categories are coming to a crates.io near you! Help decide what categories should be made available!

Take a look at the diff and consider:

As a crate user:

  • Are the proposed categories all things that would fill in the blanks in statements like "I want a crate for ______" or "I want a crate that is a _____" or "I want a crate that does ______"?
  • Are there any categories missing that you have gone to crates.io in search of?
  • Are any of the proposed categories confusing, ambiguous, or duplicates?
  • What changes would you propose to fix the above issues?

As a crate author:

  • Are you struggling to decide what category your crate would fit into, in order for people to be able to find your crate for its intended use case? If so, why? (note: a crate can have up to 5 categories)
  • Is the category you would want your crate to be in missing?
  • What changes would you propose to fix the above issues?

Details

  • I have made an assumption/decision that categories should mostly be about the use case and purpose of a crate, and not for other attributes such as operating system support, development maturity, compatibility with other libraries, license, etc, and that we should address those attributes in another manner like badges. This is a different decision than, for example, PyPI classifiers, where "classifiers" are what I'm calling "categories", and classifiers exist for all these axes including a "topic" classifier type. I'm proposing that we limit crates.io categories to the equivalent of PyPI topic classifiers. If you disagree with this assumption/decision, please note that as well, I'm open to changing my mind on this.
  • This initial set of categories was adapted from Awesome Rust.
  • Format of categories.txt
  • Once we decide on an initial list of available categories, the list can be changed by submitting a pull request to this file, which is the source of truth for category info. The crates.io database gets synced with this file when the server boots.
  • Categories are different from keywords because:
    • Anyone can start using any keyword without having to go through a PR
    • Since available categories are curated, they should be higher quality than keywords (ex: we won't have categories for both math and mathematics
    • Categories' purpose is to aid browsing, while keywords aid searching since they are included in search rankings (categories won't be).
  • Note that an RFC for the default ordering in which crates within a category are presented is coming; the current implementation for categories lists crates alphabetically.

@carols10cents carols10cents referenced this pull request Dec 7, 2016

Merged

Add Categorization! #473

@carols10cents carols10cents force-pushed the integer32llc:proposed-categories branch from 94c1742 to 85ff1fe Dec 7, 2016

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Dec 7, 2016

My first thought reading through is that there's a hierarchy of structured data. Representing that in a line-oriented manner is sub optimal. There's repetition of aspects like the English text for each category that seems brittle. I also am confused what would go in a category like libraries::computation, so I'd love a brief description for that.

Some hypothetical JSON including these ideas:

[
    {
        "slug": "libraries",
        "title": "Libraries",
        "description": "Libraries are the powerhouse of the cell",

        "children": [
            {
                "slug": "astronomy",
                "title": "Astronomy",
                "description": "Astronomy is the study of the things 'up there'. These libraries help in that pursuit"
            }
        ]
    }
]

Although I'd expect it to be TOML, really 馃槆

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 7, 2016

My first thought reading through is that there's a hierarchy of structured data. Representing that in a line-oriented manner is sub optimal. There's repetition of aspects like the English text for each category that seems brittle. I also am confused what would go in a category like libraries::computation, so I'd love a brief description for that.

Some hypothetical JSON including this:

I like the JSON, especially with the ability to add a description. Should it be TOML tho? :)

[[categories]]
slug = "libraries"
title = "Libraries"
description = "Libraries are the powerhouse of the cell"

[categories.children] 
  slug = "astronomy"
  title = "Astronomy"
  description = "Astronomy is the study of the things 'up there'. These libraries help in that pursuit"

The current text representation came from me starting out with just the display name for each category per line, then @alexcrichton suggested adding slugs in a simple way. Alex, wdyt about switching to JSON or TOML? (I know you're at #mozloha, I don't expect a quick response, but I don't want to put the work into doing this until you have a chance to weigh in 鉂わ笍 )

@BurntSushi

This comment has been minimized.

Copy link
Member

BurntSushi commented Dec 7, 2016

Ah this looks cool! I've got two thoughts/questions. :-)

First, can a crate belong to more than one category? If the answer is yes, then I feel like this makes it more like a tag concept than a categorical one, but that's just my own perspective. I don't know if others feel the same way.

Second...

I have made an assumption/decision that categories should mostly be about the use case and purpose of a crate, and not for other attributes such as operating system support, development maturity, compatibility with other libraries, license, etc, and that we should address those attributes in another manner like badges. This is a different decision than, for example, PyPI classifiers, where "classifiers" are what I'm calling "categories", and classifiers exist for all these axes including a "topic" classifier type. I'm proposing that we limit crates.io categories to the equivalent of PyPI topic classifiers. If you disagree with this assumption/decision, please note that as well, I'm open to changing my mind on this.

I feel like this is a reasonable starting place. But let's say a year from now we wanted to change our minds and expand our categories into things other than just topic classifiers. Would that be feasible to do?

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 7, 2016

First, can a crate belong to more than one category?

Yes, up to 5.

If the answer is yes, then I feel like this makes it more like a tag concept than a categorical one, but that's just my own perspective. I don't know if others feel the same way.

To me, the current keyword functionality is more like tags, for the reasons I have in the description under the bullet point "Categories are different from keywords because:".

Can you elaborate a bit on what the difference is, to you, between keywords and categories and tags, and how to best communicate that?

I feel like this is a reasonable starting place. But let's say a year from now we wanted to change our minds and expand our categories into things other than just topic classifiers. Would that be feasible to do?

Minimally, we could add additional categories with different semantics to this file, perhaps by adding some "top level" categories to distinguish them. I would not recommend adding the top-level "Topic" category like PyPI has at that point, since everyone would need to update their Cargo.tomls. I suppose we could just change the display name of existing categories to add "Topic::" or similar, with the understanding that the slugs wouldn't have that (and potentially be confusing).

@BurntSushi

This comment has been minimized.

Copy link
Member

BurntSushi commented Dec 7, 2016

To me, the current keyword functionality is more like tags, for the reasons I have in the description under the bullet point "Categories are different from keywords because:".

Can you elaborate a bit on what the difference is, to you, between keywords and categories and tags, and how to best communicate that?

Ah I see. I guess I feel like tags express a many-to-many relationship where as categories express a one-to-many relationship. I think keywords is the right word for what we have now, because they express a many-to-many relationship and are not curated. I guess I see tags as things that are curated, but also express many-to-many relationships.

This is all kind of subjective though. I think you might have been coming at it from the curated/uncurated perspective where as I'm coming at from the relationship perspective. No clue which one is right!

Minimally, we could add additional categories with different semantics to this file, perhaps by adding some "top level" categories to distinguish them. I would not recommend adding the top-level "Topic" category like PyPI has at that point, since everyone would need to update their Cargo.tomls. I suppose we could just change the display name of existing categories to add "Topic::" or similar, with the understanding that the slugs wouldn't have that (and potentially be confusing).

Ah cool that seems reasonable to me!

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 7, 2016

I feel like this is a reasonable starting place. But let's say a year from now we wanted to change our minds and expand our categories into things other than just topic classifiers. Would that be feasible to do?

Minimally, we could ....

Oh, thought of another thing we might want to add if we have categories for multiple dimensions... the way you navigate through classifiers on PyPI is that you can select any number of them to find libraries in the intersection. Try it out!

One of the reasons I'm not so much a fan of this approach is that I'd want the ability to filter searches for some of these attributes as well, not just while browsing through topic categories (ex: search for "piston", which isn't a category, and limit to crates with windows support only), and it doesn't appear that PyPI lets you do that. IMO it'd be awesome if we had sorting/filtering mechanisms that worked for both browsing and searching.

@lise-henry

This comment has been minimized.

Copy link

lise-henry commented Dec 7, 2016

Is this the good place to suggest categories? If yes, I'd like to suggest "(libraries::)internationalization".

(Also, not sure I get why there are separate categories for applications and libraries instead of e.g. having a separate flag?)

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 7, 2016

Is this the good place to suggest categories? If yes, I'd like to suggest "(libraries::)internationalization".

Yes it is!! Adding that one now :)

(Also, not sure I get why there are separate categories for applications and libraries instead of e.g. having a separate flag?)

I could be argued out of it :) I mostly did that because that's what Awesome Rust did!

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Dec 7, 2016

One potential ambiguity: do the various development-tools::ffi::(language) categories exist solely for tools that help people interface with those languages (such as binding generators or FFI helper libraries), or do they also include bindings to the core libraries of those languages (such as libpython bindings), or do they include bindings to non-core libraries of those languages as well?

If those categories have one of the broader meanings, I'd suggest widening the names from development-tools::ffi::(language) to development::ffi::(language) (or dev::ffi::(language)). If those categories have one of the narrower meanings, then I'd suggest adding an additional category for the other meanings.

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 7, 2016

I have mixed feelings about this.

I do think that better discovery mechanism is definitely needed 鈥 currently homepage features very little content ("most downloaded" crates are boring), and exploring crates by alphabetically sorted names doesn't really work.

I'm a little bit worried about adding predetermined categories. This seems like a top-down decision strongly suggesting what Rust is intended to be used for. It's a change from a bottom-up approach of a soup of tags where anything goes. I worry it may be discouraging writing something that doesn't fit any category, or that is in a category that's much smaller than other categories. Maybe categories could be built from most popular tags? (after cleanup of synonyms)

Being able to choose multiple categories is weird. To me it makes sense to have one primary category + keywords. Otherwise it overlaps with tags too much, especially when anybody can put their package into a category (i.e. categories are just another form of tag search, rather than curated collections/showcases).

It'd make sense to me if categories were tags, i.e. packages tagged with a category-related tag appear in that category.

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Dec 7, 2016

The applications:: categories seem to lack a few areas. For instance, they include applications::audio, but no video or multimedia. I'd suggest either adding those or making a single applications::multimedia category for all of them.

It might make sense to have a category for type of UI: applications::gui versus applications::cli, and possibly applications::repl.

I feel like libraries should have a category for libraries that exist specifically to solve Rust-specific problems, as opposed to some specific problem domain. For instance, libraries like owning_ref and rental.

Finally, I think the existing categories need to distinguish between "graphics" (which should include things like image formats and drawing libraries) and "gui" (which should include things like toolkits and user-interface libraries).

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 7, 2016

Now, the bikeshed:

  • The file is hard to read. My first thought was 鈥 why did you lowercase "python", and why "python Development Tools" is a subcategory of the "FFI" category?

  • I hope to cross-compile from Mac to Windows, so "Embedded::Cross compiling" seems too narrow.

  • There's ruby and mruby FFI. Does Rust have that many packages for each? Shouldn't it be ffi::ruby::mruby or just one category (with details handled via tags?)

  • libraries::command-line-argument-parsing could be subcategory of libraries::command-line-interface

@Luthaf

This comment has been minimized.

Copy link
Contributor

Luthaf commented Dec 7, 2016

Let's bikeshed !

development-tools::debugging Development Tools::Debugging
development-tools::debugging::gdb Development Tools::Debugging::GDB
development-tools::debugging::lldb Development Tools::Debugging::LLDB

I see the point of development-tools::debugging, but having sub-categories for GDB and LLDB feels weird: do we really expect to have a lot of crates in these categories?

development-tools::ffi Development Tools::FFI::*

How do we decide which language gets in this list of categories? For example I see both mruby and ruby, but no micro-python. C++ as a well known language is missing too, Objective-C is there but not Swift or Go.

libraries::astronomy Libraries::Astronomy
libraries::bioinformatics Libraries::Bioinformatics
libraries::machine-learning Libraries::Machine learning

I would unify these two categories in a libraries::science category, and maybe have a full hierarchy here:

libraries::science::math
libraries::science::physics  <= contains astronomy
libraries::science::chemistry
libraries::science::biology  <= contains bioinformatics
libraries::science::machine-learning
 ...

Having subcategories (libraries::science::physics::astronomy, libraries::science::biology::bioinformatics, etc.) could be appealing, but seems a bit premature given the number of existing scientific crates.

libraries::command-line-argument-parsing Libraries::Command-line argument parsing
libraries::command-line-interface Libraries::Command-line interface

These two could be unified too.

libraries::computation Libraries::Computation

As @shepmaster, I do not see what would fit in there.

(Also, not sure I get why there are separate categories for applications and libraries instead of e.g. having a separate flag?)

I could be argued out of it :) I mostly did that because that's what Awesome Rust did!

I feel the same, for example my next project to be released on crates.io will be both an application and a library, plus the extra libraries/applications takes a lot of space and create noise.

@Luthaf

This comment has been minimized.

Copy link
Contributor

Luthaf commented Dec 7, 2016

Also, we could maybe use the most used tags on crates.io as a starting point for the category list.

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 7, 2016

  • "cloud" is vague and probably overlaps with web-programming::deployment

  • I don't know in which category I'd put analytics software (like https://piwik.org)

  • Is crates.io intended for non-developers? The distinction between applications and libraries seems good for me on assumption that a non-technical user will be able to use apps, but won't have use for libraries. But if the whole site is for developers only, then maybe there's no point using that as top-down category.

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 7, 2016

Maybe categories could be built from tags the way StackOverflow does it?

Every tag search page has "Related tags" in sidebar that narrows down the search:

https://stackoverflow.com/questions/tagged/rust
https://stackoverflow.com/questions/tagged/rust+ffi
https://stackoverflow.com/questions/tagged/rust+ffi+python
https://stackoverflow.com/questions/tagged/rust+ffi+python+numpy

That seems to automatically create a good hierarchy.

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 7, 2016

Also, we could maybe use the most used tags on crates.io as a starting point for the category list.

Maybe categories could be built from most popular tags? (after cleanup of synonyms)

Here's all the keywords. Top 20, would any of these be good categories that aren't already covered here?

  • ffi 495 crates
  • windows 452 crates
  • winsdk 400 crates
  • google 228 crates
  • api 175 crates
  • web 175 crates
  • protocol 164 crates
  • cli 143 crates
  • parser 90 crates
  • graphics 82 crates
  • database 82 crates
  • crypto 77 crates
  • piston 71 crates
  • audio 65 crates
  • bindings 64 crates
  • math 62 crates
  • macro 59 crates
  • text 58 crates
  • json 57 crates
  • plugin 56 crates

I'm a little bit worried about adding predetermined categories. This seems like a top-down decision strongly suggesting what Rust is intended to be used for. It's a change from a bottom-up approach of a soup of tags where anything goes.

I didn't start from the keywords because I personally don't find the current keywords useful at all, and it's mostly because of the "anything goes" approach. For example, crates with the CLI keyword include argonaut, "A simple argument parser" to help you build CLIs, and betsey, "An AppVeyor cli written in Rust", which is an application with a CLI for use with a particular tool, appveyor.

And technically this is an addition, not a change. Adding categories is not getting rid of keywords, and people can add both to their crates and use either to find crates they're looking for.

I worry it may be discouraging writing something that doesn't fit any category, or that is in a category that's much smaller than other categories.

I get what you're saying here, and I don't want to discourage anyone. Perhaps adding some documentation to the "All Categories" page about how to send a PR to suggest a new category would help?

Many other package websites have categories in ways similar to this, and I haven't experienced or heard of any problems like this. Have you? I'd be really interested, especially if there are any blog/forum posts discussing this from other communities!

I will be addressing the actual category bikeshed comments in a bit, wanted to speak to some of the meta-comments first :)

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 7, 2016

libpng and Unreal Engine would probably both end up in Graphics category, which doesn't feel right (there's no specific category for 3d engines or image encoding).

@dpc

This comment has been minimized.

Copy link

dpc commented Dec 8, 2016

Just my 2c.

I wish we could have some community-driven tag-based system.

Eg. Maybe in Cargo.toml one could add tags to dependencies. Eg.

[dependencies]     
tokio = "1" #async #aio    
log = "1" #logging     
nom = "1" #parsing    
serde = "1" #serialization  
serde-json = "1" #json #serialization  

This way crates.io could use it as "votes", and each popular crate would get described by people that actually use it. Plus tags like that serve as a nice documentation of dependencies.

Wild idea, I know.

@Diggsey

This comment has been minimized.

Copy link

Diggsey commented Dec 8, 2016

Categories are a lot like OO class hierarchies, and I think the problems there will carry across (diamond inheritance and being unable to find a good structure that every crate can fit into). I think it could be OK as long as the hierarchies are kept relatively shallow.

What if within each category, crates.io could show "pseudo sub-categories" based on the most common tags within those categories?

For example, instead of trying to list up-front all the sub-categories for "dev tools", explicit categorisation could stop there, and then within "dev tools", crates.io would look at the common tags within that category (eg. "testing") and show those as the next layer of subcategories. At some point later those common tags could be promoted into a full subcategory.

It could choose tags to show based on what fraction of the crates have the tag - ideal tags would be those where approximately 1/n crates have the tag, where "n" is the desired branching level of categories, say 10. The tags which come closest to this ratio would be shown as pseudo-subcategories (listed after any actual subcategories).

This relies on being able to put crates into categories which are not leaf nodes on the tree of categories - is that possible? I think it should be possible to put a crate directly in the "Libraries" category without putting it in one of the sub-categories.

@nagisa

This comment has been minimized.

Copy link

nagisa commented Dec 8, 2016

Something I want to chime in about categories.

As a crate author, I have hard time picking out categories. Mostly because I鈥檓 a lazy goon and dislike running through a list of ten hundred strings to pick five best fitting to my crate. This probably signifies that I鈥檓 much more comfortable with a list of ten (not tens of hundreds) very generic categories from which I pick one.

Whatever way this feature goes, I鈥檒l probably end up not using it, but having less categories rather than more will certainly make me more prone to the appeals of categories :)

@nokaa

This comment has been minimized.

Copy link

nokaa commented Dec 8, 2016

I agree with nagisa; too many categories defeats the purpose. I think that categories should not be added, and instead more emphasis should be placed on tags.

Differentiating between libraries and applications is something that would be very useful. Perhaps a more advanced search allowing for filtering of libs/applications and easier searching of tags. We already have tags as a part of the Cargo.toml; to me a better solution would be to display tags and allow searching for specific tags.

@LeopoldArkham

This comment has been minimized.

Copy link
Contributor

LeopoldArkham commented Dec 8, 2016

I have a file size humanization library, I don't think it fits in an existing category, and I'm not sure what to suggest.
I guess it's a utility maybe? That's fairly vague but it might be a good way to catch other such crates.

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Dec 8, 2016

What many sites do is call everything a "tag", but distinguish between a small list of "official" tags that have a defined hierarchy and descriptions, and arbitrary "freeform" tags. Both would appear in the same tag list within crates, but the site would prominently show official tags with descriptions, while using freeform tags just for search.

@Keats

This comment has been minimized.

Copy link

Keats commented Dec 8, 2016

I think tags (I think of tags and keywords as the same thing) and a better search would be better than categories.
Searching for markdown and sorting by downloads has those results: http://imgur.com/a/khg7P

2 issues looking at that screnshot:

  • it's not sorted by downloads (Imentioned it in #396)
  • why is clippy number 2 when they don't mention markdown in the description or the tags

If we end up having categories, I'd agree with @BurntSushi and have only one possible category. The fact that categories are curated is not a big enough reason to have several imo.

If we have categories, I'd imagine something like (didn't list possible categories):

bin:
   - games
   - audio etc
library:
   - ffi
   - science
   - web
   - cli
   - graphics
   - gamedev
   - crypto
   - database
   - markup etc

In short:

  • 2 top levels, not 3
  • just another level after the top one, no sub-subcategory
  • fewer categories than what the current diff shows

Category should just be there to give a general idea, we have keywords for filtering down.

Aside: Is the full crate.io data available (ie with description, tags etc)? The index only seems to contain what cargo needs.

@jethrogb

This comment has been minimized.

Copy link

jethrogb commented Dec 8, 2016

I'm missing categories for several of my crates:

  • alloc_buddy_simple. (unless you think this should go under data structures)
  • enclave, enclave-interface, sgx-isa, sgxs. These are all support libraries for very specific CPU features. The broadest category I can come up with is libraries::hardware-support or something like that.

Will there be descriptions and/or a manual to go along with the categories? For example I think it'd be important to note that libraries::hashing is not libraries::cryptography. And I'd like some guidance for where to put my library-example crates (same as library? applications? development tools?).

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 8, 2016

One potential ambiguity: do the various development-tools::ffi::(language) categories exist solely for tools that help people interface with those languages (such as binding generators or FFI helper libraries), or do they also include bindings to the core libraries of those languages (such as libpython bindings), or do they include bindings to non-core libraries of those languages as well?

If those categories have one of the broader meanings, I'd suggest widening the names from development-tools::ffi::(language) to development::ffi::(language) (or dev::ffi::(language)). If those categories have one of the narrower meanings, then I'd suggest adding an additional category for the other meanings.

I think If I were looking for a library to help me FFI with, say, Ruby, I probably wouldn't have a preconception necessarily about whether a binding generator/FFI helper library or a binding to libraries of those languages would be what I wanted, so I think the categories should have a broader meaning. Anyone who has more experience searching for FFI related crates, please chime in if this isn't the case for you!

I think I'm just going to move the FFI categories beneath "Libraries" for now, since most of the tools I know of integrate with your code in a library fashion somehow. Are there any purely external applications that do, say, binding generation?

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 8, 2016

The applications:: categories seem to lack a few areas. For instance, they include applications::audio, but no video or multimedia. I'd suggest either adding those or making a single applications::multimedia category for all of them.

Multimedia sounds good :)

It might make sense to have a category for type of UI: applications::gui versus applications::cli, and possibly applications::repl.

I'm a little unsure about this one. I'm trying to imagine going to crates.io and saying "I really want an application that has a GUI today, to do X". I feel like I'd just want to do X and not particularly care about the interface. Can you give an example of a case where these categories would be useful?

I feel like libraries should have a category for libraries that exist specifically to solve Rust-specific problems, as opposed to some specific problem domain. For instance, libraries like owning_ref and rental.

Adding Libraries::Ownership, wdyt? Any others?

Finally, I think the existing categories need to distinguish between "graphics" (which should include things like image formats and drawing libraries) and "gui" (which should include things like toolkits and user-interface libraries).

Added Libraries::GUI; this is definitely one that a description would help with.

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 14, 2017

The categories should be curated. Shouldn't that means that assignment of crates to categories should be as well?

I don't think that necessarily follows. I think the guidance of what categories are available will be enough for crate authors to categorize their crates in a useful fashion; once this PR is merged, @shepmaster and I plan to send PRs to popular crates to help seed the categories with crates.

If not the crate authors, who do you propose should do this work?

That could also handle author failing to find the right category and not having to upload a new version just to change the classification.

We've considered adding a command to cargo to update metadata only; as we add more metadata, that command becomes more important, definitely, it's just that no one has implemented it yet.

@carols10cents carols10cents force-pushed the integer32llc:proposed-categories branch from ff836db to 2c1b405 Jan 14, 2017

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 14, 2017

Ok, I decided I've been convinced to remove the top-level Application and Library categories (but I kept the top level Developer Tools category). I moved all the subcategories up to the top level and merged them together where appropriate.

The thing that tipped my decision is that now on /categories, you see 37 categories available, instead of only 3 (Applications, Developer Tools, and Libraries). I think this makes it clearer, sooner, the breadth of all the different kinds of crates available and makes a better first impression. Here's a preview:

Preview of what the main category list page will look like

I'd like to get a general sense of what everyone who's contributed to this issue thinks of this late, big change, if you have a minute please add a reaction to this comment:

  • If you like the current version WITHOUT the top-level Applications and Libraries categories and think this is good enough to deploy, please add a thumbs-up.
  • If you think the previous version WITH the tep-level Applications and Libraries categories was better, please add a thumbs-down.
  • If you think there are other modifications that should be made before this is deployed, please leave a comment.
@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 14, 2017

"HTTP API wrappers" sounds too restrictive to me; there are probably plenty of api-wrappers not using HTTP. I also don't think it's easy to confuse with "external bindings" as the latter is still called ffi. I wouldn't call a crate which helps calling Ruby functions an "api wrapper"... Maybe rename "external bindings" to "external ffi bindings" or something like that? "external bindings" is pretty vague, maybe?

@LukasKalbertodt In the last commit when I was merging the libraries and applications together, I also added "API bindings" ("Wrappers of specific APIs for convenient access from Rust. Includes
HTTP API wrappers.") and changed "External bindings" to "External FFI bindings".

@LukasKalbertodt

This comment has been minimized.

Copy link

LukasKalbertodt commented Jan 14, 2017

馃寛 @carols10cents Having only three categories shown at the top level (/categories) may look suboptimal, I agree. But I'd prefer to have a proper category tree instead of something too flat.

It seems like the main reason for your decision to flatten out the tree is a visual one. Why not fix this by displaying the categories in a different manner instead of removing semantics from the category-tree? For example, we could have a special rendering rule for /categories which renders two levels of categories. Then everyone would clearly see the whole breadth of available categories, but one could still search in, for example, "applications" only.

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 15, 2017

It seems like the main reason for your decision to flatten out the tree is a visual one.

That was only the last reason for my decision :) The other factors include:

  • "Application" and "Libraries" are not really "topic" areas and could better be expressed with an icon or a badge
  • Some crates have both an application and a library
  • Sometimes you might be fine if there was either a tool or libraries that could be used to build a tool to accomplish some task

Relevant comments:

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 16, 2017

If no one comments on this today, I'm going to say it's done...

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 17, 2017

Whew. Ok @alexcrichton, I think we're at least out of objections to the current color of the bikeshed :)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jan 17, 2017

Awesome, thank for pushing this through @carols10cents!

@alexcrichton alexcrichton merged commit 6df510b into rust-lang:master Jan 17, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@carols10cents carols10cents deleted the integer32llc:proposed-categories branch Jan 17, 2017

@tomaka

This comment has been minimized.

Copy link
Contributor

tomaka commented Jan 24, 2017

Err I just realized that it's impossible to ever remove a category, since crates put the category name in their Cargo.toml.

Now I regret not continuing the discussion about the huge imbalance between gamedev and non-gamedev categories.

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Jan 24, 2017

Err I just realized that it's impossible to ever remove a category, since crates put the category name in their Cargo.toml.

It is not impossible: crates that have invalid categories in their Cargo.toml will still get published, just with a warning in the output of cargo publish that directs them to take a look at https://crates.io/category_slugs.

Or was there something else you mean by "impossible"?

@tomaka

This comment has been minimized.

Copy link
Contributor

tomaka commented Jan 24, 2017

Or was there something else you mean by "impossible"?

No, that's what I was thinking of.
I thought you'd get an error when publishing, which you be quite bad IMO.

If categories can be changed then it's ok to see in practice which categories will be full and need to be split, which categories will be empty and could be removed, and which categories are missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment