> On Jan 30, 2017, at 11:42 AM, Leif Andersen <l...@leifandersen.net> wrote: > > I don't think that the solution is to make core packages first class, and > community ones second class. That looses the spirit of what we're going for > here. But maybe we could have in our documentation a way for users to select > what packages they want to show up in search results. That way all packages > are equal here, and a person who wants to, say, only use core packages, can > get that.
To be fair, not all core packages are superior to their community variants. For instance, `parser-tools` is core, yet has been called "strange and klunky" compared to "modern Racket". [1] Whereas the `ragg` package is a much nicer — dare I say more Rackety — interface to `parser-tools`. So if Racket's policy is to let the boundary between core & community remain porous, then it seems consistent to let these packages compete on an even footing. > An alternative approach which probably takes less effort is to just have two > documentation pages. One for core packages, and one for community packages. > Obviously we should still make 3rd party packages feel like first class build > in stuff, but if we just host them at a different URL, that might be enough > to keep things clear. Recently we added a Racket logo to the upper right of the public doc pages. We could do something where this logo changed depending on whether the package belonged to core or community or whatever. Then we wouldn't need to actually cleave the docs into two websites (which IMO is counterproductive). Later we can get to Yelp-style star reviews: "Meh, I've experienced better mutable vectors." [1] https://groups.google.com/d/msg/racket-dev/pVcE3hdsfbM/U8dBBcPfCAAJ -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
