On 10/08/11 09:45, Peter Murray wrote:
>> Lastly, you may want to look into Drupal's project module. I think that's what they use to run their module directory. It seems like it would be a good starting point and may work out of the box.
> Cool -- thanks for the tip!
You may also be interested in the (older?) work at
http://projects.apache.org/ and http://trac.usefulinc.com/doap For example:
Interoperability with RDF/DOAP lets you build on others work and lets
others in turn pick your work over.
At the very least if allows you to get suck in the latest and greatest
>> Second, the open source site Ohloh has some nice features for characterizing
>> a project, such as languages used, licenses, etc. Here's the page for the
>> same Kepler system in Ohloh:
>> Ohloh is nice because much of its information is harvested directly from
>> links to the open source code repositories for the project, which allows it
>> to show some nice trends in the software project's life.
> A colleague e-mailed me privately about Ohloh as well, and in particular
> the metrics function to tell how viable a project is. I haven't
> lookedat Ohloh yet to see if it is possible to call into its service
> to get themetrics for registered projects, but at the very least this
> kind of project activity statistics is an important point for
> considering an open source package and I'd like to find a way to get
> it into this registry.
Ohloh is great. However it relies almost completely on metrics which are
easily gamed by the technically competent. Use of these kinds of metrics
in ways which encouraging gaming will only be productive in the short
term, perhaps the very short term.
For example: it's easy to set up dummy version control accounts and
there can be good technical reasons for doing so. It's easy to set up a
build/test suite to update a file in the version control after it's
daily run and there can be good technical reasons for doing so. But
doing these things can also transform a very-low activity single user
project into a high-activity dual user project, in the eyes of ohloh.
Turning on template-derived comments in the next big migration handles
the "is the code commented?" metric.
The more metrics are used, the more motivation there is to use tools
(which admittedly have other motivations) which make a project look good.
> On Aug 7, 2011, at 4:10 PM, stuart yeates wrote:
>> On 06/08/11 10:27, Peter Murray wrote:
>>> Well, we certainly don't want to get into a situation where we find it is turtles all of the way down.
>> Am I right in parsing that as "we have consciously decided to make the
>> registry blind to the concept of visualisation." ?
>> Given that visualisation is such a huge trend at the moment, good luck
>> with that.
> Stuart -- I apologize for not fully understanding your point; I think we are talking past each other. I don't see how limiting the scope of the definition of "Package" to just library-related or library-specific entities makes a statement one way or another on visualization.
General-purpose package modelling allows concepts such as virtualisation
to be modelled using other package relationships. Library-specific
package modelling requires visualisation (and by implication the next
big development in that field) to be explicitly modelled.
Library Technology Services http://www.victoria.ac.nz/library/