Suggestions: How are project languages measured?

over 2 years ago

Hi. I see my project languages are measured and the chart shows Javascript on 1st place. While this may be true, Javascript is definitely not the most important language in my project. As a consequence, documentation ratio is pretty low for Javascript, while being excellent for PHP. It would be nice to override the most important language in the project, so visitors can be given the correct impression on development state.

Jason Allen

over 2 years ago

hi stronger,

You bring up a good point. I looked at a few of your recent commits and noticed that they tended to include a lot more PHP code changes than javascript. I suspect your project might contain one (or more) javascript libraries - thereby dwarfing the PHP code you're writing.

I've seen similar cases with smaller Ruby on Rails projects too. Perhaps we should adjust the Ohloh Summary to specify "Mostly Written In..." as the language that contains the most lines of code changed rather than just the largest total lines of code. We'll discuss it tomorrow and get back to you.

dartar

over 2 years ago

The same issue was just reported from the lead developer of Zenphoto (written in PHP but bundling a lot of JS libraries). He pointed out that this not only biases the "Mostly written in" statistics but also produces flawed LOC and project cost estimations (since he obviously didn't write 50% of the code).

Maybe you guys should consider implementing a feature that some users already suggested, i.e. the possibility of marking some folders/files in the repository as dependencies. The ability to cross-reference these dependencies with their Ohloh page (if they are listed as independent projects) would be nice too.

Jason Allen

over 2 years ago

dartar: We've considered this in the past, but one reason we haven't done it yet is because specifying folders/files might require accompanying timestamps. Example:

treat the '/vendor/*' as dependencies only from june 2006 to june 2007

That really scares me as a feature - makes it really hard to write UI that conveys what exactly Ohloh is doing behind the covers (ie: show why a file is being accounted for ... or not). What do you think?

dartar

over 2 years ago

Jason, good point.

I understand that codebase history is crucial for this feature to be implemented, but adding manual timestamps might be unnecessary. A dependency doesn't usually change its status as a dependency over time, right? What happens more often is that it is simply dropped and replaced by another library.

So what about the following idea:

Project maintainers specify a list of files or folders (maybe using wildcards) that should be treated by the code parser as dependencies, whether they are still included in the latest revision or they are old dependencies.
Ohloh determines the portion of code matching this list over time (i.e. every time it checks out the codebase) and calculates the total amount of dependency-related LOC for the codebase history (a 4th category on top of code, comments and blanks)
Chronological information is then derived by looking at the timespan over which a specific dependency path is matched.

For instance, suppose my project used in the past three different libraries as dependencies. I list all the relevant paths in my project's dependency form: