We are thinking that more selective metrics regarding active editors might be added, specially considering larger wikis.

So, following: WikiMedia's Wikistats metrics (enter here for an example); we could have active editors who have made: {>=1 edit, >= 5 edits, >= 25 edits, >= 100 edits}. Right now we are only have "active users" which we consider users who has made >= 1 edit (as explained in our wiki).

Next level would be to have "very active users" who are editors who have made >=100 edits, but we should consider if this meaningful for the vast majority of wikis that we are studying.

A way to do it would be to let him short by "drag and drop" the metric names in the container where the selected metrics appear.

Perhaps, to make it intuitive for the users, the box that contains the metric name should also have a correlative number starting from 1.

Wild guess. Ask the interface designer.

The computation of the metrics assume several aspects that should be clarified somewhere in wikichron, probably and info page.

A (probably) non-exhaustive list of aspects and decisions taken that should be clarified/explained are:

• Definition of page, article, user, active user, anonymous user, contribution (are there any exception to the definition? how are they computed?)
• How are the edits (and other metrics) of anonymous users computed (grouped by IP address?)
• What happens with bots edits (they are removed from the metrics)? How are bots identified?
• How are the montly counts computed specially in the case of "relative" dates? By natural months or by "relative" months?
• Mathematical formula of each and every metric computed

https://en.wikipedia.org/wiki/Theil_index

It should appear in Wikis and Metrics tab and always appear at the bottom of the screen (and do not dissapear from it).

Since the tool is interested in analyzing/visualizing human activity in wikis, metrics must not consider bots or bot activity.

Hence, bots should be removed from users counts (active users, new users, new registered users, etc), from activity counts (gloabl edits, article edits, edits in user talk, edits in article talk, pages edited monthly...) and ratios (e.g. in edits per user, bot activity should not be taken into account into the numerator and bots should not be counted in the denominator).

For some reason, the code contained in main:

# create and config Dash instance
    app = create_app()

    # set layout, import startup js and bind callbacks
    set_up_app(app)

    # start Dash instance
    start_app(app)

is executed twice every time the app is launched.
I'm not sure if this is a expected behaviour and if it's because of Dash or because of our code. This is what we need to find out.

Ask Elena for the logo?

We want a way to share the selected params with other people or to save the current selection for further analysis. We currently are not interested in a user management in order to save and share sessions, so this should be implemented through an unique URL.
Using URL routing along with query string would be a good option to implement this.
See https://plot.ly/dash/urls for documentation of how Dash support URL routing.

Dash core components have included recently the Tab component. Explore if it suits our needs and if so, move to them.

Use a redis instance to store the selection for each browser session in the server and store there the data calculated for each session. See the plotly docs for more info (Example 4).
Test it and check performance.

The csv will have the metrics for all the wikis selected and for each wiki it will be include an absolute and a relative timestamp.

In this way, users can analyze the data further in case they want, for example, apply some time series analysis methods.

Regard security issues of allowing anyone to upload files to the server.

Categories for wikis by pages number:

• Large: wiki > 100 000 pages
• Big: 100 000 > wiki > 10 000
• Medium: 10 000 > wiki > 1000
• Small: 1000 > wiki

The percentage is computed 100*(edits_by_anonymous_users / edits)

It would be interesting as a monthly metric (considering only the edits of a each month) and the accumulative version (considering the edits from the creation of the wiki until the end of each month).

There are some issues that could be refined. Namely:

• The endpoint of the slider should have a tag.
• The tags in absolute dates should not be every 5 elements, but every 6 elements or every 12 elements (in this way, they work in a yearly basis). Furthermore, to make them correspond with the vertical lines in the plot, they should mark the beginning of the year (January)
• Consecutive date tags may colapse in some cases. Consider rotating the tags, if possible.
• It would be nice to see the date with the current position, when you are sliding the handle.

At this moment: Pages, editions, users, size, combined.

Calculate Gini coefficient for users over number of edits for any given month.

Time and profile how long it takes to load the webapp in first place, loading csv data when comparing and time plotting such data.

Create an external pypi library for the metrics related to the distribution of participation.

License: LGPL

To measure how is the work distributed between "core" contributos and "occasional" contributors.

First, change the name of the wiki to an operative name. Is there a unique id name for each wiki? If not, don't panic, the rest of the information shown should disambiguate the wiki.
Information that could be show is:

• Year-month of creation
• Number of users (as of the dum date)
• Number of articles (as of the dum date)
• Year-month of the dump
• Link to the wiki home (it could be added as a hyperlink in the wiki name)
• Logo (it could also link ot the wikihome).

To do the missing two complementary metrics for active users:

• Active registered users
• Active anonymous users

The tag of the vertical lines in the plots is in December of the previous year, while the lines are supposed to mark the beginning of the year, that is January.

Suppose we have a wiki A whose dump goes from May 2010 to Jun 2017, and another wiki B whose dump goes from Jan 2018 to Sep 2018. In this case, the slider will only show and select dates for the oldest wiki (A) and won't allow to select dates for the youngest wiki (B), resulting in that the wiki B is not being shown in the graphs.

This can happen with any combination of wikis where the oldest wiki lifespan doesn't contain all the other's.

A solution for this would be to do a set add of the lifespan of all the wikis and use the resulting set lifespan for the slider.

Two new metrics to measure the grade of inequality of workload between top users:

• Ratio: 1% user / 5% user
• Ratio: Top contributor / 5% user

Being:

• 1% user -> user who occupies the 1% position of top contributors
• 5% user -> user who occupies the 5% position of top contributors

Refactor how the metrics are calculated.

First, some concerns about some"distribution of work" metrics.

The metrics that use a ratio of percentiles of top contributors are not only hard to explain, but also a bit meaningless since they literally "personalize" the ratio. By personalize, I mean, that you are comparing the contributions of two (top) contributors. Is it really relevant?

Perhaps, it is much more relevant (and, btw, easier to explain) to proceed in a similar fashion to the 10:90 ratio and compare using a ratio the contributions of, for example, the top 1% of contributors against the contributors from 1% to 5%. Similarly we can compare the top 5% against the contributors from 5% to 10%.

Alternatively, we can plot the percentage of contributors that make several percents of contributions:

• 99% of contributions
• 95% of contributions
• 90% of contributions
• 80% of contributions

These metrics are used in the Figure 5 of "Temporal Analysis on Contribution Inequality in OpenStreetMap" by Yang et al (2015). We will separate each percentage in a plot-

We can also consider a similar metric but inverting the role of contributors and contributions. That is, the percentage of contributions made by the top % of contributors:

• top contributor
• 1% of top contributors
• 5% of top contributors
• 10% of top contributors

I think that these two last set of metrics should be clearer to understand by visual inspection and also to explain in words.

Use clearer names

The length of the x axis depends on the length of the legend (which inversely depends on the length of the name of the wikis). If you download a plot with wikis of short names the length of the x axis is longer than if the wikis have a long name. And no legend appears if the plot only has one wiki (so you get a plot with the longest possible x axis).

If possible, consider to use a fixed length for the axes (at least it should be the length of the plots with no legend) and a variable length for the legend (the length could depend on the names of the wikis). Alternatively, the legend could be below the plot, but the height of the axes should not change either.

Display a short metric description when mouse is over the metrics of the list.
Use html title attribute for this.

An user can enter a link and Wikichron will take care of: downloading the history dump for that wiki, parsing the data, getting the metadata for the wikis.json file and making it available in the list of wikis of the tool.

In this way, we can homogeneize the analysis of wikis considering them up to one absolute day (e.g. 31st of December 2016) or up to one particular age (e.g. 4 years old).

Relative/Absolute dates should be a switch in the right side, probably close to the slider with the time range.

Both time series should be computed at the same time (when the COMPARE button is pushed) and the switch should be on the right side to make possible the user change between both possible views whenever he or she wants.

In my opinion, if you visualize just one wiki the default mode should be absolute dates, but if you compare more than one the default mode should be relative. By "default mode" I mean what it should be shown when you push COMPARE. The user should not anticipate how he wants to show the time series before, but casually change from one to other in case he or she wants it.

Regarding the slider, it changes with the absolute/relative selection.

• The slider numbers should change from integers to dates or viceversa.
• The handles should be reset to all the time range. Probably more sophisticated behavior is not needed.

Question @javiag : what we want here, total active users or total users?

• Anonymous article edits (%)
• Total anon. article edits (%)

Tentative organization suggested (some metrics may not appear right now). The name of the list is followed by the list with the metrics. The "monthly/accum" means that both metric versions should appear.

New Pages (monthly / accum)
- Pages
- Articles
- Article talk
- User Talk
- Others

Edits (monthly / accum)
- In pages (old "General")
- In articles
- In article talk
- In user Talk
- Others (?)
- Edited pages (probably only non accum)
- Edited articles

Users (monthly / accum)
- New users
- New anonymous users
- New registered users
- Active users
- Active anonymous users
- Active registered users

Ratios (monthly / accum)
- Page edits per user
- Article edits per user
- Edits per pages (edits understood as page edits)
- Edits per articles (edits understood as article edits)

Think whether it is possible to elegantly show the accumulated and non accumulated metrics without duplicate the number of lines (elements). Perhaps, the elements could be inside a "table" with three columns: name and the column with non accum checkboxes and the column with accumulated checkboxes. If one metric has no "accumulated" version no checkbox appears in that column.

Think whether we should use the word "accumulated" or "cumulative".

It is not a priority in WikiChron, but bot activity could be shown using a few metrics;

• Bot edits (considering edits in general and not particularizing whether they edit articles or not)
• Bot users

It seems that could provide insight about the origin of the inequality: " If the LAC is less than 1, the inequality is primarily due to the relatively many small or poor individuals. If the LAC is greater than 1, the inequality is primarily due to the few largest or wealthiest individuals." It remains to be seen what happens if the origin is due to both factors as is often the case in wiki data.

https://en.wikipedia.org/wiki/Lorenz_asymmetry_coefficient

More details in the original article:
https://doi.org/10.1890/0012-9658(2000)081[1139:DIIPSO]2.0.CO;2

It is funny that is was proposed in an ecology journal, but interestingly has been used in other fields including wealth distribution, computing, etc.
https://scholar.google.es/scholar?cites=12769940368116922741&as_sdt=2005&sciodt=0,5&hl=en

Also belonging to the Inequality metrics, there is some interest in adding Herfindahl index (HHI)

Each selection of metric x wiki should be cached individually instead of caching as a whole the {selected wikis x selected metrics} set, so that subsets of that current selection are cached as well.

In order to do this, likely, the call for computing metrics will need to be improved. See this line of code for a starting point: https://github.com/Grasia/WikiChron/blob/master/lib/interface.py#L60

Allows to have different analysis opened at the same time.

If you show a metric that has zero values in between (not at the end or at the beginning). The value seems to be removed for some reason and the resulting time series is shorter (and delayed in the time axis) .

Example from the good luck charlie wiki. The delay can be seen in the vertical reference lines.

And it should have two handles (starting and ending point).