Skip to content
This repository

Link to or integrate with one or more toolbox projects #71

Closed
ato opened this Issue · 12 comments

5 participants

Alex Osborne John Gabriele Phil Hagelberg Nelson Morris Gabriel Horner
Alex Osborne
Owner
ato commented

There's a few different approaches that have been taken:

Clojars really punted on the issue of discovery as it wasn't the itch I was trying to scratch early on but I think there's a general expectation that it should at least act as a gateway to some of these resources.

Anyone have any ideas about how we should go about doing this? We could start just by linking to all of them (and probably ClojureDocs.org as well) from a header or footer or something.

John Gabriele
uvtc commented

Since,

  1. github makes it so easy to fork projects,
  2. clojars makes it so easy to upload, and
  3. maintainership of projects tends to change over time,

it can be difficult for users to find the canonical version of a given library (either the canonical github project page, or the canonical clojars page). The Dining Car seeks to address the problem by:

  • linking to the canonical Clojars page for a given project (rather than the github project page), and
  • letting the user then follow the link at the Clojars project page to the corresponding github project page (assuming that the author has put in a :url value in their project.clj)

If a Clojars page has no github link, I go find the github project and send a pull-request updating their :url.


It appears to me that users have two problems: one (A) is figuring out which library they should use for a given task, and the other (B) is locating the canonical Clojars page so they can identify what needs to go into their project.clj :dependencies to use that library.

I'm not sure Clojars can help with (A), lest it grow a forum or comments or something. I doubt voting would work --- the Python folks tried that with the Cheeseshop and, IIRC, not many folks bothered to vote. I don't think this is a direction Clojars should go in.

Regarding (B), one thing that might be of help (I may have heard this idea from technomancy --- I can't remember) is if Clojars kept downloads/week stats on each project. When a user does a search, the search results would be ranked by this "download density" (most downloads/week listed at the top / first).

I expect the Dining Car to slowly and organically accrete entries (and contributors) over time, and hopefully turn into something valuable for solving problem (A). Right now it's pretty new and does not have many libraries listed.

---John

Phil Hagelberg
Collaborator
Nelson Morris
Collaborator
xeqi commented
John Gabriele
uvtc commented

As for the question of identifying canonical projects, this could be solved if we could find a way to display both the timestamp of the last pushed version and the timestamp of the first pushed version. If this information could be surfaced clearly, I think it would clear up that confusion nicely.

Not sure I see how this would help. If anyone can push a version at any time, then last-pushed-date won't mean much. And if maintainership of projects changes over time, then first-pushed-date won't be of use either.

Phil Hagelberg
Collaborator

@xeqi: good point.

@uvtc: maintainership changes don't affect Clojars, just GitHub. If you hand off maintainership then another git repo could become canonical, but you would add the new maintainer to the Clojars group. For the date I didn't mean that the last-pushed date would help with the canonicity question, just that it's valuable information that happens to make the display of the first-pushed date more complicated to convey clearly.

John Gabriele
uvtc commented

Clojars really punted on the issue of discovery ... Anyone have any ideas about how we should go about doing this? We could start just by linking to all of them (and probably ClojureDocs.org as well) from a header or footer or something.

I think adding some links near the top of the About page could be helpful.

Alex Osborne
Owner
ato commented

I think adding some links near the top of the About page could be helpful.

And the nice part of that is it's trivial to do. Done. :-)

if Clojars kept downloads/week stats on each project

Yep. I really need to find some time to sit down and get it finished. I think we should make this data available as a feed so that other projects like ClojureSphere can make use of it.


For comparison I notice CPAN's main http://www.cpan.org/modules/index.html page has this:

How to find modules

http://search.cpan.org/ - search
Task::Kensho - some recommended modules
Browse:
All modules (a long list)
Authors
Name
Category (not maintained)
recentness

It's interesting they mention category as not maintained. I've got to say I've never found comprehensive categories very useful (or any more useful than search). Task::Kensho seems to be a like the Dining Car, although it takes even more of a prescriptive focus "here's a minimal subset the curators suggest is good" rather than "here's absolutely everything". I like that. I agree that Clojars should be making such judgement calls or curation, it should remain a neutral self-serve but I do think we should point people in the direction of other resources.

One other random idea I've had in the back of my mind for a while is some sort of widget people can use to link to the latest stable version of a project. Ideally something smallish you can embed in a GitHub README or project site that gives you copy-paste text for Lein and Maven, link to the jar page, direct download and project website. Unfortunately I'm not sure it's doable as I guess we can't put a script tag or iframe in github markdown. A few projects like Travis have done tricks with images but that doesn't work so well when you want to copy text!

John Gabriele
uvtc commented

It's interesting they mention category as not maintained.

It was probably maintained early on, when CPAN was much smaller. Perhaps it was manually curated, but then not enough people helped out --- and at the same time the CPAN was just getting too huge.

Task::Kensho seems to be a like the Dining Car, although it takes even more of a prescriptive focus "here's a minimal subset the curators suggest is good" rather than "here's absolutely everything".

Task::Kensho is actually more than that. It's one of the centerpieces of the "Modern Perl" movement. It's the list of modern recommended modules. See enlightened perl and modern perl books for more info.

The Dining Car only goes as far as mentioning at the top, "This directory is not comprehensive" (just added), and "Please endeavor to keep it up-to-date, consisting of libraries you’d recommend to friends. :)"

I could add an "only" in there after "consisting", but wouldn't want to be too brazen. :)

John Gabriele
uvtc commented

Ooof! Earlier I wrote:

(A) figuring out which library they should use for a given task, and ... (B) locating the canonical Clojars page

I expect the Dining Car to slowly and organically accrete entries (and contributors) over time, and hopefully turn into something valuable for solving problem (A).

Dunno why I wrote only (A) there. I'd hope that the Dining Car would address both issues (in particular (B)).

Sorry for the confusion.

John Gabriele
uvtc commented

I think adding some links near the top of the About page could be helpful.

And the nice part of that is it's trivial to do. Done. :-)

Nice!

Gabriel Horner
Collaborator

I'm with @technomancy in that I wouldn't want to add anything that is manual. I'd go one further in advocating to not solve any discovery problems on clojars-web. Fwiw, the "less is more" mantra has served rubygems.org well. Whenever anyone has tried to add more functionality, we'd redirect them to think of what APIs they could use to build out their service separately. I think that has allowed rubygems.org to focus on serving gems well.

As for acting as a gateway, there's no doubt clojars.org will be increasingly seen as one. The wiki seems like a good start and is already accessible at the footer. At some point we could consider formalizing some of the wiki pages into guides. As an example, the ruby community has run their guides as a separate project and linked to it off rubygems.org footer. It seems like clojure.org and clojuredocs.org already does some of this.

Alex Osborne
Owner
ato commented

Thanks all for the excellent suggestions. I'm going to close this now in favour of a few more specific tickets. :-)

  • visually de-emphasize forks (#77)
  • implement download stats (#26).
  • write some guides (#78)
Alex Osborne ato closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.