Hey folks, it’s that time of the month. Please review and add anything worth reporting
http://etherpad.wikimedia.org/p/RD201401
As usual, we are not including minor internal items.
I’m planning to post this by EOD PT today.
Dario
On Mon, Feb 10, 2014 at 2:01 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
Hey folks, it’s that time of the month. Please review and add anything worth reporting
http://etherpad.wikimedia.org/p/RD201401
As usual, we are not including minor internal items.
I’m planning to post this by EOD PT today.
Hey Dario,
Who is the audience for this report? I'm curious about overlap with individual team reporting here. For instance, in the status report for Growth, we already noted the article creation research in the January Engineering report and the product manager biweekly meeting notes (which are internal).
Steven,
this was mistakenly sent to the public list instead of the internal list in preparation for the monthly report (apologies for the noise), but it’s a good opportunity to clarify the rationale.
Team updates from Research & Data are read in a consolidated version (the monthly engineering report) by community members, chapters, board members and the general public interested in Tech updates from Wikimedia, but they are also transcluded individually on the team update page [1], where people specifically interested in research can follow what the team is working on.
Given that background research on article creation is not limited to data analysis or testing for features developed within Growth it’s important that this reaches the latter type of audience and I believe a little bit of redundancy doesn’t hurt.
We want to improve how we communicate and report research. Toby and I will be in touch with product owners and team leads after the Research and Data retreat at the end of the month to discuss how to best move forward.
Dario
[1] https://www.mediawiki.org/wiki/Analytics/Research_and_Data#Team_updates
On Feb 10, 2014, at 2:06 PM, Steven Walling swalling@wikimedia.org wrote:
On Mon, Feb 10, 2014 at 2:01 PM, Dario Taraborelli dtaraborelli@wikimedia.org wrote: Hey folks, it’s that time of the month. Please review and add anything worth reporting
http://etherpad.wikimedia.org/p/RD201401
As usual, we are not including minor internal items.
I’m planning to post this by EOD PT today.
Hey Dario,
Who is the audience for this report? I'm curious about overlap with individual team reporting here. For instance, in the status report for Growth, we already noted the article creation research in the January Engineering report and the product manager biweekly meeting notes (which are internal).
-- Steven Walling, Product Manager https://wikimediafoundation.org/ _______________________________________________ Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Mon, Feb 10, 2014 at 2:35 PM, Dario Taraborelli < dtaraborelli@wikimedia.org> wrote:
Given that background research on article creation is not limited to data analysis or testing for features developed within Growth it’s important that this reaches the latter type of audience and I believe a little bit of redundancy doesn’t hurt.
Yeah I don't mind redundancy on principle, however, I do want us to be very careful about viewing R&D as separate from our actual team work. For instance, we might learn things about article creation in general that are of broad interest, but we did it in order to provide a solid background for product changes by Growth. The primary purpose of the analysis is informing change, with educating the community or organization at large a tertiary goal.
If there is analysis work, such as traffic analysis, that doesn't fit within a single team's scope but impacts the entire organization... well obviously that makes sense to put in an overall Analytics report. But just like the UX team does not have a separate report, but instead reports what it does through and for our cross-functional teams, I feel very strongly that reporting about analysis work should be done through normal team reporting whenever possible. This keeps our analysis conceptually tied to measuring outcomes and trends relevant to product work, rather than just generalized R&D.
On Mon, Feb 10, 2014 at 2:53 PM, Steven Walling swalling@wikimedia.org wrote:
On Mon, Feb 10, 2014 at 2:35 PM, Dario Taraborelli dtaraborelli@wikimedia.org wrote:
Given that background research on article creation is not limited to data analysis or testing for features developed within Growth it's important that this reaches the latter type of audience and I believe a little bit of redundancy doesn't hurt.
Yeah I don't mind redundancy on principle, however, I do want us to be very careful about viewing R&D as separate from our actual team work. For instance, we might learn things about article creation in general that are of broad interest, but we did it in order to provide a solid background for product changes by Growth. The primary purpose of the analysis is informing change, with educating the community or organization at large a tertiary goal.
If there is analysis work, such as traffic analysis, that doesn't fit within a single team's scope but impacts the entire organization... well obviously that makes sense to put in an overall Analytics report.
Can't comment on the specific issue being discussed here, but it may be worth pointing out that the monthly engineering reports have contained an Analytics section for quite a while. (For those who are not familiar with these reports, they can be found at e.g. https://blog.wikimedia.org/c/technology/wmf-engineering-reports/ . They are usually published at the day of the metrics meeting; and I believe Dario is working to fill out the gap at https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2014/January#Ana... .)
Like the general monthly WMF reports, the engineering reports are generally organized along team / department lines. And it's quite frequent that inter-team work is reported both in the section of the client team and of the supporting team (e.g. if, say, the Wikipedia Zero team launches a new partnership and we in the Communications team put out a press release about that, then it's going to be mentioned in both sections).
But just like the UX team does not have a separate report, but instead reports what it does through and for our cross-functional teams, I feel very strongly that reporting about analysis work should be done through normal team reporting whenever possible. This keeps our analysis conceptually tied to measuring outcomes and trends relevant to product work, rather than just generalized R&D.
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Mon, Feb 10, 2014 at 3:10 PM, Tilman Bayer tbayer@wikimedia.org wrote:
Can't comment on the specific issue being discussed here, but it may be worth pointing out that the monthly engineering reports have contained an Analytics section for quite a while. (For those who are not familiar with these reports, they can be found at e.g. https://blog.wikimedia.org/c/technology/wmf-engineering-reports/ . They are usually published at the day of the metrics meeting; and I believe Dario is working to fill out the gap at
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2014/January#Ana... .)
Like the general monthly WMF reports, the engineering reports are generally organized along team / department lines. And it's quite frequent that inter-team work is reported both in the section of the client team and of the supporting team (e.g. if, say, the Wikipedia Zero team launches a new partnership and we in the Communications team put out a press release about that, then it's going to be mentioned in both sections).
Dario wanted to take the discussion offline, but we're talking specifically here about the including the work that is product analysis, not the regular reporting on infrastructure by Analytics. I'm not suggesting that we remove that.