colinmorris / moz-graphs

moz-graphs

This is a big mess of code for collecting and analysing data about interactions between Mozilla developers and the bugs they work on. Messy data + graph theory + relational stuff.

I use igraph for the graph theory stuff and sqlalchemy + sqlite + alembic for my db.

This is really not intended for anyone else's use, and it doesn't include the raw data that you would need to populate the db (though it does include some scraping code to collect some of it). But if you do find anything here useful for whatever reason, please help yourself to it.

moz-graphs's Issues

bugmonth debugging/diagnostics

Procedure to write diagnostic info about bugmonths table to a text file somewhere in logging/ to ensure values are in a sane range. For each column, write:

• Column name and type
• Number of NULL rows
• Number of 0 rows or '' rows (for strings)

If numeric:

• Average, variance, minimum, maximum

Unit tests

Would be really nice to have some unit tests. Have option of either...

1. Setting up a toy DB to test on with a small number of months, debuggers, links, etc.
2. Using the existing DB w/ some canonical set of months, debuggers, bugs, etc. the properties of which we've determined by manual inspection.

assignee graph variables

Implement bugmonth variables related to the assignee's position in the graph (assignee betweenness previous month, constraint past monthly average, etc.).

We have 3k bugs but only ~300 debuggers who are ever assigned to a bug, so to avoid duplicated work, maybe we should just:

• make a "debuggermonth" table
• populate it for each month, and for each of the 300 assigned debuggers. This will only involve using one graph at a time.
• Then to find e.g. "constraint past monthly average", we can just do a db query, rather than going through the graphs for each of the past months, calculating the constraints, and then doing the same thing next month, and the month after etc.

This may also prove useful when we do the "bug's debuggers" graph variables.