Is there any timeline for this? I've come across some corporations which really would like an easy way to address this, and in fact at mozilla.org, a non trivial amount of triage time is spent trying ... [More] to find the tracker for various extensions/plugins/random applications which each have their own hard to find web sites. I'd really love to be able to simply visit ohloh and get a link to the bug tracker. Even if the bug tracker isn't searchable. I understand that at the beginning I'd probably be filling in the links more often than I'd be finding them, but this really doesn't bother me. It's also not immediately important for me to be able to use ohloh to search the bug tracker, although I recently described to a large entity how such a feature could be useful. And yes, Mozilla projects are still waiting to see Mercurial support from ohloh, but we're already growing tools to handle Mercurial. We don't have much interest in growing a tool to map the world of software projects to record where their bug trackers live - this is something that I eagerly await from ohloh. [Less]

How can I mark someone else as another manager? (I'm not trying to abandon the field, I just want to mark a couple of other people as also being managers.)

Some mozilla related projects are complaining about being called shell script based projects because of a single file (configure). Configure (typically generated by configure.in) is interesting in ... [More] that it's likely to get thousands of small changes. As such total commit count is not going to solve the problem of "total lines of code misdetermines the language" For reference: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/configure 1.1916 cltbld 2007-10-13 14:21 Automated update from host egg.build.mozilla.org Configure of course tends to be massively long. Unfortunately, a java project which commits its javadoc (or a perl project that commits its html generated pod) will be dwarfed in the total number of files (documentation > sources). I think the trick is to try to generate an algorithm that determines "copying". If configure seems to be a derivative copy of configure.in (good luck), or foopy.html seems to be a derivative copy of foopy.pl / foopy.java, then it should be discounted. I'm not sure how well that'll work, a project with heavy manual documentation will probably still be penalized, but overall it might enable you to count by numbers of files. Another thing you could do is drop languages used in only one file. I was wondering if this would penalize the mozilla despot project (which I believe is not yet imported into ohloh, I might do that just to see what happens) http://mxr.mozilla.org/webtools/source/despot/ From memory, despot basically has one file (despot.cgi) and a help file (help.html), but it does actually have a couple of other .pl files, so today it'd probably be counted as perl. When enough of despot is converted to use .templ's, despot would probably be called html. And I don't know that I'd mind. Probably the simplest solution is to list the major language, and the second language and a note about which calculation would make the second language the major language. It of course only works for 2, and would fail for perl+html+js, but it should probably help for configure :). [Less]

Provide a way to delete projects created by bots and confused users. Someone mass added a gforge domain. I was consulted in advance and said something like: It's OK as long as they don't make a ... [More] second copy of the project I already set up. Unfortunately the slave went about and created the project anyway and while I can find a way to delete the enlistments. I can't find any way to delete the project. the proper project is: http://www.ohloh.net/projects/6783 the poor project which should not exist is: http://www.ohloh.net/projects/7463 it was created by "ohloh_slave". I understand that ohloh relies heavily on bots, but the fact that there's no way to counter all their actions is fairly frustrating. [Less]

it'd be very helpful if this could be shared among multiple projects. mozilla.org has quite a few projects with shared engineers. Trying to fill in alias tables for dozens of copies of nearly identical user lists is very painful.