 |
 |
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: http://projects.apache.org/projects/xindice.html / http://svn.apache.org/repos/asf/xml/xindice/trunk/doap_Xindice.rdf 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 releases automatically. >> 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: >> https://www.ohloh.net/p/kepler >> >> 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. cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/