Chart: repository history

[pluehne]

This adds a report that records the number of repositories in total, in organizations, and in user accounts every day, and a corresponding chart in the housekeeping tab.

I also added some manually generated demo data for the online demo:

I know that the total column is redundant, as it is the sum of the other two columns (in organization and in user accounts). However, I kept it like this to keep the configuration on the JavaScript side to a minimum.

I originally wanted to use an area chart, but finally decided against it. We don’t use area charts elsewhere, and I fear that it could lead to misunderstandings of how to read the data. However, we might think about the usage of area charts later.

Additionally, I know that this chart will have a cluttered look due to the many data points given the daily updates. I’ll build a configuration option into the dashboard in order to filter out just one data point per week or so in an upcoming pull request. I’m considering an option called aggregate-method with options such as sum, max/min, or first/last.

[toddocon]

Ooo, I like this one. I will merge this into our local Hubble when its available. I like the option of changing how many data points are displayed. I've made a 2nd chart on user activity for the purpose of showing a smaller, more detailed, data set.

[pluehne]

I like the option of changing how many data points are displayed.

Great, then that’s certainly something I’ll add soon 😃. I’ll put some thought into how to cleanly handle all the different ways of aggregating data in JavaScript.

Maybe we could even provide a button next to each chart allowing users to switch between an aggregated (for instance, weekly) and detailed (for instance, daily) view.

[pluehne]

As per @larsxschneider’s suggestion, I will move the chart into a new repositories tab into which we’ll also put the upcoming repository activity charts.

[larsxschneider]

TRUE?

[larsxschneider]

Got it!

[pluehne]

For the record, this was done to handle the special case where there are no excluded entities and users.type == None.

In this case, there wouldn’t be any content to the WHERE statement, causing a syntax error.

[pluehne]

Please ignore this comment, it was intended to go into #28.

Note that, in contrast to the previous charts, this chart records the last day, week, and four weeks (instead of 30 days). I decided to do so in order to have less fluctuations due to weekends. The past 30 days might include 4 or 5 weekends, whereas the past 4 weeks would always cover exactly 4 weekends.

We might consider doing the same with the other charts, however, this might affect already existing data and require a data reset for these charts 😐.

[toddocon]

I've merged this into our local Hubble. It works.

Question: when you say that this chart only records the last 4 weeks, does that mean data older than 4 weeks will be dropped from the data file or just not displayed?

It would be good to keep long running history. I'm often asked to provide statistics from a year ago or more for comparison. "How many repos do we have now compared to one year ago?" for instance.

[pluehne]

@toddocon: Oh, I have messed something up. This comment should have gone into #28 😃.

I’ll copy my earlier comment over to there and let’s move the discussion to there as well 😃.

[larsxschneider]

minor nit: I would prefer to use "Repo" in the code instead of "Repository" to improve code readability 😄
Otherwise all variable names and filenames will become really long for no good reason.

[pluehne]

I get your point. Personally, I don’t like using abbreviations at all, as I have encountered so many cases where abbreviations introduced unnecessary ambiguities.

For instance, I had to work on a piece of code that had classes suffixed Impl, which—surprise—didn’t stand for ”implementation” but “implication,” causing a major misunderstanding of the code.

Well, while ”repo” might not be misunderstood as something else, I made a practice of not abbreviating anything for no good reason. “PR” is an example that my intuition tells me could be misunderstood, as I’d immediately interpret it as “public relations” before thinking about “pull requests.”

However, it might be more important not to discuss this for too long (as I did with this comment, shame on me) but to keep things consistent within the code base (which isn’t the case right now). So maybe, we should clean up all the files at some point after making a uniform decision on how to name things (for instance, according to GitHub’s MySQL schemes or the GitHub API).

[larsxschneider]

In general I concur (I love this post). However, Org, Repo, and PR in the context of GitHub are pretty clear from my point of view.

[pluehne]

For the record: @larsxschneider and I agreed to consistently name entities as done be the GitHub API in the future 😃.

There, pull requests are abbreviated pulls, repositories are repos, and organizations are orgs, for instance.

We’ll try to make this consistent soon!