[Metrics] Common Metrics - Contributor Location

[xiaoya-yaya]

Description:

• Geographical location from which contributors contribute, where they live, or where they work.
• To determine global locations of contributors in an effort to understand work practices and times zones. To identify where contributions do not come from in an effort to improve engagement in these areas.

Filters

• Location is a purposely ambiguous term in this context, and could refer to region, country, state, locale, or time zone.

Instances of Implementation

Resource CHAOSS: Common Metrics -> Who https://chaoss.community/metric-contributor-location/

[open-digger-bot[bot]]

This issue has not been replied for 24 hours, please pay attention to this issue: @sunshinemingo @wengzhenjie

[frank-zsy]

This one is really hard to implement, unless we use working hour to estimate the location.

[xiaoya-yaya]

This one is really hard to implement, unless we use working hour to estimate the location.

I remember my original thought was to use the working hour estimation method from our analysis report (that is why I placed that column chart), but we can also temporarily not implement this.

[birdflyi]

Is it worth considering to implement them separately?

In my opinion, the equivalent time zone of working hours is as important as the geographic time zone. It is very important to distinguish time zone between estimated value and actual value in some situation, and another interesting part is the deviation value between them, from which the regional cooperation information can be extracted~

[xiaoya-yaya]

I like the idea of equivalent time zone of working hours because this demonstrates the actual working time inclination of developers. The difficulty in comparing the deviation is that it's hard to obtain the geographic information of developers for now.

[birdflyi]

Well, I see. Agree with the above points. Equivalent time zone of working hours is more suitable here. Estimate the time zone for different people may call for more informations, for instance, some geographic time zone labeled data of users.

[frank-zsy]

The name equivalentTimeZone is a good choice for this metric, and this one should be a metric for users.

The original thought is:

• Accumulate the users' event data for a certain time period and collect as 0am - 23pm in UTC time.
• Find out the most active 12 hours of the event array.
• Assume the 12 hours should be 9am - 9pm in the local time zone for the user.
• So the start of the most active 12 hours will be 9am, then we can identify the time zone of the user.

And actually we can pass in the 12 hours and 9am as parameter since these are not verified by scientific methods right now, but in the future I think we can study on the parameters and give a more scientific default value.

[frank-zsy]

Another thought discussed with @tyn1998 is that we should consider summer time and winter time as well since they also effect developers' time table. So maybe the procedure is estimating the time zone of a developer first and then in the second step, with the first step result, we can assume whether a developer will be effected by summer time or winter time.

But for first step, I think above method is fair enough for time zone estimation.

More details about summer time/daylight saving time and winter time.

[birdflyi]

The name equivalentTimeZone is a good choice for this metric, and this one should be a metric for users.

The original thought is:

• Accumulate the users' event data for a certain time period and collect as 0am - 23pm in UTC time.
• Find out the most active 12 hours of the event array.
• Assume the 12 hours should be 9am - 9pm in the local time zone for the user.
• So the start of the most active 12 hours will be 9am, then we can identify the time zone of the user.

And actually we can pass in the 12 hours and 9am as parameter since these are not verified by scientific methods right now, but in the future I think we can study on the parameters and give a more scientific default value.

Agree at this step. And I take the most active 12 hours of the event array as the maximum cumulative active value of 12 hours continuous interval.

[frank-zsy]

Agree at this step. And I take the most active 12 hours of the event array as the maximum cumulative active value of 12 hours continuous interval.

This is great!

[birdflyi]

Another thought discussed with @tyn1998 is that we should consider summer time and winter time as well since they also effect developers' time table. So maybe the procedure is estimating the time zone of a developer first and then in the second step, with the first step result, we can assume whether a developer will be effected by summer time or winter time.

But for first step, I think above method is fair enough for time zone estimation.

More details about summer time/daylight saving time and winter time.

It's really complicated. I doubt it may involve the influence of the latitude when take summer time and winter time into account.

[frank-zsy]

It's really complicated. I doubt it may involve the influence of the latitude when take summer time and winter time into account.

Yes, latitude will be involved in the implementation, so we should not take this into account for now.

[frank-zsy]

/self-assign

[frank-zsy]

I will close this issue since #1151 has been merged, this issue can be reopened or raise a new issue if we have more data about developer location in the future.