What should the ohloh homepage look like?

In a previous post I criticised ohloh homepage for being completely useless for current users of the site. This was somewhat unfair, since I provided no concrete constructive suggestions as to what should be on the page. This blog post, hopefully, fixes that.

To my mind there are two classes of information that should be on the homepage: (a) things that lots of users are confused about and (b) things that are 'new' (think customised rss feeds) (c) combinations of both.

Finding out what people are confused about is easy, just look in the forums, where people are most confused about:

1. changes in their kudos
2. why their enlistment hasn't been updated
3. why version control system of choice isn't supported

The list of 'new' things is:

1. new / updated projects
2. new / updated users
3. new / updated enlistments
4. new forum posts
5. new RSS items in projects RSS feeds

These (1), (3) and (5) can be filtered by the users connection to the project (contributor/user/none).

So the trick now is to find combinations which help users understand what's going on and encourage users to engage with ohloh and the projects.

Idea X: A feed of updated enlistments a user is a contributor or user of:

• Project A's enlistment at http://example.com/git updated 24st June 2008 at 24:50 GMT. A, B and C are the biggest commiters to this project, which is in Java and XML. Last updated 1st Feb 1970.
• Project B's enlistment at http://example.com/git updated 24st June 2008 at 24:50 GMT. D, E and F are the biggest commiters to this project, which is in C and shell script. Last updated 1st Feb 1970.
• Project C's enlistment at http://example.com/git failed at or about revision 12345. Click here for instrustions on what to do about this. Last updated 1st Feb 1970.
• ...

This not only tells user the status of their projects, but that enlistments are being processed, the expected time between each processing of enlistments, that some processing fails and that there's a link to find out more information. Such a feed also focuses attention on the processing of enlistments---which is the heart of ohloh and the key differentiating factor that seperates ohloh from 15 billion other open source sites.

Idea Y: A mixed feed of upstream bugs that effect ohloh performance and functionality:

• Ticket "support for .xcu file format" updated in ohcount by user "batman"
• Post "jabber message length" updated in Help! forum by user "someone else"
• Ticket "svn branch support" updated in ohloh by user "robin"
• Ticket "bzr support in ohloh" created in ohloh by user "joker"
• Post "jabber message length" created in Help! forum by user "someone"

This lets people keep up with the status of ohloh progress on issues such as the implementation branch support for svn and support for hg.

New ohloh look and feel

ohloh have changed their look and feel, and I've got to say I hate it.

Once you're logged in, almost nothing above the scroll cut on the front page is useful---we already know what ohloh is and don't need bandwidth-hogging ads to tell us. What we need are deep links into new stuff---projects, users and forum posts.

How about logged in users see content rather than ads on the homepage?

Tinkering with ohloh

I've been tinkering with www.ohloh.net, which is probably best described as a web 2.0 freshmeat. Rather than tracking manually-updated releases it relies on automatically detected updates to version control repositories, RSS and geo-urls. It relies on wiki like editing rather than the strict ownership rules of freshmeat. ohloh does automatic language detection and source code analysis based on the version control repository and attributes individual commits to specific developers and their ohloh user account.

I've added and am actively curating a group of go/baduk projects. The overall goal is to encourage reuse and reduce the willingness of hackers to rewrite go/baduk systems from scratch.

My next step on the technical side is to write some GRDDL (Gleaning Resource Descriptions from Dialects of Languages) to transform the XML returned by the API into RDF, which I can them import into simal.

My next step on the social side is to mention what I'm doing in some of the go/baduk mailing lists, but I want to wait until I've got something concrete to provide that Sensei's Library (the current repository of information about go/baduk programs) hasn't already got.