Add contribution timeline

[mathjazz]

Fixes #2487 definitively.

The patch implements contribution timeline, which can be filtered by contribution type and day.

It's deployed to stage (which uses ~2 weeks old prod data):
https://mozilla-pontoon-staging.herokuapp.com/contributors/93Rx_ofmgBDhnz4QZD1aHlOg0uY/

TODO:

• The exclude_self_reviewed filter likely needs some tweaking. Still testing.
• File Implement year selector for the user contribution graph #2619
• Add unit tests for get_contribution_timeline_data()
• Update timeline title with the selected date

[mathjazz]

@flodolo Could you take this for a spin on stage?

[flodolo]

There are a couple of differences compared to specs:

• There is no selector for the year
• You can select a day, but not a week

I feel like we might have talked about the years stuff, but I'm not completely sure at this point.

Are these too complex to implement?

The rest looks great to me.

[mathjazz]

There are a couple of differences compared to specs:

* There is no selector for the year
* You can select a day, but not a week

I feel like we might have talked about the years stuff, but I'm not completely sure at this point.

Yes, we talked about postponing the year selector: I've added a TODO item to file an issue for that. Using the day selector instead of a week selector was a conscious decision that I forgot to explain, so let me do that now.

During the spec phase we considered using a week as the smallest unit rendered on the contribution graph instead of a day, because we didn't know how the daily graphs will turn out with the actual data. In that scenario, having a weekly selector would make sense.

We went ahead with a day as the smallest graph unit, so being able to filter contributions by a day is the most intuitive option. Otherwise rendering each day on the graph doesn't make that much sense. I would even argue that monthly selector makes more sense in the current graph, if we make month labels clickable.

[eemeli]

Looks good; a couple of minor things inline to resolve.

[eemeli]

Suggested change

	contributions_qs.annotate(
	project_name=F("translation__entity__resource__project__name"),
	project_slug=F("translation__entity__resource__project__slug"),
	locale_name=F("translation__locale__name"),
	locale_code=F("translation__locale__code"),
	)
	.values("project_name", "project_slug", "locale_name", "locale_code")
	.annotate(count=Count("id"))
	contributions_qs.annotate(
	project_name=F("translation__entity__resource__project__name"),
	project_slug=F("translation__entity__resource__project__slug"),
	locale_name=F("translation__locale__name"),
	locale_code=F("translation__locale__code"),
	count=Count("id"),
	)

Would this also work? Not sure tbh, but as is the code looks awfully repetitive.

[mathjazz]

Sadly no. This is a very implicit feature of the Django ORM to make annotations over unique groups.

To quote the docs:

Ordinarily, annotations are generated on a per-object basis - an annotated QuerySet will return one result for each object in the original QuerySet. However, when a values() clause is used to constrain the columns that are returned in the result set, the method for evaluating annotations is slightly different. Instead of returning an annotated result for each result in the original QuerySet, the original results are grouped according to the unique combinations of the fields specified in the values() clause. An annotation is then provided for each unique group; the annotation is computed over all members of the group.

[eemeli]

These should use urllib.urlencode.