NetworkLabs - Latest Comments

Re: How Far Does a Tweet Travel?

Kate J — Mon, 18 Jan 2010 17:15:32 -0000

So cool! I bet it would be different if you ran the analysis with different language tweets.

Re: Straining Credulity: NokiaSiemensNetworks Sponsors Big Brother Trade Show in Dubai

Trade Show Displays — Sun, 20 Dec 2009 23:24:41 -0000

Blocking, censoring or otherwise filtering the Internet is just wrong. Any person, company or government who does that should be brought to task by the people.

Re: Compiling Cairo 1.8.8 for iGraph Visualization Support

Diederik van Liere — Mon, 07 Dec 2009 09:08:00 -0000

Yes I have, and I also use it quite extensively. However, for large graphs I prefer Igraph because of its speed.
Best, Diederik

Re: Compiling Cairo 1.8.8 for iGraph Visualization Support

neilernst — Mon, 07 Dec 2009 08:59:56 -0000

Have you checked out Networkx?

Re: Do Bugreporters Become Better Over Time?

Graham Perrin — Mon, 23 Nov 2009 11:19:57 -0000

> 'bad reporters’, people who submit a considerable number of
> bug reports but which seldomly are fixed …
> You can see these when the red line hits the 10% fix rate

What about prolific good reporters of 'bad bugs', people who simply lack the developer skills (or time) to fix what they report?

Equally, skilled developers may simply lack the time (or inclination) to fix a difficult 'bad bug' that was perfectly well reported.

It's wrong to associate that ~10% fix rate with 'bad reporters'.
<hr>
Edit: the more recent interpretation (highlights) is much more palatable :)

Re: How Far Does a Tweet Travel?

Lalu — Tue, 03 Nov 2009 21:33:57 -0000

Great Entry! Is this how they started the crackdown on cell-phone tweets in Iran?

Re: Jetpack Add-On to Predict Likelihood of Bug Fix in Bugzilla

Lech Deregowski — Wed, 09 Sep 2009 03:26:43 -0000

This is very cool but also at the same time it's hilarious as you're attempting to calculate a positive prediction for one bug among thousands (that's brilliant!). But there's one issue when calculating the possible outcome when a reporter (lets use me for this example) is not a coder but in this case just a lowly reporter. At the moment it appears that it's making the assessment purely on the reporters stats without using any other available (valuable) data (I know, I know, it's still version 1 :]) which is kind of funny because if you look at a bug that has been fixed the percentage is still a lowball guess which is not 100%.

Some thoughts on this would be to include some more data and base the initial average on not only the basic history of the reporter but also including how many of the bugs reported are duplicates, invalid/nofixes or have been fixed. I'm not sure if you can mine that deep for historical data, but if it's possible then awesome.

Then rebuild an estimate based on that. Scoring positive for fixed, negative for invalid and duplicates and building a percentage from total tickets found and maybe recalculate again based on the bug status. If you want to go further factor in the averages for users participating, the number of responses by them and attached files as patches or test cases. With the right kind of scoring, you could certainly build a better bugzilla user to bugs fixed profile and have better prediction in the process.

Just my two cents...

Re: Do Bugreporters Become Better Over Time?

Robert O'Callahan — Wed, 02 Sep 2009 18:33:29 -0000

It seems to me you've documented a correlation between number of bugs filed and fix rate, and are concluding that filing more bugs causes an increase in fix rate. But isn't it possible that causation goes in the other direction, or more likely, that they're both the result of some third factor? For example, users with more background technical knowledge and interest are presumably likely to file more bugs and also file more useful bug reports, independent of a learning effect.

Re: Jetpack Add-On to Predict Likelihood of Bug Fix in Bugzilla

Lee — Wed, 02 Sep 2009 13:53:56 -0000

Just FYI, this doesn't seem to work with the Dusk theme for bugzilla.

Re: Improving Bugzilla’s Bug Overview List by Predicting Which Bug Will Get Fixed

johnjbarton — Wed, 02 Sep 2009 13:13:53 -0000

The high correlation of bug fixes and stacktraces is a direct consequence of stacktraces being created automatically by the crash reporter tool and of Mozilla's focus on crashes. But my guess is that this metric strongly biased to older data: FF 3.0 and FF 3.5 crash much less because of the very bug fixes you analyze. Consequently the probability of a fix will be biased: on new bugs with stacktraces you will get high numbers which could be correct, but on new bugs without stacktraces the probability will be incorrect. (Because more effort can now go into non-crash bugs) Can you break your analysis down in to crash/not-crash? If you drop the stacktrace from the analysis does the probability analysis for non-stacktrace bugs give insight?