BYBLACK DUCK

Vote for the next feature

By on March 19, 2008 in blog

With the redesign done, we’re going to start focusing on adding some of the ‘missing-features’ that we’d always planned to have – but hadn’t got around to doing yet.

We know there’s a backlog of back-end features to implement – which we continue to work on. Better importing, more source control systems support, etc.. – we are working on it. However, we need to also beef up our ‘directory’-type features. Here’s a short list of things we’re considering.

About jason

View all posts by jason →
  • http://maraby.org/ mtodd (Matt Todd)

    Screenshots: Bah, lots of projects aren’t visual projects.

    Versions: Call them Releases and yeah, this isn’t a bad idea.

    Platforms: Not a bad idea.

    Categorization: That’s what tabs are for. But really, if you want to, just make some special tags like ‘@db’ or ‘@db::front-ends’ or something like that.

    Advanced Project Search: Barring problems with how projects can be classified incorrectly if they have dependent files (say, clients in multiple languages)… also not a bad idea.

    But really, please allow us to specify some files to NOT count… it not only lets us better shape how our project is viewed, but also removes some processing strain for files we don’t want considered as part of our project like bundled dependencies.

  • jason (Jason Allen)

    @matt: Good feedback, thanks.

    call versions releases – Good suggestion – we’ll do that.

    use tags to classify – Interesting idea. My current impression is that tags have failed as a classification tool – they’re just too random. Having a fixed (hierarchical) categorization would help ensure people use the same terms. I’ll continue thinking about it.

    specify some files to NOT count – I hear your loud and clear concerning the ‘let us specify ignores’ for analysis. We’re currently focused on improving our back-end scalability – to enable timely updates. We’ll get to the ‘ignores’ feature once we have the horsepower to handle the re-evaluations this feature would trigger.

  • http://www.camicom.com iamcamiel (Camiel Vanderhoeven)

    Would it be an option to use CVS tags to identify different releases?

  • jason (Jason Allen)

    @Camiel: Interesting idea – it would make sense. I’ll have to talk to Robin to see if it’s possible – I’m not sure our current importer remembers tags (I think it doesn’t). It would be a shame not to do this. I’ll get back to you on this tomorrow.

  • http://www.splitbrain.org splitbrain (splitbrain)

    What about darcs and mercurial support? Seriously, that’s what everybody is waiting for!

  • http://nitens.org dartar (dartar)

    +1 for darcs/mercurial – there are too many projects out there that Ohloh doesn’t track.

    Also, tracking of branches (on top of trunk) has been a very popular request (and much more urgent than, say, project categorization IMO). Once Ohloh is capable of multiple branch tracking, using tags for automatically identify releases sounds ike the natural thing to do.

  • jason (Jason Allen)

    @splitbrain, @dartar: Robin warned me that people have essentially already ‘voted’ for support for darcs/mercurial/etc!

    Short answer: Supporting more source control systems is entangled in our back-end update that we’re working on. Or, more specifically, some of us are working on. We can’t have everyone work on that at the same time – hence the ideas listed above.

  • http://www.geovista.psu.edu/geoviztoolkit/ geovizer (Frank Hardisty)

    +1 for screenshots, for projects that are visual, it’s the #1 thing people click on.

  • jason (Jason Allen)

    @Frank: I agree. People are visual AND lazy (me included!). Btw – I’ve always loved this GCC screenshot.

  • http://www.entidi.com/ ntd (Nicola Fontana)

    What about building custom stacks? Maybe someone of them can be shared. I’d like also to view Code analysis on them.

    Just my 2 cents…

  • jason (Jason Allen)

    @Nicola: Multiple stacks are coming. Could you elaborate on what you mean by Code Analysis?

  • http://www.entidi.com/ ntd (Nicola Fontana)

    Hi Jason, with Code analysis I mean what you see by clicking on Code analysis for a single project (line counts, language pie chart and such).

    I don’t know if it is easy or not (or ever if it is possible) to join the code analisys data of all the projects on a stack… anyway this was my suggestion.

  • http://nitens.org dartar (dartar)

    Following up on the idea of project releases, it would be great to handle this like freshmeat does and aggregate a list of recently released software on the frontpage. It would also be a nice way to get more developers involved.

  • http://draketo.de ArneBab (ArneBab)

    Specifying platforms, etc. could maybe be done with default tags.

    That way, projects would have predefined tags and freeform tags, and we would no longer see projects with “macosx, mac osx, osx, mac” but simply one selectable “macosx” tag.

    This also wouldn’t restrict developers to having to define their projects the way you lay out.

    It would just make the tags saner the soft way: “You can choose any tag, but we recommend selecting among the following ones: … “

    Then the developers could add special tags for their subcommunities, but the general tags would fit better.

    Also it might be useful to aggregate very similar tags at the time when you create a default tag (and allow developers to add the old tags again, if they really prefer the nonstandard tags).

    Example: When you create the default tag “macosx”, all similar tags like “mac osx, osx” could just be changed to it.

    (beware though that “mac” could mean “mac os 9″ “mac os 8″ or “macosx”)